war story: puzzled by DVD writing

[Peter King]

On Sun, Jul 07, 2013 at 12:13:56PM -0400, D. Hugh Redelmeier wrote:

> CD / DVD / Blu-Ray writing is such a complicated and arcane area that
> I try to avoid trying to understand it.  I just want to use one or two

Ditto!

> - if I tick the K3b burning option "create image", burning works.
>   This option causes K3b to create an image on the internal hard drive
>   before starting to burn the disk.  The advantage is that the
>   external USB drive and the NTFS filesystem no longer can cause a
>   delay in the middle of the actual burn.  The disadvantage is that
>   you need almost 5G of free space (and the whole process takes a bit
>   longer).

This means it is almost certainly a FIFO problem, possibly CPU speed;
years ago, when using what are nowadays laughably underpowered CPUs, I
used to regularly have to create a .iso image first before burning.

> Counter-evidence:
 
> - the log claims that "burnfree" (buffer underrun recovery) is
>   enabled.  Nothing in the log shows that this fired.  In a sensible
>   world, underruns, even ones recovered from, should be reported.

All that means is that the *software* enables sequential cache recovery
for burning. The hardware has to support the option too, and even then
it depends on how quickly the CPU can fill the cache.

> - amazing amount of noise/information on the web from the author of
>   cdrecord claiming lots of bugs in wodim (an "unauthorized" fork).

The cdrecord/wodim split was a nasty one, with lots of hard feelings on
both sides. Better to ignore all such charges. I've used both, and each
side has some justice, but most of it is noise rather than signal.

> What burning software do you use?  Why?

I use cdparanoia for ripping, which is very reliable. When necessary I use
mkisofs to create burnable images. But I also create burnable images and do
the actual burning with growisofs, which is also extremely reliable. These
are all command-line tools and have worked reliably for me over the years.

> /usr/bin/wodim: fifo was 0 times empty and 25505 times full, min fill was 92%.

That message suggests that the memory cache is reasonably filled, so the
failure must be in the speed of processing the FIFO queue -- which again
can be explained if there is no burn-free hardware option.

-- 
Peter King			 	peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Department of Philosophy
170 St. George Street #521
The University of Toronto		    (416)-978-4951 ofc
Toronto, ON  M5R 2M8
       CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://gtalug.org/pipermail/legacy/attachments/20130707/98049b16/attachment.sig>