DVD+, buffer underrun, write speed and verification issues
Greetings,
I have a few questions concerning DVD+R[W] writing. IMHO, I think the
issues brought up here are prime candidates to add to the existing
sources of information on DVD writing software (such as the important
FAQs and READMEs or the dvd+rw-tools and cdrecord-ProDVD applications).
Although I am familiar with CD writing, DVDs are a new ball game to me.
I am using a Toshiba SD-R5272 DVD+/-RW drive on an older K6-2 400Mhz
Linux 2.6.8.1 system (which is even further slowed by the need to
disable IDE DMA due to hardware issues).
The fact that the base DVD transfer speeds are higher than that of
CDs caught me off guard in the form of buffer underruns. Things
got a lot more confusing when I was met with unsuccessful attempts
to slow the recording speed to 1x:
: cdrecord-ProDVD dev=1,0,0 -v -sao fs=16m speed=1 driveropts=noburnfree,forcespeed myfile.iso
: .
: .
: Average write speed 2.1x.
: Min drive buffer fill was 0%
: Total of 51 possible drive buffer underruns predicted.
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.)
It seems that DVD *media* contains minimum as well as maximum write speed
specifications. This is not at all obvious to new users. For goodness
sake, point this out as well as showing what the various fields output
by dvd+rw-mediainfo mean! It would also be nice if the dvd+rw-tools
offered a way to get the drive information (a la cdrecord-ProDVD -prcap).
Andy Polyakov wrote a good post about this speed issue:
http://lists.debian.org/cdwrite/2004/03/msg00032.html
> Keep in mind that growisofs speed selection code works as following: ask
> firmware for supported speeds for this media, take lowest for 1x,
> multiply it by -speed factor and find the *closest* speed in the list
> from the first step. Meaning that -speed=1 doesn't really mean set 1385,
> but rather "pick the lowest speed." And so does -speed=0.5...
Such information would also be at the top of my list of things to
say in DVD writing tutorials, FAQs and READMEs.
The write speed issue is even further complicated by the DVD+ formats.
Andy Polyakov wrote another good post about this latter issue:
http://lists.debian.org/cdwrite/2003/11/msg00118.html
> Manual page explicitly mentions that -speed option is for controlling
> DVD-R[W] recording velocity. This means that it indeed is ignored in
> DVD+ context. I don't know if the following statement holds
> *universally* true, but at least all unit's I've worked with so far
> couldn't control the DVD+ recording speed. This is the original reason
> why the -speed is ignored. At least for the time being [as nobody says
> it can't change].
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:
ftp://ftp.berlios.de/pub/cdrecord/ProDVD/README
> A DVD+R is written in a mode something between TAO and packet writing
> mode.
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.
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
> only.
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.)
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
trust).
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
warnings.
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.)
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:
http://lists.debian.org/cdwrite/2004/11/msg00135.html
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
VCC, IIRC).
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?!
I have no experience as to how DVD media stands up to real-world use
(dust, fingerprint accidents, etc.). I sure would not trust it as the
only means to store critical data of any sort - even with
user-land-add-on sector level redundancy.
No offense, but as far as DVD-land goes, what a mess!
Thanks in advance for any comments and advice,
Mike Shell
Reply to: