An ID3v2 tag holds a song’s title, artist, cover art and much else. It normally sits at the very start of the file, before the first audio frame, so a player can read it while the file is still arriving. A tag is a ten-byte header, optionally an extended header, a series of frames, padding, and, in version 2.4, an optional footer. Numbers are big-endian. Versions 2.2 (1998), 2.3 (1999) and 2.4 (2000) all appear in the wild; 2.3 is the most common.
The tag header
| Offset | Size | Field | Meaning |
|---|---|---|---|
| 0 | 3 | Identifier | ID3 |
| 3 | 1 | Major version | 2, 3 or 4, for ID3v2.2, 2.3 and 2.4; never 255 |
| 4 | 1 | Revision | usually 0; never 255 |
| 5 | 1 | Flags | see below |
| 6 | 4 | Size | the size of the tag after this header, excluding a footer, as a syncsafe integer |
A syncsafe integer stores 7 bits in each byte, with the top bit always 0, so no run of bytes can look like a frame sync: the value is b₀ × 2²¹ + b₁ × 2¹⁴ + b₂ × 2⁷ + b₃.
Tag flags
| Bit | 2.2 | 2.3 | 2.4 | Meaning |
|---|---|---|---|---|
| 7 (0x80) | unsynchronisation | the tag (2.2, 2.3) or every frame (2.4) has been unsynchronised | ||
| 6 (0x40) | compression | extended header | in 2.2, the tag is compressed (never defined; such a tag cannot be read); in 2.3 and 2.4, an extended header follows | |
| 5 (0x20) | – | experimental | the tag is experimental | |
| 4 (0x10) | – | footer | a footer follows the tag | |
Unsynchronisation
MP3 audio decoders look for frame syncs: eleven 1 bits. Tag data could contain
the same pattern, so an unsynchronised tag inserts a zero byte after every
0xFF that is followed by a byte with its top three bits set, or by a
zero. A reader removes every 0x00 that follows a 0xFF. In 2.2
and 2.3 this applies to the whole tag after its header; in 2.4 each frame has its own
flag. The explorer undoes it to read the frames, and still points every field at
the right bytes of the file.
Extended header
Optional, following the header when flag bit 6 is set.
| Version | Layout |
|---|---|
| 2.3 | 4 bytes size, not counting itself, excluding this field; 2 bytes flags (0x8000 CRC present); 4 bytes padding size; 4 bytes CRC-32 when flagged |
| 2.4 | 4 bytes syncsafe size, counting itself; 1 byte number of flag bytes; flag bytes (bit 6 update, bit 5 CRC, bit 4 restrictions), each flag then a length byte and its data: 0 for update, 5 syncsafe bytes of CRC-32 for CRC, 1 byte of restrictions |
In 2.4, the restrictions byte packs five limits, in bit order high to low:
| Bits | Limit |
|---|---|
| 7–6 | tag size: 128 frames and 1 MB; 64 and 128 KB; 32 and 40 KB; 32 and 4 KB |
| 5 | text encoding: none, or only ISO-8859-1 or UTF-8 |
| 4–3 | text field size: none, 1024, 128 or 30 characters |
| 2 | image encoding: none, or only PNG or JPEG |
| 1–0 | image size: none, 256×256, 64×64, or exactly 64×64 (unless wider or taller is required) |
Padding and the footer
After the last frame, a tag may have padding: zero bytes that let it grow without moving the audio. Reading a frame ID of four zero bytes means the frames have ended. A padding byte that is not zero is reported, since it usually means a frame has been misread.
Text encodings
Most frames start with a one-byte text encoding that applies to their text fields:
| Value | Encoding | Terminator | Versions |
|---|---|---|---|
| 0 | ISO-8859-1 (Latin-1) | 1 zero byte | all |
| 1 | UTF-16 with a byte-order mark | 2 zero bytes | all |
| 2 | UTF-16BE without a mark | 2 zero bytes | 2.4 |
| 3 | UTF-8 | 1 zero byte | 2.4 |
Version 2.4 allows a text frame to hold a list: values separated by the terminator.
Frames
Every frame in a tag has a short header: in 2.3 and 2.4, a four-character ID, a 4-byte size (syncsafe in 2.4, plain in 2.3) and two flag bytes; in 2.2, a three-character ID and a 3-byte size, with no flags. The size does not count the header. A tag’s frames are a sequence in no required order.