Media Descriptor File (MDF)

Main article: Ripping games

A Media Descriptor File, consisting of an MDS metadata file and an MDF data file, is a proprietary disc image format originally developed for the Alcohol 120% and Alcohol 52% software. It is designed to be a high-fidelity format capable of storing complex disc attributes, such as subchannel data, layer breaks for dual-layer DVDs, and physical disc characteristics used by copy protection schemes.

Overview

The format is split into two distinct files:

.MDF (Media Data File): Contains the actual raw sector data of the disc. Depending on the ripping settings, this may include the main channel data (2048 or 2352 bytes per sector) and sometimes integrated subchannel data.
.MDS (Media Descriptor Sheet): A binary metadata file that describes the disc's structure, including track positions, sessions, and pointers to the .MDF file. For DVDs, it is critical for storing the exact sector address of the layer break.

Technical Details

Because the MDS format is proprietary and binary, it is not human-readable in a text editor like a .cue file. However, several versions (v1.x and v2.x) have been identified through community research.

MDS File Structure

A standard MDS file typically contains the following blocks:

Header: Contains the "MEDIA DESCRIPTOR" magic string, version info, and the number of sessions.
Disc Information: General attributes like disc type (CD, DVD, etc.).
Session Blocks: Details for each session on the disc.
Track Blocks: Details for each track, including the start address (LBA) and the track mode (e.g., Audio, Mode 1, Mode 2).
Subchannel Pointers: Pointers to the locations of subchannel data if present.

MDF Sector Formats

The .MDF file usually stores data in one of two ways:

2352 bytes/sector (Raw): Captures the full sector including sync patterns and error correction.
2448 bytes/sector (Raw + Subchannel): Captures the 2352-byte sector plus the 96 bytes of subchannel data.

MDF vs. BIN: Technical Distinctions

To the casual user, an .mdf file and a .bin file may appear identical—both are large, raw data blobs. However, the difference lies in how the data is packed and the "intelligence" of the companion descriptor file.

1. Sector Packing and Interleaving

While a standard BIN/CUE typically stores data in 2352-byte sectors (raw data only), an .mdf file often utilizes a 2448-byte sector format.

Interleaving: In a 2448-byte rip, the 96 bytes of subchannel data (P-W subcodes) are "interleaved" directly after each 2352-byte sector.
The Sidecar Difference: In the BIN/CUE ecosystem, these 96 bytes must be stored in a separate "sidecar" file (like .sub or .sbi). In the MDF format, the data is all-in-one.
The Rename Risk: If a user renames a 2448-byte .mdf to .bin, most emulators will fail or exhibit "jittering" because they expect 2352-byte chunks. The software will misalign the data stream almost immediately.

2. Structural vs. Descriptive Metadata

The fundamental difference between an .mds and a .cue file is the type of information they store:

.cue (Descriptive): A human-readable text map. it tells the software "Track 2 starts at this timecode." It describes the logical layout.
.mds (Structural): A binary descriptor. It provides the software with hardware-level structural info, such as precise lead-in/lead-out addresses and DVD Layer Breaks.

3. DPM (Data Position Measurement): Main article: Copy protection

The "Killer Feature" of the MDF/MDS format is its ability to store DPM data. Certain copy protections (like SecuROM) don't just check the bits on the disc; they measure the physical density of the data—essentially the "wobble" of the spiral track.

Alcohol 120% measures this physical characteristic and stores it in the .mds file.
A .bin/.cue rip is "blind" to this physical timing. For high-security games, a .bin/.cue rip will fail the authentication check, even if the data itself is a 100% perfect copy.

Comparison to Other Formats

Main article: Ripping games#Comparison

Conversion and Tools

Some MDFs out there are actually just plain ISO files. In such cases, simply changing the file extension may be enough. If an emulator does not support MDF/MDS, the following tools can be used to convert or manipulate them:

IsoBuster: Can open MDF/MDS files and extract data or convert them to other formats.
mdf2iso: A command-line utility for Linux/Unix to convert MDF images to standard ISO.
iat (Iso9660 Analyzer Tool): Another Linux CLI tool for detecting the structure of many types of CD-ROM image file formats, including MDF, and converting them into ISO-9660. If the --iso option does not produce a valid image, try --cue instead.
Alcohol 120% / 52%: The native software for creating and burning these images.

External Links