RFC 3119 (rfc3119) - Page 2 of 19
A More Loss-Tolerant RTP Payload Format for MP3 Audio
Alternative Format: Original Text Document
RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
2. The Structure of MP3 Frames
In this section we give a brief overview of the structure of a MP3
frame. (For more detailed description, see the MPEG 1 audio [3] and
MPEG 2 audio [4] specifications.)
Each MPEG audio frame begins with a 4-byte header. Information
defined by this header includes:
- Whether the audio is MPEG 1 or MPEG 2.
- Whether the audio is layer I, II, or III.
(The remainder of this document assumes layer III, i.e., "MP3"
frames)
- Whether the audio is mono or stereo.
- Whether or not there is a 2-byte CRC field following the header.
- (indirectly) The size of the frame.
The following structures appear after the header:
- (optionally) A 2-byte CRC field
- A "side info" structure. This has the following length:
- 32 bytes for MPEG 1 stereo
- 17 bytes for MPEG 1 mono, or for MPEG 2 stereo
- 9 bytes for MPEG 2 mono
- Encoded audio data, plus optional ancillary data (filling out the
rest of the frame)
For the purpose of this document, the "side info" structure is the
most important, because it defines the location and size of the
"Application Data Unit" (ADU) that an MP3 decoder will process. In
particular, the "side info" structure defines:
- "main_data_begin": This is a back-pointer (in bytes) to the start
of the ADU. The back-pointer is counted from the beginning of the
frame, and counts only encoded audio data and any ancillary data
(i.e., ignoring any header, CRC, or "side info" fields).
An MP3 decoder processes each ADU independently. The ADUs will
generally vary in length, but their average length will, of course,
be that of the of the MP3 frames (minus the length of the header,
CRC, and "side info" fields). (In MPEG literature, this ADU is
sometimes referred to as a "bit reservoir".)
Finlayson Standards Track