The MPEG specification went through three revisions. MPEG 1 (ISO/IEC 13818-3) and MPEG 2 (ISO/IEC 11172-3) are ISO standards. MPEG 2.5 is an unofficial extension of MPEG 2 to support lower sampling rates. MPEG 2/2.5 is also known by the abbreviation LSF, which stands for Lower Sampling Frequencies.

An MPEG audio file is made up of frames. There are three "layers" to the spec; this post is concerned only with layer III, but in Layers I & II the frames are completely independent of one another (meaning that you could cut the file at any frame boundry & have the resulting parts play correctly). Layer III can make use of a technique known as the "bit resevoir" where unused space in each frame can be put to use to hold data for subsequent frames, meaning that frames may depend on one another. In the worst case, a decoder may need to read nine frames before being able to decode one [3]​.

Each frame is made up of a fixed-size header, possibly a two-byte CRC, a block of information that will be needed by decoders to interpret the audio samples referred to as the "side information", and finally the audio samples themselves.

Schematically, MPEG audio data looks like this:

+--------------+--------------+------------------+---------------+--------------+----
| frame header | optional CRC | side information | audio samples | frame header | ...
+--------------+--------------+------------------+---------------+--------------+----

This post is concerned with computing duration, which can be computed strictly from the header.

A little dimensional analysis points the way to computing the frame size:

samples   bytes    seconds   bytes
------- * ------ * ------- = -----
 frame    second   sample    frame

We know samples per frame from the MPEG audio version & Table 7. We can compute bytes per second from the bitrate (cf. Table 4): if the bitrate is B, then we have B kilobits per second or B * 1000/8 bytes per second. Finally, seconds per sample is just the inverse of the sampling freqency. Explicitly, let S be samples per frame from Table 7, B the bitrate from Table 4, and H the sampling frequency from Table 5. Then the frame size will be:

           B * 1000
floor(S * ----------)
            H * 8

Note that if the padding bit is set, we'll need to add one to arrive at the offset to the next frame.

Here's a worked example:

000000 ff fa 92 04 41 41 00 00 02 dd 06 c2 83 03 18 90  >....AA..........<
000016 5c ab 08 50 48 22 6e 4a f9 51 25 35 21 00 21 78  >\..PH"nJ.Q%5!.!x<
000032 18 e4 56 b0 20 04 01 81 a3 b4 f8 d8 b7 70 e0 60  >..V. ........p.`<

The frame header is 0xff, 0xfa, 0x92, 0x04. Un-packing that gives:

ff        fa        92        04
1111 1111 1111 1010 1001 0010 0000 0100
AAAA AAAA AAAB BCCD EEEE FFGH IIJJ KLMM

Un-packing each field gives:

• A, 11 bits, frame sync
• B, 2 bits, 11, MPEG version 1
• C, 2 bits, 01, layer 3
• D, 1 bit, not protected/no CRC
• E, 4 bits, 1001, 128kbps bitrate
• F, 2 bits, 00, 44100 Hz sampling rate
• G, 1 bit, 1, frame is padded with one extra slot
• H, 1 bit, 0 => private bit unset
• I, 2 bits, 00, stereo channel mode
• J, 2 bits, 00, ignored for this example
• K, 1 bit, 0, no copyright
• L, 1 bit, 1, original media
• M, 2 bits, 00, ignored for this example

So we have S := 1152, B := 128 & H := 44100

           B * 1000                    128000
floor(S * ----------) = floor(1152 * ---------) =~ floor(417.959183673) = 417
            H * 8                    44100 * 8

The padding bit is set, so this frame is 418 bytes in size.

There are two ways of which I am aware to calculate the duration of the frame.

The simpler of the two is to again do a little dimensional analysis:

samples    seconds   seconds
------- * -------- = -------
 frame     sample    frame

Explicitly, let S be samples per frame from Table 7 and H the sampling frequency from Table 5. Then the duration of this frame, in seconds, will be S/H.

Continuing the example from the last section, S is 1152 & H is 44100. S/H = 0.0261224489796 seconds.

The second approach, if B is the bitrate & D the frame size in bytes, is to compute:

    8
-------- * D
B * 1000

The dimensional analysis is left as an exercise. In this case:

   8
------ * 418 = 0.026125
128000

It irritates me that these two values only agree to three figures. I suspect that this is due to the fact that I don't really understand how the audio data is encoded (the value of 418 bytes, for example, includes the frame header & side information; it's not clear to me that that should be counted).

libmad [4]​ takes the first approach, for what it's worth:

int mad_header_decode(struct mad_header *header, struct mad_stream *stream)
{
  ...
  /* calculate frame duration */
  mad_timer_set(&header->duration, 0,
                32 * MAD_NSBSAMPLES(header), header->samplerate);

The bitrate refers to the number of bits in each audio sample: the more bits the better the quality. Encoding can be done using either a constant bit rate (CBR) or by varying the bitrate with each frame (VBR).

CBR brings with it advantages on the decoding side. If we somehow know, a priori, that a given file was encoded using CBR, then a lot of the problems described in the previous section disappear. All frames are the same size (up to padding) & of the same duration (assuming a constant sampling rate, on which more below). If you know the total size of the audio data (a reasonable assumption), you can compute, after decoding just the first frame header, the number of frames, the total duration, and how to seek ahead anywhere in the file. This post would not exist if all .mp3 files used CBR.

CBR also brings along some notable drawbacks. It forces the unpalatable choice of either encoding every frame at a bitrate suitable for the most complex regions of the audio, resulting in a file that is larger than necessary, or of encoding every frame at the minimal bitrate, resulting in poor audio quality. For that reason, VBR was introduced. There is a third variant– Average Bit Rate, or ABR. We'll touch on that below, but for purposes of this discussion, ABR is just a particular form of VBR. VBR lets the encoder select high bit rates for complex portions of the audio being encoded, and low bitrates for the simpler sections (such as the silence at the beginning & end of a song). The cost is that you now have to parse every frame header to do things like seek to a given timestamp.

Finally, absent outside information, there is no way to determine that a give file was encoded using CBR other than… walking every frame & checking, which pretty much leaves us having to treat everything as VBR.

It was due to this regrettable situation that both Fraunhofer & Xing (two big names in MP3 technology), in the time-honored tradition, introduced different & incompatible unofficial extensions to the standard. The idea in both cases was to start the data with a frame that contained no audio data, and to use that frame to hold a tag containing additional information that would ease life on the decoder side. That way decoders that didn't support their tags would just skip the frame harmlessly. Fraunhofer introduced the VBRI tag & Xing the Xing tag. The LAME encoder later introduced their own tag that extended that of the Xing encoder. Each contained the total number of frames for duration calculations, as well as a lookup table for seeking purposes. Collectively, these tags are referred to as VBRI.

Before digging into the details of each tag, let's wrap-up the question with which this post began: how to compute the duration of an .mp3 file? We have one solution, outlined above, that is known to be good in all cases, albeit expensive.

Now suppose we have parsed the first audio frame header, so we know how many samples are present in each frame (that's constant, remember) and what the sampling rate is for this frame. This gives us the duration of this frame, in seconds. Suppose further we have discovered a VBRI tag in that first frame (on which more below), and that that tag contains the total number of frames in this file. We can now compute the duration of the file by simply multiplying this frame's duration by the number of frames.

Well, it's very likely we can. That calculation is only accurate if the sampling frequency doesn't change. There's nothing that says it can't: every frame specifies it independently. However, I have never seen that happen in the wild. My sense is that every frame specifies it separately to avoid the need for a file header to specify it for all following frames. With the current arrangement, a decoder can connect to a stream of audio frames (think on-line radio), use the frame sync to "lock on" to the next frame it sees & just start playing. To confirm my hunch, I may concoct a pathological .mp3 file containing stretches of frames that use different sampling frequences & see which players get the duration correct & which don't.

Again for what it's worth, this is the approach taken by MPD: parse the first frame header & estimate the song duration based on that frame's bitrate & the track's total size (i.e. assume CBR). However, if the Xing frame is present, it will abandon that estimate & just multiply the first frame's duration by the total number of frames given in the Xing header.