[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DVD+, buffer underrun, write speed and verification issues

Michael Shell wrote:

Note also that I have always used -dao/sao mode with CDs to get an
"faithful" reproduction of whatever image I wanted to burn. (Furthermore,
I do not trust the "burnfree" approach - if I get an underrun during
recording, I won't trust the disk.)

I don't know why you think thiss is more faithful... I burn many of my incremental backups with addir, and write multisession, using tao. I have programs which create and verify individual md5sums for the files, and have no problems.
So, why is this? Well, this is indirectly mentioned at the end of
Andy's DVD+RW/+R/-R[W] for Linux page:

Sometimes DVD+RW/+R recording strategy is referred to as packet writing.
I myself am reluctant to call it so (or TAO/SAO/DAO) for the following
reason. Despite the fact that DVD-R[W] provides for lossless linking
(within a packet/extent only), packets/extents are still denoted with
certain linking information which distinguishes it (recording mode in
question) from e.g. Disc-at-once. Now the point is that written
DVD+RW/+R media, rather its Data Zone, does not contain any linking
information and is logically indistinguishable from one written in
DVD-R[W] Disc-at-once mode (or DVD-ROM for that matter). 

which is similar to the way Joerg Schilling put it at the end of his
cdrecord-ProDVD README:

A DVD+R is written in a mode something between TAO and packet writing

However, it is easy to become confused by the wording of the first part
of that same README:

DVDs may be written in SAO mode or in packet mode. Cdrecord currently
only supports SAO mode. Cdrecord-ProDVD-1.11a35 and later allow to
specify -dao for correctness. Later versions of cdrecord will only
write DVDs if -dao is specified.

I agree this is not clear. It can be read as meaning either that the DVD media can only be written in SAO/packet, or that the software only supports those modes. Then it says -dao is is required by the software, but it's not totally clear if this means the option is igored and -sao is used, or that -dao will be supported at a later date.

Clearly you need more than -dao to allow multi-session.

as it is easy to mistakenly conclude from this that later versions of
Cdrecord-ProDVD will require the -dao option and that DAO is the correct
way to record all DVDs.

It does not help that this is also in the README:

IMPORTANT NOTE: DVD+R and DVD+RW are not official DVD formats
from the DVD-Forum. The drives are available for a short time

which is easy to incorrectly interpret to mean that DVD+ is nonstandard
and as such will be orphaned in the near future. (I think it should read
"The drives have been available ...".) I sympathize with the worry of the
DVD-forum to prevent the confusion that resulted from all these different
standards. However, reading Andy's page, I get the distinct impression
that DVD+ is the way things should have been done in the first place.
(Except that DVD+ lacks a dummy/simulation mode. Geeezzz. This is another
thing that every DVD FAQ should mention.)

Unless there was something I missed, the statement about nonstandard was correct when written, and may be still for all I know. I put no more faith in Jorg as a fotune teller than any other predictor or the future. Maybe it will go away, maybe it will be a standard, maybe there will be a standard which corrects the shortcomings of +R and -R, some of which you mention above.

Indeed, recording an image via growisofs to DVD+ media seems to proceed
correctly on my underpowered system without hint of any type of buffer
underrun even though indicated recording speeds were still at 2x.
This brings two questions to mind:

 1. Do I not have to worry about underruns with growisofs when writing
    to DVD+ media on a slow system? If it is possible for underrun
    related corruption to occur, will growisofs warn me of this
    and not silently rely on burnfree features (which I do not

2. What is the correct write mode (dao/sao/tao, etc.) option to use
   under cdrecord-ProDVD for DVD+ media? I am pretty sure that my use of
   SAO/DAO was incorrect for my slow system as it resulted in underrun

I am also curious as to the size of the DVD+ data packets and whether or
not the DVD+ formats are truly designed to be timing insensitive - that
is from the point of view of any minimum data rates required by the host
machine. (e.g., that DVD+ data packets are supposed to be <= the size
of the drive's buffer and that the drive will not begin a packet write
until it has acquired a complete packet from the host.)

I pass to Andy on this one!

Which brings me to my last point. Every DVD writing tutorial/FAQ should
mention something about how to verify the written data.

My personal choice right now is to use:

cmp -b myfile.iso /dev/dvd

noting that cmp will encounter the EOF of the image file first as reading
from /dev/dvd does not complete at the end of the recorded image unless
the recorded image fills the media entirely (or is it just to the end of
the next 32k boundary?). One can also use the -n option of cmp to restrict
the comparison length to that of the original image. Another way to verify
is to use md5sum. However, md5sum does not seem to have an -n which implies
that dd must first be used to get the first N bytes of /dev/dvd where N is
the file length of the image - and doing so can take up a lot of HD space.
IMHO, if you have to read all the bytes anyway, you might as well use cmp.
md5sum's are the way to go when you want to delete the original image and
need to verify sometime afterward.

I'd much rather have something like readcd's -c2scan - it is just
unbelievable that after all that effort to develop DVD writer standards,
there seems to be no way to verify written data at the lower levels
as Joerg mentioned in a reply to a post by Volker Kuhlmann on the subject:

Actually, IMHO, I think that there should be some means to verify
at the "analog" level (maybe that is what Joerg means by "PI/PO" scan).
That is to say, that drives should offer a "verify" mode in which read
parameters are intentionally compromised (such as reduced read laser
power, reduced jitter tolerances, etc.) to see at what point errors
begin to occur and, thus, getting a feel for the *analog* strength and
integrity of the recording. Those of you old time hardware hackers may
remember that the later generation EPROM memory chips offer such a
feature with a verify mode that reduces the allowable tolerance of a
the analog read signal from the memory cells (through a reduction in

As it stands now, I am not so confident in the reliability of DVD disks
for backup applications. It seems so hit and miss: "What do you expect
from cheap media?" I dunno, I for one expect it to work - how does
media that cannot record reliably differ from, say, a hockey puck?!

If you do -dao from asn existing ISO image, verification should be as easy as using md5sum. Get the size of the filesystem as written with "isoinfo -d -i /dev/dvd" and remember that it is in 2k sectors. Then check the sum with "dd if=/dev/dvd bs=2k count=size | md5sum -" and you have your answer.

I embed a file in the data with the md5sum of the other files, so I can identify an individual bad file if I have one, and so I can do multisession easily. So I have "contents-sesNN.md5" files, one per session.

bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Reply to: