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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]