This article is from the CD-Recordable FAQ, by Andy McFadden (firstname.lastname@example.org) with numerous contributions by others.
Packet writing is an alternative to writing entire tracks or discs.
It allows you to write much smaller chunks, down to the level of individual
files. With track-at-once recording there's a maximum of 99 tracks per
disc, a minimum track length of 300 blocks, and an additional 150 blocks
of overhead for run-in, run-out, pregap, and linking. Packet writing
allows many writes per track, with only 7 blocks of overhead per write (4
for run-in, 2 for run-out, and 1 for link). Since it's possible to write
packets that are small enough to fit entirely in the CD recorder's buffer,
the risk of buffer underruns can be eliminated.
There are some problems with packet writing, mostly due to the inability of
older CD-ROM drives to deal with the gaps between packets. CD-ROM drives
can become confused if they read into the gap, a problem complicated by
read-ahead optimizations on some models.
There are two basic "philosophies" behind packet writing, fixed-size and
variable-size. With fixed-size packets, the CD recorder writes data
whenever it has a full packet. All packets in the same track must have the
same size. It's relatively easy for a CD-ROM drive to skip over the
inter-packet gaps if it knows where the gaps are ahead of time, but there's
a large installed base of CD-ROM drives that aren't that smart.
With variable-sized packets, the CD-ROM drive can't tell ahead of
time where the gaps are. The problem can be avoided by laying out the
filesystem in such a way that the drive never tries to read from the gaps.
One approach is to put each file into a single packet, but if the size
of a file exceeds the size of the CD recorder write buffer, the risk of
buffer underruns returns. An alternative is to write the file in several
pieces, but the Level 1 ISO-9660 filesystem supported by most operating
systems doesn't support this. Replacing the "redirector" (e.g. MSCDEX)
with one that supports Level 3 ISO-9660 solves the problem.
Files on packet-written discs are typically stored in a UDF filesystem.
When the session is closed -- necessary for the disc to be readable on
anything but a CD recorder -- some implementations will wrap an ISO-9660
filesystem around the disc to make the files accessible on systems without
a UDF reader. When DirectCD for Windows closes a disc in ISO-9660 format,
it uses Level 3 multi-extent files. Support for Level 3 ISO-9660 will
likely be added to future OSs, but for the time being it can be difficult
to share such discs between machines that aren't running Win95/NT.
DirectCD for Mac OS leaves the disc in UDF format, so reading the discs
requires a UDF driver. See section (6-3-1) for more information on UDF,
including a web site where free UDF drivers can be downloaded. (If you
have DirectCD, you don't need to download the drivers separately; you would
only need them if you didn't own packet-writing software and wanted to read
discs created by somebody who did.)
Writing to a CD-R with packets will be slower than writing with standard
premastering software. Since the expected application for packet writing
is "drive letter access" rather than creating an entire CD, this should not
be an issue for most people.
Audio CDs can't be written with packets.
You really don't want to defragment a CD-RW written with fixed packets.
The disc is deliberately fragmented to avoid "wearing out" sectors on
Some early CD recorders were only be able to write to a disc the first 99
times it was placed in the drive, because the recorder has to calibrate
the laser power before writing, and there are only 99 spaces for doing
the test writes. Sony and Philips have developed ways to work around the
problem, such as remembering the last 10 pieces of media seen, so this
doesn't cause problems on current drives.
Information on packet-writing software follows. It is in general a bad
idea to have more than one installed at the same time.