Writing Cdroms Right

Data CD Burning: track-at-once vs. disk-at-once

There are two modes you can use when burning data to a CD-ROM: track-at-once (TAO) and disk-at-once (DAO, also known as session-at-once, or SAO). Assuming you don't need to do multi-session writing, you may use either of these modes. Here is an explanation of some practical differences between these modes that will help you decide which to use.

When reading a CD created with TAO mode, a run-out area past the end of the data is required. If this run-out area does not exist, you will not be able to read the last small portion of data on the CD. For this reason, and since cdrecord defaults to TAO, mkisofs defaults to padding the end of the disk image with 150 blank sectors. So by using (current versions) of mkisofs and cdrecord at their defaults, you should have no problem mounting the CD and reading back the data you wrote. However, the problem with TAO is that you cannot read the entire low-level disk data, for example with "cat /dev/cdrom", because that would try to read the run-out sectors and result in errors. Although the readcd utility lets you specify a sector range when reading the low-level data, for any given CD you may not know if it was created with TAO or DAO or, in the case of TAO, how much padding to account for.

The advantage of a CD created with DAO mode is that operations such as extracting the disk image or verifying against the source image are trivial. However, when burning a CD in DAO mode, it is necessary to tell cdrecord the true sector size of the filesystem. This, combined with the fact that this mode is not the default of the utilities, makes DAO a bit cumbersome. The main points are to use the -no-pad option of mkisofs, and the -dao and -tsize options of cdrecord. The -tsize option must be set to the number of sectors of the filesystem, with the postfix "s". In our case this value is the size of the image file in bytes divided by 2048 bytes per sector. For example:

mkisofs -no-pad -r -J -o test.iso files/
# this results in test.iso which is 202752 bytes, and 202752/2048 = 99 sectors
cdrecord -v dev=0,0,0 -dao tsize=99s driveropts=burnfree test.iso
# verify result:
cmp /dev/cdrom test.iso
# copy result:
cat /dev/cdrom > copy.iso

postscript: contrary to what is implied above, it is possible to discover the size of data contained on a disk, using tools such as isoinfo. Given that, the original ISO image of a disk can be accurately extracted and verified-- although still not as trivially. This means there is less incentive to omit the record padding, which may cause problems with some combinations of hardware and OS even with DAO mode.

HomePage · FindPage · RecentChanges · preferences
(site locked) · history
Last edited April 4, 2005 11:42 pm EDT (diff)