BIN/CUE (.bin + .cue)

BIN/CUE is the most widely supported multi-track CD image format. It has two parts:

  • one or more data files (usually .bin) containing sectors back to back, with no header;
  • a plain-text cue sheet (.cue) that says which file holds which tracks, what type each track is, and where each track and index begins.

The cue sheet format was created by Golden Hawk Technology for its CDRWIN burning software (1990s). The name comes from the SCSI-3/MMC SEND CUE SHEET command, which a burner uses to tell the drive the disc layout before a Disc-At-Once write. The text format is a human-readable version of that idea. There has never been a formal standard. The de facto reference is the CDRWIN user manual's appendix, and many programs (EAC, cdrdao, Redump, ImgBurn, IsoBuster, foobar2000) have added their own extensions, mostly through REM comments.

1. The data file(s) #

A .bin file is just sectors:

  • one fixed sector size per track, set by the TRACK type (section 3.2), e.g. 2352 for AUDIO and MODE1/2352, or 2048 for MODE1/2048. Different tracks in the same file can have different sizes;
  • no header and no gaps except those the cue sheet says are in the file;
  • in practice almost always raw 2352-byte sectors, so that one file can hold Mixed Mode discs and the data tracks keep their sync, headers and EDC/ECC.

The first 150 sectors of the disc (track 1's pregap) are normally not in the file. The file starts at LBA 0, unless the cue sheet has INDEX 00 on track 1, which is used for hidden-track audio.

Audio sectors are 16-bit little-endian stereo PCM, as returned by drives. The MOTOROLA file type means big-endian samples.

Two layouts are common:

  1. Single file: one .bin holds every track. CDRWIN, ImgBurn, IsoBuster and older rippers produce this.
  2. One file per track: Game (Track 01).bin, Game (Track 02).bin, … This is the Redump standard, used for preservation and by most emulators. It makes per-track checksums possible.

2. Cue sheet syntax #

  • One command per line. Leading whitespace is ignored (indentation is conventional only).
  • Keywords are case-insensitive in most parsers, but are written in upper case.
  • Arguments containing spaces are enclosed in double quotes.
  • Times are mm:ss:ff (75 frames per second). In a cue sheet, times are positions within the current file (or lengths), not absolute disc times (section 6).
  • The character set was never defined. Older files are in the system code page (often Windows-1252 or Shift-JIS). Newer tools write UTF-8, sometimes with a BOM. libmirage detects a BOM and otherwise assumes UTF-8.
  • At most 99 tracks and 99 indexes per track, matching the CD format.

The commands fall into a strict nesting: disc-level commands, then FILE → TRACK → track-level commands.

[disc-level: REM, CATALOG, CDTEXTFILE, TITLE, PERFORMER, SONGWRITER]
FILE "name" TYPE
  TRACK nn TYPE
    [FLAGS, ISRC, TITLE, PERFORMER, SONGWRITER, REM]
    [PREGAP mm:ss:ff]
    INDEX 00 mm:ss:ff      (optional)
    INDEX 01 mm:ss:ff      (required)
    [INDEX 02..99 ...]
    [POSTGAP mm:ss:ff]
  TRACK nn+1 TYPE
  ...
[FILE ... more tracks]

3. Commands #

3.1 FILE "filename" type #

Starts a new data file. Every following TRACK and INDEX refers to this file, until the next FILE. A path is resolved relative to the .cue file. Many tools also try case-insensitive matches and different extensions when the named file is missing (libmirage's mirage_helper_find_data_file does).

Type Meaning
BINARY Raw sectors, little-endian audio. By far the most common type.
MOTOROLA Raw sectors, with audio samples big-endian.
WAVE A RIFF WAV file (audio tracks only); the header is skipped and the PCM data used. Addresses count 2352-byte frames of decoded audio.
AIFF An AIFF file (audio only).
MP3 An MP3 file (audio only). Later extensions also accept FLAC, OGG, APE and so on via the same mechanism.

3.2 TRACK nn type #

Starts a new track, number 01–99. Numbers must be ascending (gaps in numbering are allowed by some tools, but are not valid on a real disc). The type fixes the sector size in the file and how its bytes map onto the CD sector:

Type Bytes per sector in file What part of the 2352-byte sector is stored Disc track
AUDIO 2352 all (PCM) audio
CDG 2448 2352 audio + 96 bytes interleaved P–W subchannel audio with CD+G graphics
MODE1/2048 2048 user data 0x010–0x80F only Mode 1
MODE1/2352 2352 all (sync, header, data, EDC/ECC) Mode 1
MODE2/2048 2048 Form 1 user data only (0x018–0x817) Mode 2 Form 1
MODE2/2324 2324 Form 2 user data only Mode 2 Form 2
MODE2/2336 2336 everything after the header (0x010–0x92F) Mode 2 (XA mixed or formless)
MODE2/2352 2352 all Mode 2 (XA mixed or formless)
CDI/2336 2336 like MODE2/2336 CD-i
CDI/2352 2352 all CD-i

The /2352 types are what preservation tools produce. Readers need the stored size to step through the file, and the mode to regenerate missing parts (sync, header, EDC/ECC) when a drive emulator is asked for raw sectors from a cooked track.

3.3 INDEX nn mm:ss:ff #

Marks index nn of the current track at position mm:ss:ff within the current file:

  • INDEX 01 is required. It is the track's start (the address that goes into the TOC).
  • INDEX 00 is optional. It marks the start of the pregap and means the pregap sectors are in the file, between INDEX 00 and INDEX 01.
  • INDEX 02–99 are optional sub-indexes.
  • Positions must increase within a file. The first index of the first track in each file is usually 00:00:00.

The time is a sector count: INDEX 01 03:20:15 means file sector (3 × 60 + 20) × 75 + 15 = 15,015, which is byte 15,015 × sector size for that track (after summing the sizes of earlier tracks in the file if they differ).

3.4 PREGAP mm:ss:ff #

Declares a pregap of the given length for the current track that is not stored in the file. The reader (or burner) generates it: silence for audio, zero-filled sectors in the track's mode for data. It must come after TRACK and before INDEX.

The key distinction:

Pregap exists on the disc Pregap bytes in the .bin
INDEX 00 … INDEX 01 yes yes
PREGAP yes no

3.5 POSTGAP mm:ss:ff #

A gap at the end of the track, not stored in the file. It comes after the last INDEX of the track. It is rarely used, except for data tracks followed by audio on TAO-written discs.

3.6 FLAGS flag... #

Sets the track's subchannel Q CONTROL bits (see Tracks §6):

Flag Meaning
DCP Digital copy permitted (CONTROL bit 1)
4CH Four-channel audio (bit 3)
PRE Pre-emphasis (bit 0)
SCMS Serial Copy Management System. This is not a CONTROL bit: it makes a burner alternate the copy bit to signal "one generation of copies allowed"
DATA (some tools) data track; normally implied by the track type

It goes after TRACK and before INDEX.

3.7 ISRC code #

The 12-character ISRC of the current track (e.g. ISRC USRC17607839). A burner writes it into the Q subchannel as ADR 3 frames (Subchannels §4.6).

3.8 CATALOG nnnnnnnnnnnnn #

The disc's 13-digit Media Catalog Number (EAN/UPC barcode), at disc level. It is written to Q as ADR 2.

3.9 CD-TEXT: TITLE, PERFORMER, SONGWRITER, CDTEXTFILE #

TITLE "…", PERFORMER "…" and SONGWRITER "…" at disc level (album) or track level (song) give CD-TEXT strings. CDRWIN limited them to 80 characters. They cover only part of CD-TEXT: one language, and only three of the pack types.

CDTEXTFILE "file.cdt" names a binary file with the raw CD-TEXT packs: 18-byte packs as read from the lead-in, including their CRCs, sometimes preceded by the 4-byte READ TOC header. This preserves all CD-TEXT exactly. libmirage reads the whole file and decodes it once all tracks are known.

3.10 REM comment #

A comment. Many tools hide extra metadata in REM lines. Readers should ignore REM lines they don't understand.

REM line Origin Meaning
REM SESSION nn cdrdao, Redump, EAC, IsoBuster Following tracks belong to session nn. This is the standard way to describe multisession discs.
REM LEAD-OUT mm:ss:ff IsoBuster/Redump Length of the preceding session's lead-out
REM ORIGINAL MEDIA-TYPE: CD Aaru/DiscImageCreator Type of the original disc (CD, CD-R, DVD-R, BD, …)
REM SINGLE-DENSITY AREA / REM HIGH-DENSITY AREA Redump (Dreamcast GD-ROM) Which of the GD-ROM's two areas follows
REM GENRE, REM DATE, REM DISCID, REM COMMENT EAC, foobar2000 Audio metadata (freedb disc ID, year, ripper comment)
REM REPLAYGAIN_ALBUM_GAIN … etc. foobar2000 ReplayGain values
REM Ripping Tool:, REM CRC32 : … trurip Ripping tool and hashes
REM MSF: mm:ss:ff = LBA: n some tools Address annotations

Some tools also emit non-REM extras such as GENRE, ARRANGER, COMPOSER, UPC_EAN and DISC_ID (Aaru recognises them). Strict parsers reject unknown commands, so writers should avoid them.

4. Examples #

4.1 Single data track #

FILE "game.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00

game.bin holds raw Mode 1 sectors from LBA 0 to the end. Its size is a multiple of 2352.

4.2 Mixed Mode, single file, gaps stored #

This is the disc from the Tracks page example:

FILE "game.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 12:20:04
    INDEX 01 12:22:04
  TRACK 03 AUDIO
    INDEX 01 15:59:50
  TRACK 04 AUDIO
    INDEX 00 20:42:10
    INDEX 01 20:44:10

With every gap stored in the file, the file holds every sector from LBA 0 onward, so:

absolute disc time = cue time + 00:02:00        e.g. 12:22:04 → 12:24:04 (LBA 55,654)
file offset        = LBA × 2352

4.3 The same disc, Redump style (one file per track) #

FILE "Game (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Game (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Game (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 01 00:00:00
FILE "Game (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Each pregap is stored at the start of its own track's file (Redump's convention). Track 1's file ends where track 2's pregap begins. A track's length is its file size divided by the sector size.

4.4 The same disc with gaps left out (PREGAP) #

FILE "game.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PREGAP 00:02:00
    INDEX 01 12:20:04
  TRACK 03 AUDIO
    INDEX 01 15:57:50
  TRACK 04 AUDIO
    PREGAP 00:02:00
    INDEX 01 20:40:10

The 150-sector gaps are not in the file, so every later track's file position falls behind its disc position by the gaps seen so far. Track 4's index 1 is at file sector 93,010 but disc LBA 93,310: the 300 missing gap sectors account for the difference.

4.5 Audio CD with gaps attached to the previous file (EAC's "noncompliant" layout) #

FILE "01.wav" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 04:12:33
FILE "02.wav" WAVE
    INDEX 01 00:00:00

Track 2's pregap is the tail of 01.wav, and track 2 proper starts at the beginning of 02.wav. The original CDRWIN could not handle a track that spans two files, which is why EAC labels this layout noncompliant. Most modern parsers accept it.

4.6 Hidden track in track 1's pregap (HTOA) #

FILE "album.bin" BINARY
  TRACK 01 AUDIO
    INDEX 00 00:00:00
    INDEX 01 03:41:20

Here the file starts at absolute time 00:00:00 (LBA −150) and contains the hidden song, so the usual "file starts at LBA 0" assumption does not hold. When track 1 has INDEX 00 00:00:00, file sector 0 is LBA −150. Track 1's index 1 is then at file sector (3 × 60 + 41) × 75 + 20 = 16,595, which is LBA 16,595 − 150 = 16,445. All later LBAs shift accordingly.

4.7 Multisession (Enhanced CD, Redump style) #

REM SESSION 01
FILE "Album (Track 01).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "Album (Track 02).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:32
REM SESSION 02
FILE "Album (Track 03).bin" BINARY
  TRACK 03 MODE2/2352
    INDEX 01 00:00:00

The lead-out of session 1, the lead-in of session 2 and the pregap of track 3 are not stored. A reader adds them: libmirage assumes 11,250 sectors (6,750 lead-out + 4,500 lead-in) plus a 150-sector pregap. See Sessions §3. If the dumping tool recorded the real lead-out length (REM LEAD-OUT), that should be used instead.

4.8 CD+G karaoke disc #

FILE "karaoke.bin" BINARY
  TRACK 01 CDG
    INDEX 01 00:00:00
  TRACK 02 CDG
    INDEX 00 03:58:20
    INDEX 01 04:00:20

Each sector is 2448 bytes: 2352 audio + 96 interleaved subchannel.

5. How a reader turns a cue sheet into a disc #

This summarises libmirage's algorithm (lib/cdemu/libmirage/images/image-cue/parser.c). Aaru's (CDRWin/Read.cs) is equivalent but longer.

  1. Start session 1. For each line, match it against a list of regexes. (Extensions inside REM are tried before the generic REM rule.)
  2. FILE: finish the previous track (its last fragment extends to the end of the old file). Remember the new filename and type. Reset the in-file position to 0.
  3. TRACK: create a track, look up the sector size and mode for its type, and reset "pregap seen".
  4. PREGAP: add an empty ("NULL") fragment of that length to the track and move the track start past it. No file bytes are consumed.
  5. INDEX 00: note that a pregap is present in the file; it begins at this address.
  6. INDEX 01 (or INDEX 00, whichever comes first for the track):
    • If an earlier track in the same file is still open, set its length to this address − that track's start address and advance the in-file byte offset by length × that track's sector size. Sector sizes can differ per track, so the offset has to be accumulated track by track rather than computed as address × size.
    • Create a data fragment at the current byte offset with this track's sector size (for CDG: 2352 + 96 interleaved subchannel).
    • If INDEX 00 came first, INDEX 01 just sets the track start (pregap length = INDEX 01 − INDEX 00).
  7. INDEX 02+: record the index.
  8. POSTGAP: append an empty fragment.
  9. REM SESSION n (n > 1): finish the current track and session. Give the session a lead-out length (11,250 after session 1, 6,750 after later ones). Open a new session. (Correction for UltraISO/IsoBuster single-file images, which do store the lead-out/lead-in: subtract that length from the next computed fragment length.)
  10. At the end: finish the last track (use the rest of the file). Work out each session's type from its track modes (all audio → CD-DA; any Mode 2 → CD-ROM XA; otherwise CD-ROM). Add the standard 150-sector track 1 pregap if the file didn't contain it.

Then TOC entries (A0/A1/A2 and the track pointers) are synthesised from the result. The cue sheet itself never contains them.

6. Mapping a cue to disc addresses #

For each track, in order:

disc_lba = −150                       (start of program area)
for each track t:
    disc_lba += PREGAP(t)             (not in file)
    if t has INDEX 00:                (in file)
        pregap_len = INDEX01 − INDEX00
    else if t is track 1:
        pregap_len = 150 (synthesised) unless the file starts with track 1's pregap
    else:
        pregap_len = 0
    t.index0_lba = disc_lba
    t.index1_lba = disc_lba + pregap_len        ← goes into the TOC
    disc_lba    += length_in_file(t)            (sectors from first INDEX to next track's first INDEX / EOF)
    disc_lba    += POSTGAP(t)
    (+ session gap if a REM SESSION follows)
lead-out (A2) = disc_lba

Where length_in_file(t) = (next track's first index in the same file − this track's first index), or (bytes remaining in the file / sector size) for the last track in a file.

7. What BIN/CUE does and doesn't preserve #

Kept Lost / not representable
Any number of tracks, audio and data, with per-track sector sizes Subchannel (except CDG tracks): no MCN/ISRC as recorded, no P/Q irregularities, no index marks beyond what's written in the cue
Raw sectors (with /2352), so EDC/ECC and intentional errors are kept The original Full TOC (lead-in Q entries, ADR 5 B0/C0): the reader rebuilds it
Pregaps (with INDEX 00) or their lengths (with PREGAP) Exact multisession gaps (unless REM LEAD-OUT is present)
CONTROL flags (FLAGS), MCN (CATALOG), ISRC (ISRC) Lead-in and lead-out contents
CD-TEXT (TITLE etc., or a full .cdt) DVD anything (no structures, no layers); DPM; C2 error information
Multisession, via REM SESSION (an extension) Data track scrambling state; drive read/write offsets (unless the dumper corrected for them)

BIN/CUE plus a separate subchannel file (.sub, .sbi) is a common combination for emulators that need LibCrypt or similar protection data.

Sources #