MP3 File Documentation

Summary

An MP3 file is lossy compressed audio: MPEG-1/2 Audio Layer III, standardised by MPEG and Fraunhofer IIS in ISO/IEC 11172-3 (1993). It stores sound as a stream of independent frames, each about 26 ms long, at bitrates from 8 to 320 kbps. The extension is .mp3 and the MIME type is audio/mpeg. Files usually carry ID3 tags for title, artist and cover art.

Technical details

FeatureValue
Full nameMPEG-1/2 Audio Layer III
File extension.mp3
MIME typeaudio/mpeg
Format typeLossy compressed audio bitstream (perceptual coding)
DeveloperFraunhofer IIS / Moving Picture Experts Group (MPEG)
Introduced1993 (MPEG-1); MPEG-2 low-sample-rate extension 1995
StandardISO/IEC 11172-3 (MPEG-1 Audio); ISO/IEC 13818-3 (MPEG-2)
Patent statusOpen — last Fraunhofer patents expired around 2017
CompressionLossy, based on ISO/MPEG psychoacoustic model 2
Bitrate range8–320 kbps, constant (CBR), variable (VBR) or average (ABR)
Common bitrates128, 192, 256, 320 kbps
Sample rates32 / 44.1 / 48 kHz (MPEG-1); down to 8 kHz (MPEG-2 / 2.5)
Samples per frame1152 (MPEG-1 Layer III); 576 for MPEG-2 / 2.5
Frame duration~26 ms at 44.1 kHz
ChannelsMono, stereo, joint stereo, dual channel
Frame header4 bytes, big-endian, starting with the 11-bit frame sync
Frame syncFF Ex / FF Fx (commonly FF FB)
Error protectionOptional 16-bit CRC after the header
Byte orderBig-endian
MetadataID3v2 at the start, ID3v1 in the final 128 bytes
Related extensions.wav .m4a .flac .aac .ogg
Specificationiso.org/standard/22412.html
File signature (magic bytes)
FF FB (or 49 44 33 → “ID3”)

MP3 has no single fixed signature. Raw audio begins with a frame sync: 11 bits all set, so the first byte is 0xFF and the next byte’s top three bits are set. That gives FF Ex or FF Fx depending on the MPEG version, layer and CRC bits, most often FF FB (also FA, F3, F2). In practice a file very often starts with the ASCII string ID3 (49 44 33), because an ID3v2 tag is prepended and the first audio frame follows the tag. A legacy ID3v1 tag, if present, sits in the last 128 bytes and starts with TAG (54 41 47). To detect an MP3, check for a leading ID3 or scan for an FF Ex/Fx sync at a frame boundary.

What is an MP3 file?

MP3 is short for MPEG-1/2 Audio Layer III, the lossy audio format standardised by the Moving Picture Experts Group as ISO/IEC 11172-3 in 1993, with the core coding technology developed at Germany’s Fraunhofer IIS. A 1995 MPEG-2 extension (ISO/IEC 13818-3) added lower sample rates. Its MIME type is audio/mpeg, and the last relevant Fraunhofer patents expired around 2017, so encoding and decoding MP3 is now unencumbered worldwide.

“Layer III” is the most complex of the three MPEG-1 audio coding modes; Layer I and Layer II trade compression for simpler encoding. An MP3 is not a container in the sense of M4A or MP4. It is a bare stream of self-describing audio frames, usually bracketed by ID3 metadata. Everything below is about how that stream is laid out, frame by frame and bit by bit.

The 32-bit frame header, field by field

Every audio frame opens with a 4-byte header, stored big-endian. The 32 bits are conventionally written as four groups of letters, one letter per field:

AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM

Reading left to right: A is the 11-bit frame sync, all bits set. That is why the first byte is always 0xFF and the second byte’s top three bits are set, giving the familiar FF FB, FF FA, FF F3 or FF F2. B (2 bits) is the MPEG version ID: 11=MPEG-1, 10=MPEG-2, 00=MPEG-2.5, 01 reserved. C (2 bits) is the layer: 01=Layer III, 10=Layer II, 11=Layer I. D (1 bit) is the protection bit, and it is inverted logic: 0 means a CRC follows the header, 1 means no CRC.

E (4 bits) is the bitrate index, a lookup into a table keyed by version and layer (not a raw kbps value). F (2 bits) is the sampling-rate index, another table lookup. G (1 bit) is the padding bit; when set, the frame is one slot (one byte for Layer III) longer so the average bitrate lands exactly on target. H (1 bit) is a private bit with no defined meaning. I (2 bits) is the channel mode: 00=stereo, 01=joint stereo, 10=dual channel, 11=mono. J (2 bits) is the mode extension, meaningful only in joint stereo, where it signals which intensity/MS stereo bands are on. K is copyright, L is original, and M (2 bits) is de-emphasis (00=none, 01=50/15 µs, 11=CCITT J.17).

Bitrate index and sample-rate index tables

The 4-bit E field does not store kbps directly. Index 0000 means “free format” and 1111 is invalid; the values between them map through a version- and layer-specific table. For MPEG-1 Layer III:

Bitrate index (E)kbps (MPEG-1 Layer III)
000132
001040
001148
010056
010164
011080
011196
1000112
1001128
1010160
1011192
1100224
1101256
1110320

The 2-bit F field maps just as tersely. For MPEG-1: 00=44100 Hz, 01=48000 Hz, 10=32000 Hz, 11 reserved. MPEG-2 halves those to 22050 / 24000 / 16000 Hz, and MPEG-2.5 halves them again to 11025 / 12000 / 8000 Hz. Because both fields are table indices, a decoder must first read the version and layer bits to know which table to consult; the same four bits mean different bitrates in Layer I versus Layer III.

Frame anatomy: header, CRC, side information and main data

After the 4-byte header, a frame is laid out as an optional 16-bit CRC, then the side information, then the main data. The CRC is present only when the header’s protection bit is 0, and it covers the header and side info. Side information size depends on the channel count and MPEG version: for MPEG-1 it is 17 bytes in mono and 32 bytes in stereo/joint/dual; MPEG-2 and 2.5 use 9 and 17 bytes. The side info carries scalefactor selection, Huffman table choices, and the main-data pointer discussed below.

One MPEG-1 Layer III frame always decodes to 1152 audio samples (two granules of 576), which at 44.1 kHz is about 26 ms of sound. MPEG-2 and 2.5 frames hold 576 samples. The byte length of a frame is not fixed for VBR files but follows a formula:

frameLength = floor(144 * bitrate / sampleRate) + padding    // Layer III, bytes
// e.g. 128000 bps @ 44100 Hz: floor(144 * 128000 / 44100) = 417 (+1 if padded)

The constant 144 is 1152 samples divided by 8 bits per byte. The padding term is the header’s G bit, adding a single byte when set so the running average bitrate stays exact despite integer truncation.

The bit reservoir and why frames are not self-contained byte ranges

A subtle consequence of Layer III is that a frame’s header does not sit immediately before its own audio payload. The side information starts with a 9-bit field called main_data_begin, a negative byte offset (a back-pointer) into the bytes already emitted. When a passage is simple and does not need its full bit budget, the encoder leaves the slack unused; a later, more demanding frame can then reach backwards into that slack. This shared pool is the bit reservoir.

The practical effect: the main data belonging to frame N may physically live in the bytes of frames N−1 or N−2. A frame header is a timing and format marker, not a clean boundary you can cut on. Splitting an MP3 exactly at a frame header can orphan main data that a following frame expected to find behind it, which is why careful editors decode and re-encode, or at least respect the reservoir, rather than slicing raw bytes.

The perceptual coding pipeline

MP3 compression discards sound the ear is unlikely to hear. On the encode side the pipeline runs roughly: a 32-band polyphase filterbank splits the signal into subbands; a modified discrete cosine transform (MDCT) converts each subband into finer frequency lines (18 per subband, 576 total per granule); those lines are grouped into scalefactor bands that approximate the ear’s critical bands. In parallel, a psychoacoustic model (the ISO reference used model 2) computes a masking threshold: for each band, how much quantisation noise stays inaudible under the louder tones nearby.

Quantisation is then shaped to push noise below that threshold, spending more bits where the ear is sensitive and fewer where sound is masked. The quantised frequency lines are finally Huffman coded using tables selected per region and named in the side information. Decoding reverses all of this: Huffman decode, dequantise, inverse MDCT, synthesis filterbank. The masking model lives only in the encoder, which is why two encoders at the same bitrate can produce audibly different files.

ID3v2 at the front, ID3v1 at the end

Most MP3 files begin with an ID3v2 tag, before any audio frame. Its 10-byte header is the ASCII string ID3, a 2-byte version (for example 03 00 for ID3v2.3), a 1-byte flags field, and a 4-byte syncsafe size. Syncsafe means only the low 7 bits of each byte are used, so the tag’s length can never accidentally contain the byte 0xFF that would look like a frame sync. Inside are frames keyed by four-character IDs: TIT2 (title), TPE1 (artist), TALB (album), TRCK (track), and APIC for embedded cover art.

The older ID3v1 tag lives in the final 128 bytes of the file and starts with TAG. It is a fixed layout with no length prefixes: 30 bytes each for title, artist and album, 4 bytes for year, 30 for comment, and 1 byte for a numeric genre code. Because its fields are fixed-width, ID3v1 truncates long titles and cannot hold cover art, which is exactly why ID3v2 was added at the front. A file can carry both.

+-----------------------------+  offset 0
| ID3v2 tag                   |  "ID3" + version + flags + syncsafe size
|   TIT2 / TPE1 / TALB / APIC |  title, artist, album, cover art
+-----------------------------+
| MPEG audio frame 1          |  FF Fx header + side info + main data
| MPEG audio frame 2          |
|   ...                       |
| MPEG audio frame N          |
+-----------------------------+  last 128 bytes
| ID3v1 tag "TAG"             |  30B title / 30B artist / 30B album / year / genre
+-----------------------------+  end of file

CBR, VBR and the Xing/Info and LAME headers

In a constant-bitrate (CBR) file every frame carries the same bitrate index, so a player can estimate duration from file size alone: bytes divided by bitrate. Variable-bitrate (VBR) files vary the index per frame to spend bits where the audio is complex, which gives better quality per byte but breaks that simple arithmetic. A naive seek in a VBR file, jumping to a byte position proportional to a time position, lands in the wrong place.

The fix is a metadata frame placed as the first frame of the stream, in what would otherwise be the side-info/main-data area of a silent frame. It is tagged Xing in VBR files and Info in CBR files (same structure, different label). It records the total frame count, total file bytes, and a 100-entry table of contents that maps percentage-through-the-file to percentage-through-the-time, so a player can seek accurately without scanning every frame. Encoders from the LAME project append a LAME extension in the same frame, adding encoder version, gapless-playback delay/padding, and a replay-gain value. A player reads this frame to report a VBR file’s true length before playing a note.

Frequently asked questions

Why does a trimmed or half-downloaded MP3 still play?

Because the audio is a stream of independent frames, each with its own header stating bitrate, sample rate and channel mode. A decoder resynchronises by scanning for the next FF Ex/Fx sync word, so it can start mid-file and play whatever frames it finds. A partial download simply ends early. The one caveat is the bit reservoir: a cut on a frame boundary can leave the first surviving frames slightly glitched if their main data lived in bytes that were removed.

What is the bit reservoir?

It is a way to borrow unused bits across frames. When a frame does not need its full bit budget, the leftover space stays available; a later, harder-to-encode frame reaches backwards into it via the main_data_begin pointer in the side info. This lets Layer III hold quality steady through loud transients without raising the nominal bitrate, at the cost of frames no longer being independent byte ranges.

How does a player know a VBR file’s length?

It reads the Xing header in the first frame. That header stores the total frame count and byte count, so the player multiplies frames by samples-per-frame over the sample rate to get the duration, and uses the 100-entry table of contents to seek. Without a Xing header, a player has to scan the whole file frame by frame to time it, which is why some VBR files briefly show the wrong length.

Why is there no single MP3 magic number?

The audio itself has no fixed file header, only per-frame sync words (FF Ex/Fx). And most files begin with an ID3v2 tag, so the first bytes on disk are usually the ASCII ID3 instead. Detection means checking for a leading ID3 or scanning for a valid frame sync, not matching one constant. Lossless alternatives like WAV and FLAC, or the AAC-based M4A, do start with their own fixed signatures. The MP3 specification is published as ISO/IEC 11172-3.

References