MP3 File Structure

Structure of MP3 file can be expressed in this scheme (TAGs are optional):

[TAG v2]   Frame1   Frame2   Frame3...   [TAG v1]

MP3 file is divided into a small blocks - frames. Each frame has constant time length 0.026 sec. But size of one frame (in Bytes) varies according to bitrate. Eg. for 128kbps it is (normally) 417 Bytes and for 192kbps 626 Bytes.

The first 4 Bytes of each frame is frame header and the rest is audio data.

Frame header consists of information about frame (bitrate, stereo mode...) and because of that frames are independent items. Each of them can have its own characteristic. It is used eg. in Variable Bitate files, where each frame can have different bitrate.

Frame header has this structure (each letter is one bit):


A    Frame synchronizer
All bits are set to 1. It is used for finding the beginning of frame. But these values can occur many times in binary file so you should test next values from header for validity (eg. bitrate bits arent 1111, sampling rate frequency isnt 11 etc.). But you can never be 100% sure if you find a header.
Next method is to find the first header and then go through all frames - almost exact, but time consuming.
Be careful with the first frame! It doesnt have to start at the first Byte in file. Either TAG v2 can be included or file can contains of some crap at the beginning.
Anyway - to find a header is a little problem.
B    MPEG version ID
00  MPEG Version 2.5 (not an official standard)
01  reserved
10  MPEG Version 2
11  MPEG Version 1
In most MP3 files these value should be 11.
C    Layer
00  reserved
01  Layer III
10  Layer II
11  Layer I
In most MP3 files these value should be 01 (because MP3 = MPEG 1 Layer 3).
D    CRC Protection
0  Protected by CRC
1  Not protected
Frames may have some form of check sum - CRC check. CRC is 16 bit long and, if exists, it follows frame header. And then comes audio data.
But almost all MP3 files doesnt contain CRC.
E    Bitrate index
0000  free
0001  32
0010  40
0011  48
0100  56
0101  64
0110  80
0111  96
1000  112
1001  128
1010  160
1011  192
1100  224
1101  256
1110  320
1111  bad
All values are in kbps.
F    Samplig rate frequency index
00  44100
01  48000
10  32000
11  reserved
All values are in Hz. In most MP3 files these value should be 00.
Note: Sample frequency 44100 means that one second of audio information is hacked to 44100 pieces. And each 1/44100 sec. is audio value taken and encoded into digital form.
G    Padding
0  Frame is not padded
1  Frame is padded
Padding is used to fit the bitrates exactly. If you use frames with length 417 Bytes (for 128kbps) it doesnt give exact data flow 128kbps. So you can set Padding and add one extra Byte at the end of some frames to create exact 128kbps.
Fuck it.
H    Private bit
It can be freely used for specific needs of an application, eg. it can execute some application specific events.
No special meaning, forget it.
I    Channel
00  Stereo   Similar to Dual mono, 2 channels, but bitrate can be different for each one and is coded dynamically. Eg. if channel 1 is silent, the second one will get higher bitrate.
01  Joint Stereo   Mostly used in MP3. One channel is common (mid) and is used mainly for common and lower tones. The second is (side) channel for encoding differences between normal channels.
Note: Stereo effect is listenable properly only for higher tones because for lower ones is length of sound wave so long that you are not able to distinguish phase move.
10  Dual   Also known as Dual mono; 2 separate channels.
11  Mono (single channel   Normal mono.
J    Mode extension (only if Joint Stereo is set)
  Intensity Stereo  MS Stereo
Tells which mode for JointStereo is used.
K    Copyright
0  Audio is not copyrighted
1  Audio is copyrighted
No special use.
L    Original
0  Copy of original media
1  Original media
No special use.
M    Emphasis
00  None
01  50/15
10  reserved
11  CCIT J.17
Tells if there are emphasised frequencies above cca. 3.2 kHz.

Formula for counting frame length in Bytes:

FrameLen = int((144 * BitRate / SampleRate ) + Padding);

Eg. for Bitrate = 192kbps, SampleRate = 44.1kHz a Padding = Yes
FrameLen = int((144 * 192000 / 44100) + 1) = 627 Bytes
int() means round to bottom. FrameLen includes frame header.

Constant Bitrate (CBR)

Here is no problema. All frames should be the same (except of audio data).
But only SHOULD. God damn if they vary in Padding or Emphasis. But I met CBR files where all frame headers were the same and frame length should be 626 Bytes. But some frames were 625, 627, 628... So be careful, in MP3 files you cant rely on nothing. But in most cases frame length is correct.

Variable Bitrate (VBR)

This system was created to minimize file lengths and to preserve sound quality.
Higher frequencies generally needs more space for encoding (thats why many codecs cut all frequencies above cca 16kHz) and lower tones requires less. So if some part of song doesnt consist of higher tones then using eg. 192kbps is wasting of space. It should be enough to use only eg. 96kbps.
And it is the principle of VBR. Codec looks over frame and then choose bitrate suitable for its sound quality.

It sounds perfect but it brings some problems:
If you want to jump over 2 minutes in song, it is not a problem with CBR because you are able simply count amount of Bytes which is necessary to skip. But it is impossible with VBR. Frame lengths should be arbitrary so you have to either go frame by frame and counts (time consuming and very unpractical) or use another mechanism for approximate count.
If you want to cut 5 minutes from the middle of VBR file (all we know CDs where last song takes 10 minutes but 5 minutes is a pure silence, HELL!) problems are the same.
Result? VBR files are more difficult for controlling and adjusting. And I dont like feeling that sound quality changes in every moment. And AFAIK many codecs have problems with creation VBR in good quality.
Personally I cant see any reason why to use VBR - I dont give a fuck if size of one CD in MP3 is 55 MB with CBR or 51 MB with VBR. But everybody has a different taste... some people prefer VBR.

VBR File Structure

is the same as for CBR. But the first frame doesnt contain audio data and it is used for special information about VBR file.

Structure of the first frame:

Byte        Content
0-3Standard audio frame header (as descripted above). Mostly it contains values FF FB 30 4C, from which you can count FrameLen = 156 Bytes. And thats exactly enough space for storing VBR info.
This header contains some important information valid for the whole file:
- SAMPLING rate frequency index
- CHANNEL (JointStereo etc.)
4-xNot used till string "Xing" (58 69 6E 67). This string is used as a main VBR file identifier. If it is not found, file is supposed to be CBR. This string can be placed at different locations according to values of MPEG and CHANNEL (ya, these from a few lines upwards):
36-39"Xing" for MPEG1 and CHANNEL != mono (mostly used)
21-24"Xing" for MPEG1 and CHANNEL == mono
21-24"Xing" for MPEG2 and CHANNEL != mono
13-16"Xing" for MPEG2 and CHANNEL == mono
After "Xing" string there are placed flags, number of frames in file and a size of file in Bytes. Each of these items has 4 Bytes and it is stored as 'int' number in memory. The first is the most significant Byte and the last is the least.
Following schema is for MPEG1 and CHANNEL != mono:
00 00 00 01Frames Flagset if value for number of frames in file is stored
00 00 00 02Bytes Flagset if value for filesize in Bytes is stored
00 00 00 04TOC Flagset if values for TOC (see below) are stored
00 00 00 08VBR Scale Flagset if values for VBR scale are stored
All these values can be stored simultaneously.
Number of frames in file (including the first info one)
File length in Bytes
52-151TOC (Table of Contents)
Contains of 100 indexes (one Byte length) for easier lookup in file. Approximately solves problem with moving inside file.
Each Byte has a value according this formula:
(TOC[i] / 256) * fileLenInBytes
So if song lasts eg. 240 sec. and you want to jump to 60. sec. (and file is 5 000 000 Bytes length) you can use:
TOC[(60/240)*100] = TOC[25]
and corresponding Byte in file is then approximately at:
(TOC[25]/256) * 5000000

If you want to trim VBR file you should also reconstruct Frames, Bytes and TOC properly.
152-155VBR Scale
I dont know exactly system of storing of this values but this item probably doesnt have deeper meaning.

Complicated? Ya, that is.


TAG is name for data space in MP3 file where some text informations (song name, artist, album...) can be stored.

TAG ver.1

is old and simple. It takes always 128 Bytes at the very end of file (after the last audio frame).


Bytes  Length  Content
0-23Tag identifier. Must contain "TAG" string if Tag is valid.
3-3230Song Name

126. Byte can also be used as the number of song. Items should be padded with NULL (ASCII 0) or with a space (ASCII 32).

Values for Genre are predefined, you can find them eg. in WinAmp. Only the most important ones:
22  Death Metal
138Black Metal
144Thrash Metal

Problems with TAG v1 are obvious: you can store only a few items (you have a bad luck for eg. country of an artist, used codec, author of lyric...) and there is only a limited space for items (you also have a bad luck if song name has more than 30 chars).
But despite that is TAG v1 commonly used by most of "MP3 release" groups.

TAG ver.2

is newer, bigger and uncut. And... much more complicated.
Is placed at the very beginning of file (before all audio frames).


TAG v2 contains of header and frames (dont mismatch it with audio frames and their headers!!!).

Header (10 Bytes)

Bytes  Content
0-2TAG identifier. It contains of string "ID3"
3-4TAG version. Can be eg. 03 00
6-9Size of TAG

Flags Byte has this structure (in bits):
where the first 3 bits indicate Unsynchronization, Extended header and Experimental indicator.
Flags normally dont have special meaning, can be set to 00.

Size of TAG is encoded into 4 Bytes. But not to be so easy, the most significant bit in each Byte is set to 0 and ignored. Only remaining 7 bits are used. The reason is to avoid mismatch with audio frame header which has the first synchro Byte FF).
Eg. TAG len 257 is encoded as 00 00 02 01.
Size of TAG doesnt contain header itself so total lenght of previous TAG is 257 + 10 Bytes.


Each frame is used for storing one information - eg. Artist or Album.
Frame consists of header and body.

Header(10 Bytes)

Bytes  Content
0-3Frame identifier

Frame identifier consist of four characters. There are many predefined values you can use. But eg. current version of WinAmp displays only these ones:

Iden.  Description
TRCKTrack number
TENCEncoded By
TCOPFrame identifier
TOPEOriginal Artist
TIT2Song name

You can freely define you own frame, eg. with identifier "CUNT" but you cant expect thet some player will be able to diaplay that. Anyway you can store any information into MP3 file without limits.

Size is stored from the most significant Byte to the least. It doesnt include frame header, so total length of frame is Size + 10. Warning: After the header always one Byte with value 00 follows and then begins frame body. Size has to include this Byte.

Flags in most cases are set to 00 00. But they have this structure (in bits):

abc00000 ijk00000        //why they are not stored in one Byte???

Flag  Description
aTAG alter preservation
bFile alter preservation
cRead only
kGrouping identity

Example of frame:
545045310000000700 000053536C61796572
TPE17 Slayer

To be even more complicated, some frames can have special structure. Eg. COMM (comments) aslo contains language version which is not normally displayed:

434F4D4D0000000C00 0000656E6700636F6D 6D656E74
COMM0C engcom ment

For TCON (genre or style) you can use predefined values as in TAG v1. Then frame body looks like "(144)Thrash Metal" and the number corresponds with TAG v1. Or you can simply write your own style and then body is "Brutal Black" and is stored like normal frame body.

Complete description of TAG v2 you can find here.