Bill Davidsen wrote:
This is not ISO9660 data. I want the burner program to take my bits and put them on the media, nothing else. The data is in 64k chunks, so all writes are sector complete. I haven't had any issues with reading the data off DVD, or off CD in the case where I write it to something which allows me to know the size, but in general I don't. Nor can I run the data generation repeatedly to get the size, it's one of those "it depends" things.
Unfortunately, determining the end-of-data (end-of-track) location on a data CD is one of those things which is difficult-to-impossible to do reliably. This seems to be due to the way in which the 2048-byte-block data format is "layered on top of" the original Red Book audio CD format. On a data CD written in the usual way (one data track), the transition between the data-layered blocks and the leadout area is difficult for CD players to handle reliably, and different players tend to behave differently. If you're lucky, your CD-ROM drive will read the last data block reliably, and the attempt to read one block beyond that will result in an immediate I/O error of some sort, allowing you to detect end-of-data reliably and quickly. This rarely seems to be the case, unfortunately. Other scenarios I have seen include: - The last data block reads back reliably. Attempting to read the block following it does return an error, but only after a substantial delay. - The last data block (or even the last couple of data blocks) are unreadable. Attempting to read them results in an I/O error. I believe that I remember some discussion on the list, which turned up a spec requirement that when transitioning between tracks having different modes (and the leadout is a different mode than a data track) you're actually required to pad the data... or, if you don't, the transition blocks between tracks are formally unreadable. I don't remember the exact details. In practice, in order to be able to read your last real sector(s) of data reliably, it's necessary to pad the burn with a few sectors of unwanted filler data. I believe that cdrecord and/or mkisofs were changed, a few years ago, to apply this sort of padding automatically to ensure that the final portion of an ISO9660 image would always be readable. Since you aren't using ISO9660, and since you have prior knowledge of your data's fundamental block size (64kB), I think there's a reasonable solution for you. - Use cdrecord (or one of the plug-compatible substitutes) in TAO burning mode. - Use the "-pad" option, with "padsize=16" option (16 sectors or 32kB of padding). - Read your CD-ROM disk back 64k bytes at a time. - You'll get an I/O error when you try to read the 64kB byte chunk which extends past the end of what you actually burned. Ignore any fragmentary data (partial chunk). You can probably use the track size in the TOC as an indication of the amount of data actually written - just round it down to a multiple of 32 sectors. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org