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: 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: 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.
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 <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 |