[Ffmpeg-devel] Re: OT: cdrecord

[Hauke Duden]

Rich Felker wrote:

>On Mon, Aug 01, 2005 at 11:28:54PM +0200, Tobias Diedrich wrote:
>  
>
>>Rich Felker wrote:
>>
>>    
>>
>>>realtime priority is not useful; joerg just claims it is. i've nver
>>>used realtime priority, even when i had an old burner, and all modern
>>>burners have "burnproof" functionality which turns off the laser when
>>>the buffer drains and resyncs and resumes burning when more data is
>>>available, all in hardware with no software intervention.
>>>      
>>>
>>BTW, Joergs cdrecord stupidly _disables_ burnproof by default,
>>because he thinks it degrades cd quality.  (Which I could understand
>>if burnproof would kick in too often, but it usually doesn't kick in
>>and is nice to have safety net)
>>    
>>
>
>It would be interesting to see the real facts on whether it degrades
>quality.
>

It is true. Burnproof is also not perfect. If it kicks in too often (as 
in "all the time") then some burners give up and emit an error. For 
others the disc can become unusable. Frequent buffer underruns also 
degrade reading performance.

However, I agree that it is stupid NOT to use burnproof because of this. 
As has already been said, buffer underruns are usually rare and for 
these cases the disc quality will not be degraded in a noticable way. 
And even for worse cases: I prefer a disc with degraded quality to a 
broken disc. If the data is verified after the burning and you don't 
care about read speed then a degraded disc may be perfectly fine for you.

There are also heuristics to detect buffer underruns when burnproof is 
enabled - they are far from perfect, but if buffer underruns occur all 
the time then they work quite well.. So cdrecord could print a warning 
at the end of the process if it thinks that a lot of buffer underruns 
have occurred and that the disc quality may have suffered. Then the user 
can decide if he wants to burn it again or not.


Hauke