Despite appearances, the following is a simplified account of storage on a DirectCD disc. For the full story, check ECMA 119 and 167 at http://www.ecma.ch - or the equivalent from ISO if you can afford their fees. I am not the source of this information, but its author is fully knowledgable and has done an admirable job of making it understandable. If you doubt that, try the ECMA documents.
In order for data to be readable on a standard CD-ROM, the disc must contain three things: a lead-in (containing the table of contents or TOC), the data area (containing the tracks), and a lead-out (containing nothing). The TOC is NOT the same as it would be used for a file system; it only describes what is in the data area - like track start and stop positions. An "open" disc or session contains only the data area since the ultimate track layout is not known (new tracks can be added) until the session is closed. These data are stored in a temporary location called the PMA. When the session is closed, the drive gets the temporary information from the PMA and writes it in the lead-in as the TOC. Again, this has nothing to do with the actual contents of the data area. Move that disc to a CD-ROM drive, and the CD-ROM will find the TOC and tracks and is able to perform reads or to play the associated audio. In a multi-session disc, you would have multiple lead-in, data, lead-out sequences with each lead-in except the last linking via some pointers to the next. The CD-ROM drive starts at the first lead-in and follows it through to the last one to locate the current data set. A CD-R/RW drive does all this, but is able to read the PMA as well so it can find the open session data. Now, when using incremental, or packet writing, the link, run-in and run-out blocks are added whenever a packet is written; they are required due to the way that data are encoded onto the disc. It also has nothing to do with the lead-in, data, lead-out business either. Do these link blocks cause problems for CD-ROM's? Some, but MultiRead is supposed to mandate the ability to deal with them.
So how does this all apply? When using CD-R, DirectCD will write into the data area of the open session, appending packets as needed. In this state there is no lead-in or lead-out so a CD-ROM cannot read the disc. When the disc is converted to ISO-9660 format, we write the ISO image to the disc and close the session. We could simply close the session and still be readable on a CD-ROM because all a CD-ROM cares about is the lead-in, data, and lead-out. Nobody could get anything useful from it without a reader, but the drive would be happy. ISO 9660 is useful because of the wide availability of ISO readers. In the case of CD-RW, we actually format for all the data and close the session right in the beginning. That is why it is readable (in theory anyway) from the start. With both CD-R and CD-RW, the file system is written into the data area of the disc, but with RW the session containing the data is closed and therefore readable on a MultiRead CD-ROM.
With DirectCD, data are written in discrete units (packets) that may be as large the recording drive's buffer. Because of the way data are encoded onto a CD, each packet is proceeded by a series of blocks (link and run-in) and followed by a couple of blocks (run-out). One way of visualizing this is to think of the packet being encased in some "insulation". The net result is that there are some additional blocks between consecutive packets of data. For example, if we have to write a 3-megabyte file on a drive with a 1-megabyte buffer, the data will likely end up written in three discrete pieces or packets, each packet being one megabyte in size and each pair being separated by the linking blocks. In order to read the data correctly, the reading software must be able to skip over the linking blocks that separate each packet. MSCDEX cannot do this. It assumes that all files will be written in one continuous extent. When it encounters files written in multiple pieces it tries to report them as multiple files. The Win95 and WinNT readers are able to skip ahead as needed. This is really the distinction between ISO level 1 and level 3. In level 3, the files can be in different pieces (multi-extent) while in level 1 the files must be single extent.
Another wrinkle added by a file system implementation is that we are able to handle multiple threads of execution writing at the same time. This means that we may have data interleaved on the disc as a result of receiving interleaved data from the operating system. This would also require multiple extents. Finally, the fixed packet size used for RW is 64K or 32 blocks (blocksize=2K). Including the link blocks and the total amount written becomes 39 blocks (1 link, 4 run-in, 32 data, 2 run-out) or 78K. This is also why there is so much overhead for direct overwrite on RW media, approximately 18% waste!
E-mail me at cdrecording@mrichter.com
Return to Mike's home page