On-disk encoding: frames, sectors, modes and regions

Physical layout described the spiral of pits and lands. This page explains how bytes are turned into that pattern, and how the resulting stream is organised into sectors of different modes, grouped into the lead-in, program area and lead-out. It covers CDs in detail and then DVDs.

Most image formats store sectors, the level described in sections 3–5. Sections 1–2 cover the lower levels that a drive handles itself and that images never contain. They are still worth knowing: they explain where the 2352-byte sector and the 96 bytes of subchannel come from, and why some things (such as the exact alignment of audio) can differ between two dumps of the same disc.

1. The big picture (CD) #

Two parallel streams are recorded together on a CD:

• the main channel: 2352 bytes per sector, either audio samples or a data sector with its own sync, header and error-correction fields; and
• the subchannel: 96 bytes per sector (98 bytes including 2 sync bytes), split into eight 1-bit channels P–W. See Subchannels.

A sector (also called a block, or in audio terms a frame when written as mm:ss:ff) is 1/75 of a second of playing time at 1× speed. All CD addressing counts in these units.

From top (bytes) to bottom (pits), the encoding chain is:

 2352 bytes main data per sector                 96+2 bytes subchannel per sector
          │                                                  │
 (data sectors only) scramble bytes 12..2351                 │
          │                                                  │
 split into 98 small frames of 24 bytes                      │
          │                                                  │
 CIRC encoder: +4 bytes (C2 "Q" parity) → interleave         │
               +4 bytes (C1 "P" parity)  → 32 bytes          │
          │                                                  │
          └──────── + 1 subcode byte per small frame ◄───────┘   (98 frames × 1 byte = 98 bytes)
                          │
                 33 bytes per small frame
                          │
            EFM: each byte → 14 channel bits, + 3 merging bits
            + 24-bit frame sync (+3 merging bits)
                          │
            588 channel bits per small frame
                          │
            NRZI: each "1" = a pit edge → pits and lands

The numbers fit together exactly:

• 98 small frames × 24 bytes = 2352 bytes of main data per sector.
• 98 small frames × 1 subcode byte = 98 bytes. Of these, 2 are sync patterns (S0, S1) and 96 carry the P–W channels: 96 bytes × 8 bits = 8 channels × 96 bits.
• 588 channel bits × 98 frames × 75 sectors/s = 4,321,800 channel bits per second at 1×.

2. From bytes to pits: EFM and frames #

2.1 Small frames (F1 → F2 → F3) #

ECMA-130 names the frame at each stage:

2.2 CIRC: why sectors and subchannel don't line up perfectly #

CIRC (Cross-Interleaved Reed–Solomon Code) is the CD's first, mandatory layer of error correction. It is used on every CD, audio and data alike. Two Reed–Solomon codes are used: C2 (28,24) and C1 (32,28). Between them the bytes are spread out by delay lines of up to 108 frames. A scratch that wipes out a run of consecutive frames on the disc therefore damages only a byte or two of each code word after de-interleaving, and those few errors can be corrected. The details are on the EDC/ECC page.

The interleaving has a consequence for imaging. The main-channel bytes of one sector are physically spread over a stretch of track that is longer than one sector, and they come out of the decoder delayed relative to the subcode bytes, which are not interleaved. The drive has to re-align them. Drives do not all do this identically, so:

• audio read from different drives can be shifted by a fixed number of samples (the drive's read offset, e.g. +6 samples for many drives). Tools like EAC and AccurateRip correct for it;
• subchannel data returned alongside a sector can be off by a sector or so on some drives. Careful dumping tools (Aaru, redumper, DiscImageCreator) detect and correct this.

Data sectors do not suffer from the offset problem in practice: each data sector carries its own sync pattern and address header (section 3), so the drive can locate its start exactly.

2.3 EFM: eight-to-fourteen modulation #

A pit or land must be at least 3 and at most 11 channel bits long (3T–11T). In channel bits, this means every 1 must be followed by at least 2 and at most 10 0s. Arbitrary bytes don't obey this, so each 8-bit byte is replaced by a 14-bit symbol from a fixed table. Of the 16,384 possible 14-bit patterns, 267 satisfy the run-length rule, and 256 of them are used.

Between consecutive 14-bit symbols the encoder inserts 3 merging bits, chosen to:

1. keep the run-length rule valid across the boundary between symbols, and
2. minimise the DC content (the running difference between total pit length and total land length), which keeps the servo and slicer circuits stable.

Each channel frame begins with a 24-bit sync pattern that cannot occur in EFM data (100000000001000000000010, i.e. two 11T runs in a row), followed by 3 merging bits. So:

sync (24) + merge (3) + 33 × (EFM symbol (14) + merge (3)) = 27 + 561 = 588 channel bits

2.4 Subcode sync: where a sector begins #

Of the 98 small frames that make up a sector, the subcode bytes of the first two do not carry P–W data. They hold two special 14-bit EFM patterns, S0 and S1, which lie outside the 256-entry EFM table. The decoder uses them to find the start of each 98-frame subcode block. The remaining 96 subcode bytes are the P–W data. That is why the subchannel is always "96 bytes per sector" in image files.

3. Sectors: the unit images store #

Once the drive has decoded EFM and CIRC, it presents each sector as 2352 bytes of main-channel data. How those 2352 bytes are used depends on the sector's type.

3.1 Audio (CD-DA, Red Book) #

offset  size
0x000   2352  PCM audio: 588 stereo samples, each 2 bytes left + 2 bytes right,
              16-bit signed, little-endian. 44,100 samples/s ÷ 75 = 588.

There is no sync, header, address or sector-level error correction. Every byte is sound. A drive finds its position in audio only through the Q subchannel, which is why reading audio is less exact than reading data, and why the subchannel matters for audio.

Byte order: 16-bit samples are little-endian in the sector as returned by drives and as stored in .bin/.img/.mdf files. The CUE sheet's MOTOROLA file type means a file of big-endian samples, which must be byte-swapped. Raw CD-DA "as on disc" is sometimes described as big-endian. Images follow the drive's little-endian convention.

3.2 Data sectors (Yellow Book / ECMA-130) #

All data sectors begin with the same 16 bytes:

offset  size
0x000   12    Sync pattern: 00 FF FF FF FF FF FF FF FF FF FF 00
0x00C   3     Address: minute, second, frame of this sector, in BCD (absolute time, see LBA page)
0x00F   1     Mode: 00h, 01h or 02h
0x010   ...   (depends on the mode)

The sync pattern lets the drive find the start of a sector in the data stream. The header (address + mode) tells it which sector it has found and how to interpret the rest. The address is the sector's absolute MSF time in BCD (0x12 means 12). For LBA 0 the header is 00 02 00 01: minute 0, second 2, frame 0, mode 1.

The mode byte selects one of the following layouts.

Mode 0 #

0x010   2336  All zero

Mode 0 sectors carry no data. They are rare and sometimes appear in lead-in, lead-out or gaps.

Mode 1 (the common CD-ROM sector) #

offset  size
0x000   12    Sync
0x00C   4     Header (MSF in BCD + mode 01h)
0x010   2048  User data                    ← this is what an .iso contains
0x810   4     EDC: CRC-32 over bytes 0x000..0x80F
0x814   8     Zero (reserved)
0x81C   172   ECC P-parity
0x8C8   104   ECC Q-parity
0x930         (end, 2352 bytes)

Mode 1 spends 288 bytes per sector on extra protection (EDC + reserved + 276 bytes of ECC). This gives data a second, much stronger layer of error correction on top of CIRC. It is enough that a correctly read Mode 1 disc is reliable to roughly one uncorrectable byte in 10¹² or better. See EDC/ECC.

Mode 2 "formless" #

0x010   2336  User data, no EDC/ECC

The original Yellow Book Mode 2 simply gives the 288 protection bytes to the user. It is rarely used in pure form. Its main importance is as the basis for CD-ROM XA.

Mode 2, XA Form 1 and Form 2 (CD-ROM XA / Green Book / White Book) #

CD-ROM XA ("eXtended Architecture") subdivides Mode 2 sectors with an 8-byte subheader. Each sector can then be either Form 1 (protected data) or Form 2 (more payload, less protection). Form 1 and Form 2 sectors can be mixed within one track. That lets audio/video streams (Form 2) be interleaved with program data (Form 1). PlayStation discs, Video CDs, CD-i discs and multisession Photo CDs use XA.

Mode 2 Form 1                          Mode 2 Form 2
offset  size                           offset  size
0x000   12    Sync                     0x000   12    Sync
0x00C   4     Header (mode 02h)        0x00C   4     Header (mode 02h)
0x010   8     Subheader                0x010   8     Subheader
0x018   2048  User data                0x018   2324  User data
0x818   4     EDC (over 0x010..0x817)  0x92C   4     EDC (over 0x010..0x92B), optional (0 = not used)
0x81C   172   ECC P-parity
0x8C8   104   ECC Q-parity

Form 1 is just as well protected as Mode 1, but has 8 fewer bytes of space because of the subheader. Form 2 trades the ECC for 276 extra payload bytes.

One subtle but important difference: for Mode 2 Form 1, the 4 header bytes are treated as zero when the ECC is computed. They are excluded so that the parity does not depend on where the sector ends up on the disc. The EDC also starts at the subheader (0x010) rather than at the sync. (Mode 1's EDC and ECC both include the header.)

The subheader

The 8 subheader bytes are 4 bytes written twice, for redundancy:

byte 0 / 4  File number      Identifies which interleaved "file" this sector belongs to (0 if unused).
byte 1 / 5  Channel number   Sub-stream within the file (e.g. one of several audio channels), 0–31.
byte 2 / 6  Submode          Bit flags, below.
byte 3 / 7  Coding info      For audio/video sectors, describes the encoding (e.g. ADPCM sample rate,
                             mono/stereo). 0 for data.

Submode bits:

A reader that only has the raw sector learns its form from bit 5 of byte 0x012.

3.3 Summary of sector sizes #

These sizes come up constantly, because image formats name tracks by "how many bytes of each sector are stored":

C2 error pointers are one bit per main-channel byte (2352 / 8 = 294 bytes). A drive can return them to flag which bytes CIRC could not correct. They are useful when dumping, but no image format discussed here stores them.

3.4 Raw versus cooked reads #

A drive can return a sector in different ways. MMC's READ CD command lets the host choose which parts of the 2352 bytes it wants (sync, header, subheader, user data, EDC/ECC) and which subchannel format to append. READ(10)/READ(12) return only the 2048 user-data bytes ("cooked"). The drive applies EDC/ECC correction first, and fails the read if the sector is uncorrectable.

An image made from cooked reads (an .iso, or a MODE1/2048 track) cannot reproduce the original sync, header or EDC/ECC exactly. For Mode 1 and Form 1 they can be regenerated, because they are a pure function of the address and data (that is what ECM compression exploits). They cannot be regenerated if the original contained intentional errors, as some copy protections do. Only a raw image preserves those.

4. Scrambling #

Before a data sector is EFM-encoded, bytes 12 to 2351 (everything except the sync pattern) are XORed with a fixed pseudo-random sequence. This is defined in ECMA-130 Annex B. Many data sectors contain long runs of identical bytes, especially zeros. Unscrambled, those runs could produce EFM patterns with a lot of DC content or repeated structure that upsets the drive's tracking and slicing circuits. Scrambling makes the recorded data look random.

The sequence comes from a 15-bit linear feedback shift register with polynomial x¹⁵ + x + 1, preset to 0x0001 at the start of every sector. The output is taken least-significant bit first. This is libmirage's implementation, which builds a 2340-byte table, one byte for each of bytes 12–2351:

// lib/cdemu/libmirage/mirage/utils.c, mirage_helper_init_ecma_130b_scrambler_lut()
uint16_t fsr = 1;
for (int i = 0; i < 2340; i++) {
    uint8_t value = 0;
    for (int j = 0; j < 8; j++) {
        uint8_t lsb = fsr & 1;       // output bit
        value |= lsb << j;
        fsr >>= 1;
        if ((fsr & 1) ^ lsb)         // feedback: x^0 XOR x^1 goes into x^14
            fsr |= 0x4000;
        else
            fsr &= 0x3FFF;
    }
    lut[i] = value;                  // sector[12 + i] ^= lut[i]
}

The first few table bytes are 01 80 00 60 00 28 00 1E 80 08 ....

Notes:

• Audio sectors are not scrambled.
• Drives descramble data sectors automatically, so images normally contain unscrambled sectors. CloneCD's DataTracksScrambled=1 (see IMG/CCD/SUB) and some preservation dumps (redumper's .scram files) store the scrambled form instead. That can matter for copy protection and for dumping discs whose data tracks are read with audio commands.
• Scrambling is its own inverse: applying the same XOR again restores the original.

5. Regions in addressing terms (CD) #

The physical layout page described the lead-in, program area and lead-out by radius. Here is the same structure as the drive sees it through sector addresses and the Q subchannel.

5.1 Lead-in #

• Lies just before the program area. Its sectors have negative LBAs. In MSF terms the lead-in typically starts somewhere in the 90s of minutes (for example 97:2x:xx) and counts up to 99:59:74, after which the program area's 00:00:00 follows. The LBA page explains this wrap-around.
• Its Q subchannel repeats the Table of Contents over and over. Each Q entry describes one track (POINT 01–99) or one special item (POINT A0, A1, A2, and on multisession/recordable discs B0, C0, ...). Each entry is repeated three times in a row. See Subchannels.
• On audio discs the main channel is digital silence. On data discs it is typically data sectors filled with zeros, in the mode of the first track.
• CD-TEXT, if present, is carried in the R–W subchannels of the lead-in.
• Normal read commands cannot access it. Drives read the TOC from it when the disc is inserted and report it through READ TOC. Only specialised firmware or "lead-in reading" tricks can dump the lead-in itself. No common image format stores lead-in sectors. Instead, they store the TOC derived from it (MDS data blocks, CCD [Entry] sections).

5.2 Program area #

• Starts at absolute time 00:00:00. The first 150 sectors (00:00:00–00:01:74, LBA −150 to −1) are the pregap of track 1 (index 0). Track 1's data (index 1) starts at 00:02:00 = LBA 0.
• Contains the tracks, 1 to 99 of them, each with indexes (index 0 = pregap, index 1 = start of content, 2–99 = optional subdivisions). See Tracks.

5.3 Lead-out #

• Begins immediately after the last track. Its start address is the TOC's A2 pointer, which is also the "end of disc" used to compute the last track's length.
• Its Q subchannel has track number AA (hexadecimal; 0xAA is not valid BCD, which makes it unambiguous) and index 01.
• Its main channel is silence (audio discs) or data sectors (data discs, in the last track's mode).
• It is at least 6,750 sectors (90 s) long on a single-session disc, and shorter for later sessions of multisession discs (see Sessions). Its purpose is partly practical: it gives a player that overshoots the last track something sensible to read.
• Drives may let you read a few lead-out sectors. Images don't store it. A reader recreates it if needed.

5.4 What image formats keep #

          lead-in     │ pregap T1 │ track 1 ... track N (incl. their pregaps) │ lead-out
LBA:     < −150       │ −150..−1  │ 0 ......................................  │ A2 ...
-----------------------------------------------------------------------------------------------
.iso        –               –        track 1 user data only (Mode 1 / Form 1)       –
.bin/.cue   –        only if INDEX 00/PREGAP style says so    all tracks           –
.mdf        –               –        all tracks (some pregaps omitted, see page)   –
.img        –               –        all tracks incl. later pregaps                –
TOC data   (MDS/CCD store the decoded TOC entries; CUE implies them)

6. DVD encoding #

DVD uses the same general ideas (modulation, interleaving, Reed–Solomon) with different parameters, and with simpler logical structure: every sector carries exactly 2048 bytes of user data and there are no sector modes.

6.1 Data frame (2064 bytes) #

offset  size
0x000   4     ID: 1 byte sector information + 3 bytes Physical Sector Number (PSN)
0x004   2     IED: Reed–Solomon check bytes protecting the ID
0x006   6     CPR_MAI: copyright management information (CSS/CPRM flags, region...)
0x00C   2048  Main data (user data)            ← this is what an .iso / .mdf stores
0x80C   4     EDC: CRC-32 over bytes 0x000..0x80B
0x810         (end, 2064 bytes = 12 rows × 172 bytes)

The sector information byte packs: sector format type, tracking method, reflectivity (≤ 40% means a dual-layer disc), zone type (data / lead-in / lead-out / middle area), data type (read-only / other) and layer number (0 or 1). The PSN is a 24-bit sector number (data area starts at 0x030000). Unlike a CD header it is binary, not BCD.

After the EDC is computed, the 2048 main-data bytes are scrambled by XOR with the output of a 15-bit LFSR (x¹⁵ + x⁴ + 1). One of 16 different starting values is chosen from bits 7–4 of the PSN, so neighbouring sectors get different patterns.

6.2 ECC block (16 sectors) #

DVD error correction does not work per sector. 16 consecutive data frames are stacked into a matrix of 192 rows × 172 bytes and protected by a Reed–Solomon product code (RS-PC):

• each of the 172 columns gets 16 bytes of outer parity, PO: RS(208,192). This adds 16 rows, for 208 rows;
• each of the 208 rows gets 10 bytes of inner parity, PI: RS(182,172). This adds 10 columns, for 182 columns.

Total: 208 × 182 = 37,856 bytes per ECC block, of which 16 × 2048 = 32,768 are user data. Details are on the EDC/ECC page.

This is why DVD capacities and layer sizes come in multiples of 16 sectors. In the Empire Earth III example on the MDS page, the two layers differ by exactly one ECC block (16 sectors). It is also why the smallest unit a DVD drive can write is 32 KiB.

6.3 Recording frames and physical sectors #

The 16 PO rows are distributed one per sector, so each sector becomes a recording frame of 13 rows × 182 bytes = 2,366 bytes. Each 182-byte row is split into two halves of 91 bytes. Each half is EFMPlus-modulated (8 bits → 16 channel bits) and preceded by a 32-channel-bit sync code (SY0–SY7, chosen to mark the position within the sector). That gives 26 sync frames of 32 + 91 × 16 = 1,488 channel bits each. One physical sector is therefore 26 × 1,488 = 38,688 channel bits.

EFMPlus keeps CD's 3T–11T run-length rule (plus a 14T run reserved for the sync codes). It maps 8 bits to 16 directly, with no merging bits; a finite-state machine with four states chooses among alternative code tables to control DC content. It is about 6% more efficient than EFM's 17 channel bits per byte.

6.4 Lead-in contents: PFI, DMI and friends #

The DVD lead-in's control data zone holds 192 copies of a 16-sector control data block:

Other structures a drive reports include copyright information (format 01h, 4 bytes: copy protection system type such as CSS/CPPM, plus region management information), the disc key (02h, CSS), and the BCA (03h). Alcohol's MDS stores copyright info, DMI and PFI for each layer, plus the BCA. Most other formats store none of them.

Sources #

• ECMA-130, CD-ROM, especially §14–§16 (sector structure, modes), §18–§22 (CIRC, EFM, frames) and Annex B (scrambler). https://ecma-international.org/publications-and-standards/standards/ecma-130/
• ECMA-267, DVD-ROM: data frame, scrambling, ECC block, recording frame, EFMPlus, control data zone. https://ecma-international.org/publications-and-standards/standards/ecma-267/
• T10 MMC-6 draft: READ CD (sector field selection, C2 pointers), READ DISC STRUCTURE formats. https://www.t10.org/drafts.htm
• libmirage source: lib/cdemu/libmirage/mirage/utils.c (sync pattern, scrambler, sector type detection), lib/cdemu/libmirage/mirage/sector.c (sector layouts per mode and stored size).
• Wikipedia, "Eight-to-fourteen modulation": https://en.wikipedia.org/wiki/Eight-to-fourteen_modulation
• Wikipedia, "CD-ROM" (sector modes, XA): https://en.wikipedia.org/wiki/CD-ROM
• Wikipedia, "EFMPlus": https://en.wikipedia.org/wiki/EFMPlus
• psx-spx, "CDROM Disk Images CUE/BIN/CDT" (stored byte ranges per track type): https://problemkaputt.de/psxspx-cdrom-disk-images-cue-bin-cdt-cdrwin.htm