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: ftp://ftp.berlios.de/pub/cdrecord/ProDVD/READMEA 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.
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 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.)
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 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.)
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: 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?!
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 <firstname.lastname@example.org> CTO TMR Associates, Inc Doing interesting things with small computers since 1979