On the hydrogenaudio wiki pages, it says that the size of the bit reservoir for mp3 is 511 bits. Is this correct? That seems like a really small number to me. I'm not sure what are the byte-sizes of the mp3 frames, but I think they are maybe roughly 1 kilobyte for a single 320 kbps frame, 500 bytes for a 160 kbps frame, etc (I could be way off with these numbers, anyone please correct me if they are wrong).

511 bits (not bytes) seems like it would be insignificant in comparison. Did the hydrogenaudio wiki mean to say 511 bytes, maybe? (I am not trying to imply anything, just asking).

Also, as a side note I noticed that the bit reservoir is off (for compatibility reasons regarding maximum framesize) for 320 kbps CBR files in LAME 3.95. According to what I've seen others say here, it is also off for 3.96. Supposedly it is reinstated for 3.97, but in 3.98 if the docs are to believed it may be gone again (or restricted to a tiny size that is essentially not very significant). I have no idea if it is on or not for 320 kbps CBR in earlier versions of LAME or other encoders.

One question I have about this is, if the bit reservoir is off at 320 kbps, how does huffman encoding/compression benefit 320 kbps mp3s? My understanding is that the huffman encoding gains a tiny amount of extra lossless compression on the mp3 file, which saves bits which are stored in the bit reservoir and thus become available to increase the bit size of future frames and increase the quality of the mp3 file overall. But if there is no bit reservoir, is the huffman encoding still able to perform its intended function?

Maximum bitreservoir is 511 byte.

The huffman coding used in mp3 has no relation whatsoever to the bit reservoir.

That's right. It's merely the method of coding the information. It uses shorter codes to represent the symbols with greater probability, so it is efficient only during pure tones. On the other hand, it's not usefull in multitimbral parts (most of the time in contemporary music )

All of that is quite simply not true.

In fact, the huffman coding in MP3 and AAC will have it's hardest time exactly when dealing with strong, pure tones, but has no issues with noisy parts or contemporary music.

Thanks for the responses, everyone.

After reading these posts here I also did some more net-searching on the huffman issue, and what I found supports that Garf and eevan were correct when they said the huffman coding has no relation to the bit reservoir. I also found the articles that made me think that it did, and I think I figured out the source of my confusion.

The huffman coding itself gains an extra amount of lossless compression on the audio, but in general a tiny, tiny, tiny amount of extra bits may be wasted after the huffman compression is done, because the huffman compressed data will generally be a tiny tiny tiny bit less than the allowed, specified framesize. That's because there's no way to predict how large the huffman-processed data will be until after it is calculated. To fix this, mp3 I guess is using a loop and if the final huffman data is smaller than the allowed framesize, it will start that frame again from scratch (with a finer quantization at the psychoacoustic part of the encoding). After enough loops the data should fit in the specified framesize very well, so the huffman compression is effective and independent of the bit reservoir.

But, a super super tiny tiny tiny fraction of bits per frame will generally be wasted after the looping is completed, and I guess that is what can go into the bit reservoir (therefore is not wasted, except in 320 kbps CBR). But that's only a tiny fraction of the amount of compression the huffman process achieved, so mostly irrelevant I'd say.

Maybe what I said is still incorrect. But regardless, thanks for the help, guys.

I don't know, but I've found a similar explanation here. And it supports what I know about Hufmann coding. Don't get me wrong, I just want to be sure.