Why are MP3 bitrates often multiples of 32? Part 2
Technically, there is nothing to limit the MP3 bitrate to a multiple of 2, as variable bitrate encoding can be used, or a custom bitrate can be achieved using some flags not used in the MPEG specification (although it must be implemented manually).
For MP3 to be MPEG-compliant, and therefore compatible with most MP3 decoders, it must have a bitrate defined by the specification, so all CBR-encoded MP3 files must have a bitrate that is a multiple of two.
Depending on the resource, VBR can be encoded by changing the bitrate between a fixed rate above each frame, or it can be encoded by sharing the available bits in adjacent frames (effectively generating a non-standard bitrate for the two frames combined). The length of a given frame depends on the sampling rate, there are 1152 samples per frame. There is nothing to limit the size of the frame itself, nor is there any limit to making the frame size base 2 (i.e. a 128 kbit/s MP3 with a 44.1 kHz sample rate would have a frame size of 417 bytes).
In the end, a file encoded at 126 kbps sounds worse than a file encoded at 128 kbps, and likewise a file encoded at 131 kbps sounds better. However, MP3s are encoded for compression according to the psychoacoustic model of a specific encoder. The amount by which a file sounds “better” or “worse” at a given bitrate depends largely on the algorithm used to implement the model; however, in general, higher bit rates can hold more data, likely reproducing Build a more accurate raw stream audio signal
I strongly suspect that the reason the MPEG standard specifies multiples of 2 is because binary computers can often optimize math involving both themselves and programmers.
This is a begging question. Don’t you think there is a mathematical/arithmetic reason for the chosen bitrate value? Or doesn’t the mere presence of VBR justify any limits on possible bitrates?
@slhck I’ve just updated my answer to provide more relevant details, please let me know if this answers all questions.
MPEG 1 Layer-III (mp3) files are streams of frames.
This web page details the data structure of the framework.
As you can see, only 4 bits are allocated to determine the bitrate. When designing a format for live streaming, you don’t want to waste more space than describing the stream.
I’m not sure exactly why 4 bits was determined to be a good compromise between space footprint and “bitrate resolution” – for the particular bitrate chosen, they were probably chosen based on the lowest and highest quality range that the engineer considered acceptable. mp3 algorithm.
Probably most MP3 players read one frame at a time, probably trying to “early” buffer at least one frame when decoding/playing the current frame.
The size of the frame and possibly the RAM allocated to it is as follows:
FrameSize = 144 * BitRate / SampleRate when the padding bit is cleared.
FrameSize = (144 * BitRate / SampleRate) + 1When the padding bit is set.
Higher bit rate/sample rate = more RAM required.
128 Kbps is probably popular as it is the default setting for many encoders.
Also, a colleague gave me insight into the discussion: 128 Kbps also roughly translates to “minutes in a minute” (unverified though), probably has something to do with that as well.
When “raw” data is logged, that data is buffered in chunks. These blocks will obviously be powers of two. It’s conceptually easier if you have an integer number of blocks per second.
