Why are MP3 bitrates usually multiples of 32? (powers of 2)

Question

I understand why multiples of 2 show up so often in with computers because of their binary nature, but I haven't been able to figure out the most common mp3 bitrates (64kbps, 128kbps, 160kbps, 192kbps, 256kbps, 320kbps, etc.) tend to follow this rule as well.

• Since MP3s are just sequential encodings of sound waves, why does it matter that each second is represented with a number of kilobits that is divisible by 2?
• Do music players like iTunes just keep reading the file and reproducing the encoded sound regardless of where the second boundaries are, or do they read the file second by second?
• In the later case, reading a 256kbps file would require reading slightly fewer pages in memory than a 257kbps file, but the player could always just read in 256-kilobit chunks regardless of them bitrate and just process it gradually, right?
• Are MP3s at 128kbps popular just because this is a generally accepted bitrate or do they actually have some advantage over files at 126kbps and 131kbps other than a very slight difference in quality/filesize?

Answer 1

For constant bit rate encoding (CBR), the MPEG-1 Audio Layer III standard specifies standard bit rates of 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320 kbit/s. There are others defined in the MPEG-2 standard, but they are all multiples of 2 as well (actually, all multiples of 8 in the range 8 to 160 - see the table labelled "Bitrate index" in the link above).

Technically, there is nothing limiting an MP3's bitrate to a multiple of two, as variable bit-rate encoding may be used, or a custom bitrate may be implemented using some of the unused flags from the MPEG specification (although this would have to be implemented manually). For an MP3 to be compliant with the MPEG specification, and thus compatible with most MP3 decoders, it must have a bit-rate as defined per the specification - thus, all CBR-encoded MP3 files will have a bit-rate as a multiple of two.

According to the resource, VBR can be encoded by either switching the bitrate between the fixed rates above per-frame, or it can be encoded by sharing the available bits in adjacent frames (effectively yielding a non-standard bitrate for the two combined frames). The length of a given frame is dependent on the sampling rate, with 1152 samples per frame. There is nothing restricting the size of a frame itself, nor is there any restriction for a frame to be a base-2 size (i.e. a 128 kbit/s MP3 with a sampling rate of 44.1 kHz will have a frame size of 417 bytes).

---

Lastly, a file encoded at 126 kbps will sound worse than one at 128 kbps, and likewise, one at 131 kbps will sound better. However, MP3's are encoded according to a particular encoder's psychoacoustic model for compression. The amount a file will sound "better" or "worse" at a given bitrate is highly dependent on the algorithms used to implement the model - however, in general, higher bitrates allow for more data, presumably reconstructing a more accurate stream of the original audio signal.

Answer 2

MPEG 1 Layer-III (mp3) files are a stream of frames.

This web page details the data structure of a frame.

As you can see, only 4 bits were allocated to determine the bitrate. When designing a format for something that is meant to be streamed in realtime, you don't want to waste more space than you have to describing things about the stream.

Not sure precisely why 4 bits was determined to be a good tradeoff between consumed space and "bitrate resolution" - and regarding the specific rates chosen, they were probably chosen according to what the engineers judged were the acceptable lowest and highest ranges of quality for the mp3 algorithm.

Likely most MP3 players are reading in a frame at a time, possibly trying to buffer at least one frame "ahead" while the current one is being decoded/played.

The size of the frame, and likely the RAM allocated to hold it, is this:

• FrameSize = 144 * BitRate / SampleRatewhen the padding bit is cleared.
• FrameSize = (144 * BitRate / SampleRate) + 1 when the padding bit is set.

Higher bitrates/samplerates = more RAM needed.

128Kbps is likely popular because it's the default setting on many encoders.

Also, a co-worker gave me some insight on this during a discussion: 128Kbps also roughly translates to a "meg a minute" (haven't verified, though) - might also have something to do with it.

Answer 3

When recording the "raw" data, the data will be broken into blocks for buffering. These blocks are obviously going to be powers of two. It's simplest conceptually if there is an integer number of blocks per second.