[Ffmpeg-devel] Re: OT: cdrecord

Måns Rullgård mru
Wed Aug 3 11:00:04 CEST 2005


Hauke Duden said:
> 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.

Now try explaing this to J?rg.

> 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.

Cdrecord already prints the number times burnproof was used.  Even when
burning with the source files on NFS over wireless LAN, and a loaded system,
it is virtually never needed.  Modern burnerns have typically 8MB buffers,
so there would have to be quite a bit going on for cdrecord to lose the CPU
long enough to make a difference.

-- 
M?ns Rullg?rd
mru at inprovide.com





More information about the ffmpeg-devel mailing list