cd_read_side.jpg (8K)

Chip's CD Media Resource Center:

Image from Disctronics

Sectors, Sections & Digital Data Tracks

The data for digital audio tracks on a CD-ROM is identical to what we discussed in the section on CD-DA. A digital audio track is a stream of bytes representing 16-bit sample values for the two (R & L) channels every 1/44100th of a second. There is nothing in the data stream itself to describe the structure of the music tracks -- that is taken care of through the p & q subcode channels.

But digital data tracks do have structure, based on a unit called a sector. "A Sector is the smallest addressable part of the information area that can be accessed independently" [ECMA-130 section 14]. A sector contains 98 frames. The frames themselves are the same as was described in the CD-DA section -- each frame of 588 channel bits contains a "payload" of 192 data bits, or 24 data bytes. Thus there are 24*98 = 2352 data bytes in a sector.

I'll note once again that "sectors" aren't the same as subcode blocks or Sections , even though each contain 98 frames. The difference between a "Sector" and a "Section" is simply that sections are ansynchronous from sectors. That is, sections may spill across sector boundaries. While this seems needlessly confusing, you'll be pleased to know that the reason is "because the mapping of a Sector on the Sections during recording is implementation-dependent due to the freedom left in clause 16," [ECMA-130, clause 21]. The aforesaid clause 16 defines the interleaving of sector data across multiple frames.

Each sector begins with a 12-byte sync field. The sync field always contains the same pattern: 00 FF FF FF FF FF FF FF FF FF FF 00. I was puzzled by the purpose of this field until it occurred to me that the basic CD hardware, designed to support digital audio, is just delivering a stream of bytes. Unlike a conventional disk drive, the CD drive has no physical concept of a sector to be read. Therefore I suppose that the drive firmware or driver uses the sync field to sync up with the 2352-byte sector boundaries. I wonder why a subcode channel wasn't used for this purpose.

Following the 12-byte sync field is a 4-byte header. The first three bytes of this header contain the sector address, and the fourth byte contains a number which defines the sector mode. Currently only modes 00, 01 and 02 are defined.

Interpretation of the remaining 2336 bytes of the sector depends on the sector mode.

sectormode00.gif (4K)
Above: Sector mode 00, ECMA-130
sectormode01.gif (6K)
Above: Sector mode 01, ECMA-130
sectormode02.gif (4K)
Above: Sector mode 02, ECMA-130
EDC, P-parity and Q-parity

The most interesting sector mode for CD-ROM is 01, in which the amount of user data is reduced to a computer-friendly 2048 bytes, and the remaining 288 bytes used to enhance the existing CIRC error detection and correction. The 4-byte EDC (Error Detection Code) field is a simple CRC (cyclic redundancy check) computed over all the bytes in the sector up to that point (bytes 0 through 2063). That is, the EDC field is computed on the sync bytes and sector header as well as the user data.

After the EDC field, the Intermediate field is just padding consisting of 8 bytes of zeroes, occupying bytes 2068 to 2075

The P-parity field in the sector is completely separate from the P-parity used in building in the frames, nor, of course, should it be confused with the P subchannel. The function names P and Q are apparently standard in the literature of error correcting codes. The P-parity field occupies 172 bytes in positions 2076 to 2247. It is computed on bytes 12 to 2075. So the 12 sync bytes are excluded, but the sector header and the EDC (and even the Intermediate field) are included.

The Q-parity field consists of 104 bytes immediately following in bytes 2248 through 2351, the last byte of the sector. It is computed on bytes 12 through 2047, so it provides protection over the P-parity field as well as everything else.

P- and Q-parity in the sector are computed using a Reed-Solomon Product-like Code (RSPC). Details are in Annex A of ECMA-130. For some reason I've always disliked the study of error correcting codes and must confess that the bare specification made very little sense to me.

Last Updated Monday October 15, 2001 17:58:31 PDT