Alcohol 120% MDS/MDF disc image format

Alcohol 120% (Alcohol Soft, early 2000s) stores a disc as two files:

• .mdf ("media data file"): the sector data, optionally with subchannel data appended to each sector;
• .mds ("media descriptor"): a small binary file describing the disc. It holds the medium type, sessions, the full TOC, track layout and file offsets, and for DVDs the physical format structures and BCA. It can also carry a DPM table measured from the original disc.

The format was never published. Everything here comes from reverse engineering:

1. Our own sample analysis (Quake, a Mixed Mode CD; Deus Ex, a data CD; Empire Earth III, a dual-layer DVD; and a single-layer DVD). Facts that come only from these samples are marked (samples).
2. libmirage, the CDEmu image library: lib/cdemu/libmirage/images/image-mds/.
3. Aaru, which reads and writes the format: lib/Aaru/Aaru.Images/Alcohol120/.
4. psx-spx / no$psx documentation by Martin Korth: https://problemkaputt.de/psxspx-cdrom-disk-images-mds-mdf-alcohol-120.htm.

Where these sources disagree, both views are given.

The same MEDIA DESCRIPTOR container, at version 1.x, is also used by GameJack (.xmd). DAEMON Tools' later MDS v2 / MDX format (version 2.x) is different: its descriptor is compressed and encrypted (see the appendix).

Conventions. All multi-byte integers are little-endian. Track, point, session and index numbers and MSF values are binary, not BCD. Offsets are in bytes from the start of the .mds file unless stated otherwise. Fields shown as "zero" were zero in all samples and in files written by Aaru. Their meaning is unknown.

File.MDF

The MDF holds the sector data: each sector is stored at 2048 to 2352 bytes, optionally followed by 96 bytes of subchannel data. The sector size is a per-track field in the MDS (data block 10h). It already includes the 96 subchannel bytes when subchannel is present.

Sector sizes seen:

What is stored #

• DVD: sectors start at LBA 0 and run to the end of the data area. On a dual-layer disc, layer 1 follows layer 0 directly.

• CD: the image starts at LBA 0 (MSF 00:02:00). The first 150 sectors (LBA −150..−1, track 1's pregap) are not stored.

• CD pregaps of later tracks (samples): the 150-sector pregap (index 0) of the first audio track after a data track was also not stored. In a Mixed Mode disc every track after track 1 therefore sits 150 sectors earlier in the MDF than its PLBA suggests:

  Track 1 start offset       = 0
  Track N (N>1) start offset = (PLBA − 150) × sector size      (Quake)
  

  The total MDF size on a CD equalled the sum of all tracks' index-1 lengths × sector size. For Quake that is 319,611 sectors × 2448 = 782,407,728 bytes, which matched the file size exactly.

How the readers handle pregaps. The libraries disagree, so a converter should use each track's explicit start offset (data block 28h) and index-1 length rather than assume a layout:

• libmirage assumes pregaps are never stored. It inserts an empty ("NULL") fragment of pregap sectors before each track and reads index 1 from start_offset. This matches the samples.
• Aaru assumes the pregap sectors are stored immediately before start_offset: it reads a pregap sector at start_offset − pregap × sector_size. Its writer lays files out that way, except for track 1, whose pregap it never writes. On an image like Quake this would read the end of track 1 as track 2's pregap. Aaru also has a special case for "faulty UltraISO" MDS files, which set track 1's pregap wrongly.

Split MDF files. A track's data can be spread over several files (data block 30h, "number of filenames", > 1). libmirage treats this as consecutive fragments, assumes splits fall on sector boundaries, and works out each fragment's length from its file size. The start offset applies only to the first file. (not observed)

Subchannel data #

When present (data block 01h = 8, sector size 990h), the 96 subchannel bytes follow each 2352-byte sector in interleaved ("raw P–W") order: each byte holds one bit from each of the eight subchannels.

Bit7..0 = Subchannel P..W (in that order, e.g. Bit6 = Subchannel Q)

1st..8th bit of each subchannel   = Bit7..Bit0 of bytes 0..7 (MSB first)
9th..16th bit                     = bytes 8..15
...

This is the opposite of CloneCD's .sub, which is linear (12 bytes of P, then 12 of Q, …). Conversion code is on the Subchannels page.

File.MDS: layout

An MDS file consists of these parts, normally in this order and without gaps:

Header                      (58h bytes documented; first structure at 58h or 60h)
Disc structures             (DVD only; one 1004h-byte slot per layer)
BCA data                    (DVD only, optional; position given in the header)
Session block(s)            (24 bytes each)
Data blocks                 (80 bytes each; per session: lead-in entries, then tracks)
Index blocks                (CD only; 8 bytes per data block)
Filename block(s)           (16 bytes each; usually one, shared by all tracks)
Filename string(s)          (usually one: "*.mdf")
Disc metadata blocks        (optional: DPM, read-error list)

Every part is located through an offset in an earlier part, so readers should follow offsets and not assume positions.

Typical offsets (samples):

(psx-spx gives 58h/70h for CDs; our samples had 60h/78h. Both are valid, since the header gives the session block's offset.)

Header #

Notes:

• Aaru maps all CD-like media (CD-DA, CD-ROM XA, PlayStation, …) to 00h, all writable DVD types (±R, ±RW, DL) to 12h, and everything else to 10h. libmirage accepts only the five values in the table.
• Aaru treats DVD-R as a DVD regardless of the PFI's own disc category.

No sample contained a BCA.

Session blocks (24 bytes) #

Lead-in block count (0Bh). On a single-session CD this is 3 (A0, A1, A2). On a multisession CD it also counts the ADR 5 entries (B0, C0) in that session. (samples) It was 3 even on DVDs, which have only one data block and no A0–A2 blocks. This looks like an Alcohol quirk and is safe to ignore.

Gaps between sessions. libmirage computes the length of the lead-out/lead-in/pregap gap after session n as start(session n+1) − end(session n). This uses only the session blocks; the MDF doesn't store the gap.

Data blocks (80 bytes) #

One data block per TOC entry.

• CD: each session has one block per lead-in entry (Points A0h, A1h, A2h, and on multisession/recordable discs B0h, C0h, …), followed by one block per track in track order. In samples, A0–A2 came first.
• DVD: a single block for "Point 1", with no A0h–A2h blocks.

Bytes 02h–0Bh are a direct copy of an MMC READ TOC Full TOC descriptor (bytes 1–10: ADR/Control, TNO, POINT, Min, Sec, Frame, Zero, PMIN, PSEC, PFRAME; see Subchannels §5.3). The rest is Alcohol's own track description.

For Point ≥ A0h, bytes 0Ch–4Fh are zero, and the track mode is 00h. Aaru does give lead-in blocks an index-block offset; libmirage ignores it.

Meaning of the MSF fields #

Aaru's writer, when it has no real TOC, synthesises B0h as ADR/Control 50h with the next session's address, and C0h as 50h with Min = 128 and PMIN:PSEC = 97:25 (a placeholder ATIP manufacturer code).

ADR/Control on lead-in blocks (samples): 14h on a data CD (Deus Ex), but 10h on a Mixed Mode CD (Quake) whose track 1 is 14h. Aaru writes A0h and A2h with the first track's control, and A1h with the last track's control. On Quake the last track is audio, so A1h is 10h. The 10h on Quake's A0h/A2h suggests Alcohol copies the drive's raw TOC, whatever it reports.

Track mode #

libmirage's author hex-edited this byte and fed it to Alcohol. Only the low nibble had any effect:

The values actually seen in files:

The high nibble is thus either A or E. Bit 6 (40h) has no effect in Alcohol according to libmirage. psx-spx associates ECh with subchannel-carrying Mode 2 tracks, but the subchannel mode byte (01h) already says that. Aaru writes ECh/EDh for Form 1/Form 2 and flags images containing ACh as written by an older, incorrect writer. Readers should decode the low nibble only, as libmirage does. Writers aiming for maximum compatibility should probably use ABh for raw Mode 2 tracks.

For A9h and AAh, the sector size field (930h vs 990h) and the subchannel byte agree on whether subchannel is stored.

Index blocks (CD only, 8 bytes) #

libmirage calls this the "track extra block". There is one index block for every data block, including dummy all-zero blocks for A0h–A2h, which come first; the track index blocks follow in track order. Each data block's 0Ch field points to its own.

Rules seen in the samples:

• Index 0 is 150 for track 1 and for the first audio track following a data track, and 0 for other tracks. Only the track 1 and data→audio cases were observed.
• Index 1 of track 1 is the length of its stored data: from PLBA 0 to the start of the next track, minus the next track's pregap.
• For consecutive tracks: PLBA(N) + index1(N) = PLBA(N+1) − index0(N+1). In other words the "length" field excludes the following pregap, which is why the MDF has no room for it.

Aaru's writer follows the same rules: the first track gets pregap 150, a track whose mode differs from the previous track gets pregap 150 (taken off the previous track's length), and other tracks get 0.

Alcohol stores only index 0 and index 1. Indexes 2+ are lost unless the subchannel is stored.

DVD images have no index blocks. Their data block 0Ch holds the length instead.

Filename blocks (16 bytes) #

All tracks normally share the same filename block (their 34h fields point to the same place). A track with n filenames has n consecutive filename blocks.

Filename strings #

"*.mdf",00h        (8-bit:  6 bytes)
"*.mdf",00h,00h    (16-bit: 12 bytes, UTF-16LE)

This is the name of the sector-data file. *.mdf is a wildcard meaning "same base name as this .mds, with the extension .mdf". libmirage implements it as a regex (\*\.(\w+) → replace the .mds file's extension with the captured one). A literal filename is resolved relative to the .mds file. Aaru always writes *.mdf in UTF-16 ("Yup, Alcohol stores no filename but a wildcard").

DVD-specific structures

Disc structures #

The region starting at the offset in header field 40h holds copies of the DVD's lead-in control structures, as read with MMC READ DISC STRUCTURE. It is made up of 1004h-byte (4,100-byte) slots: one for a single-layer disc, two for a dual-layer disc.

Within each slot, per libmirage:

Aaru reads the same slot slightly differently. It treats bytes 000h–003h as the 4-byte READ DISC STRUCTURE response header of the DMI (its writer emits 08 02 00 00, i.e. length 0802h), then the DMI, then the PFI at 804h. Both agree on where DMI and PFI are. For the first 4 bytes, libmirage's "copyright info" reading fits the 4100-byte slot size (4 + 2048 + 2048) best. Aaru notes "TODO: CMI" and does not use them.

(samples) The first 804h bytes were all zero in every sample (pressed discs commonly have an empty DMI and no copy protection). On the dual-layer disc, the two PFI copies were identical.

libmirage decides whether a second slot exists from the PFI's layer-count bits. Aaru reads only the first slot ("TODO: Second layer").

PFI (Physical Format Information) #

The multi-byte PSN fields are big-endian (MMC/ECMA convention), unlike the rest of the MDS.

Aaru warns that Alcohol has been seen changing the disk category and part version in the stored PFI (for example, recording a DVD-R as DVD-ROM), "so much for archival value". So don't trust the PFI's category byte to tell you what the original medium was. The header's medium type is no more reliable.

Geometry #

• Layer 0 contains end(layer 0) − 030000h + 1 sectors.
• Total sectors = session end sector = the data block's length field (0Ch).
• MDF sector 0 corresponds to physical sector 030000h.
• On an opposite-track-path disc, layer 1 starts at physical sector FFFFFFh − end(layer 0). The layer break is at an LBA equal to the layer 0 sector count. Worked conversions are on the LBA page.

Empire Earth III (dual layer) (samples):

The layer sizes differ by one 16-sector ECC block.

The single-layer sample used 01 02 01 00: single layer, embossed, 0.267 µm/bit, data area 030000h..17C1DFh, 1,360,352 sectors in total.

BCA #

If header field 1Ah (BCA length) is non-zero, the raw BCA data (up to 188 bytes on DVD) is stored at the offset in header field 24h. libmirage exposes it as disc structure 03h. Aaru's writer places it between the disc structures and the session blocks. (not observed)

Disc metadata blocks (DPM and others)

Header field 54h points to a small directory of optional blocks:

At the offset in header field 54h:
  00h  4      Number of blocks (N)
  04h  4*N    Offset of each block (from start of the .mds)

Each block starts with a 4-byte block type. Aaru: "This value indicates what kind of block it is. DPM is 01. Other, non-DPM block types have been observed, but their purpose is currently unknown." libmirage loads only the first block. Aaru loads it only if its type is 1.

DPM data #

DPM (Data Position Measurement) is a physical fingerprint of the original disc. It records the angular position of sectors as the disc turns, sampled every resolution sectors. Because of CLV (Physical layout §3), a revolution holds more sectors at the edge than at the centre, so the curve flattens toward the outside. Its exact shape depends on the pressing. Copy protections such as SecuROM and StarForce measure it to tell an original from a copy, and emulators (DAEMON Tools, Alcohol, CDEmu) use the stored table to fake the right timing. Alcohol measures it when imaging with the right options; not all images contain it.

Structure (block type 1) #

00h  4      Block type (1 = DPM)
04h  4      Start sector (0)
08h  4      Resolution (sectors per entry)
0Ch  4      Number of entries (E)
10h  4*E    Entries (32-bit unsigned)

(samples) The DPM data was the last thing in the file, and the main block ended exactly at end of file.

Entries #

(samples, with Aaru's interpretation)

• The resolution is 50 sectors for CD and 256 for DVD. Aaru's comment: going lower than 50, Alcohol's minimum, "you start losing precision since cumulative hex angles are only stored as uint32".
• The entry count × resolution just covers the disc (for example Deus Ex: 6,544 × 50 = 327,200 for a 327,274-sector disc).
• Entries increase monotonically. They are cumulative angles: the total rotation from the start sector up to each sample point.
• The first entry is about one interval's worth of rotation, so entry k probably describes sector (k+1) × resolution. (unconfirmed)
• The difference between successive entries shrinks as the radius grows. For CD it falls from about 1,316 to 582; for the single-layer DVD from about 2,252 to about 1,159.
• A rough check suggests the counter ticks about 256 times per revolution. (unconfirmed)
• On a dual-layer disc the table is a single block over both layers. The per-entry increments form a V shape: they shrink through layer 0, jump slightly at the layer break (1274 to 1279 in Empire Earth III, at sector 1,187,040 / 256 = 4,636.9), and then grow again across layer 1 as it spirals back toward the centre.

Second block: probably a read-error list #

One CD sample (Deus Ex) had a second block with header 2, 4, 1, 1 followed by a single value, 327,270 (= session end − 4).

psx-spx describes a "read errors" structure at the header-54h offset with fields "unknown (1), offset, unknown (2), unknown (7), unknown (1), number of read errors (E), E × LBA". That reads as a block directory followed by a type 2 block listing the LBAs of sectors Alcohol could not read. On that reading, Deus Ex's block (type 2, then 4, 1, count 1) lists one unreadable sector at LBA 327,270, near the very end of the disc where TAO run-out or a damaged edge would cause read errors. The meaning of the middle fields (4 vs. psx-spx's 7, and 1) is unknown. psx-spx also mentions that "additional data may include hundreds of kilobytes of text strings or zero-filled blocks" in some files.

Converting MDS/MDF

A recipe for turning an MDS/MDF into a disc model (or into CUE/BIN or CCD):

1. Check the signature, and that the major version is 1.
2. Read the header, then each session block in order from 50h.
3. For each session, read num_all_blocks data blocks from 14h. Separate track blocks (Point 1–99) from lead-in blocks (≥ A0h). The lead-in blocks give A0 (disc type), A1, A2 and any B0/C0, which is enough to rebuild a Full TOC (for CCD [Entry] sections).
4. For each track block:
   • mode ← low nibble of 00h; control ← low nibble of 02h; ADR ← high nibble;
   • sector size ← 10h; if 01h = 8, the last 96 bytes of each sector are interleaved subchannel;
   • CD: pregap, length ← index block at 0Ch. DVD: length ← 0Ch;
   • index 1 at LBA 24h, at byte 28h in the MDF; pregap sectors are not in the MDF (samples, libmirage);
   • filename ← filename block at 34h (handle *.ext wildcards and UTF-16).
5. Session gaps: start(next session) − end(this session).
6. DVD: read the PFI at structure slot + 804h for layer info. Keep DMI, copyright info and BCA if the output can hold them (only MDS can).
7. DPM: copy it if the output is MDS; otherwise it is lost.

Appendix A: MDS v2 / MDX (DAEMON Tools)

DAEMON Tools 4.x and later write descriptors that start with the same MEDIA DESCRIPTOR string, but with major version 2. libmirage handles them in a separate parser (lib/cdemu/libmirage/images/image-mdx/):

00h  16  "MEDIA DESCRIPTOR"
10h  1   Major version: 2
11h  1   Minor version: 0 or 1
12h  26  Copyright string: "(C) 2000-2010 DT Soft Ltd." (minor 0) / "(C) 2000-2015 Disc Soft Ltd." (minor 1)
2Ch  4   Offset to encryption header (MDS v2), or FFFFFFFFh (MDX: descriptor embedded in the data file)

The descriptor that follows is zlib-compressed and encrypted (AES-based, XTS mode, in a TrueCrypt-style 512-byte header with a PKCS#5 salt and a TRUE magic value). The data file may itself be encrypted or compressed. Once decrypted, the descriptor resembles a v1 MDS. It is out of scope here; the libmirage source is the best reference.

Appendix B: Missing / unknown data

• CD-TEXT: no known storage. The lead-in isn't stored, so it is probably lost. Aaru's capability flags claim CD-TEXT/MCN/ISRC support, but its Alcohol code never reads or writes them.
• MCN / ISRC: no dedicated fields. They survive only inside stored subchannel data (Q ADR 2/3 frames).
• The meaning of header 16h (= 2) and data block 12h (= 2 on CD). Both are required by DAEMON Tools according to Aaru, but their meaning is unknown.
• The meaning of bit 6 in the track mode byte (Ax vs Ex).
• Whether other disc structures (BCA, or non-zero copyright info and DMI) appear in images of protected or recordable DVDs.
• The ADR/Control byte of A0h..A2h blocks (copied from the drive's TOC, or computed?).
• Whether pregaps other than track 1's and the data→audio one are ever stored in the MDF, and how an emulator should synthesise the missing pregaps (silence for audio; zero-data sectors in the track's mode for data).
• The exact DPM units, and the middle fields of the type 2 (read error) block.
• Media types other than the five listed, and track modes marked not observed.

Sources #

• Our own sample analysis (Quake, Deus Ex, Empire Earth III, one single-layer DVD).
• libmirage lib/cdemu/libmirage/images/image-mds/image-mds.h and parser.c (structures, track mode experiment, disc structures, BCA, DPM, filename wildcard); image-mdx/image-mdx.h (MDS v2/MDX).
• Aaru lib/Aaru/Aaru.Images/Alcohol120/Structs.cs, Enums.cs, Read.cs, Write.cs, Helpers.cs (field names, alternative track modes, DAEMON Tools compatibility values, DPM, PFI/DMI layout, B0/C0 synthesis).
• psx-spx, "CDROM Disk Images MDS/MDF (Alcohol 120%)": https://problemkaputt.de/psxspx-cdrom-disk-images-mds-mdf-alcohol-120.htm
• Wikipedia, "Media Descriptor File": https://en.wikipedia.org/wiki/Media_Descriptor_File
• T10 MMC-6 draft (READ TOC Full TOC descriptor; READ DISC STRUCTURE formats 00h/01h/03h/04h). https://www.t10.org/drafts.htm
• ECMA-267 §3.3 / Annex (Physical format information field definitions). https://ecma-international.org/publications-and-standards/standards/ecma-267/