I wonder why there isn't a 288kbps bitrate. There is just 256kbps and after that 320 kbps...I think this gap is quite big. Isn't that a waste of bits? I mean, let's say in a vbr mode, the encoder 'guesses' that it needs 270 kbps there is no way to use 256kbps and the reservoir to compensate the missing bits...so the encoder would have to use 320 kbps...but then, there is no way to store that many extra bits in the reservoir for the next frame.

Same thing for CBR modes. When mp3 was developed most people used CBR since no one could have guessed about LAME's 3.96.1 excellents --preset standard mode. And it's quite a size difference if I use CBR 256 or 320 kbps...especially back then...

The bitrate index located at frame headers is limited to 4 bits. That's why the format developers had to limit the amount of available bitrates.

ok, that makes sense. However, why didn't they make the bitrate index bigger than? Where would be the disadvantage?

Well, those extra bits will perfectly fit into the bit reservoir.

As Roberto explained, this is a limitation that comes from the bitrate index in the raw mp3 stream.

I think that Layer III inside mp4 container doesn't have this limitation.

If so then would there be a potential quality advantage in encoding directly to MP3 within an MP4 container? If so will this be possible with LAME 4? It sounds like yet another way to squeeze even better quality out of MP3.

As sort of a side note, the MP3 bitrates follow a vaguely exponential format:
Between 32 and 64, the steps are 8kbps (32,40,48,56,64)
Between 64 and 128, the steps are 16 (64,80,96,112,128)
Between 128 and 256 the steps are 32 (128, 160, 192, 224, 256)
Between 256 and 512 the steps are 64 (256, 320, 384, 448, 512 (okay, so these don't exist. I stuck them in to finish the pattern))
etc...

However, they could only use 14(*) of those bitrates, so they capped it at 320. This makes it look strange, as the last increment is the only one that has a difference of 64kbps, but it's all just following a pattern.

Hope that clears up why there's a big jump there

(*) The 14 is from using a 4-bit index, but one value is used for freeformat and one is invalid.

No, this doesn't help. It just change the way bits are stored.
Inside mp3 stream, you use fixed frame size and bit reservoir, inside mp4 container you use variable frame size but no bit reservoir.

In both case the upper limit regarding how many bits can belong to a frame is the same.

ok, I always wanted to know how many bits can be stored in the bit reservoir...according to EncSpot it should be 0,5 kilobyte...however, in my example there are 6,25 kilobyte that needed to be stored in the bit reservoir

Nope, they will be used.

The maximum number of bits belonging to a frame is equal to the number of bits that can be stored inside a 320kbps frame.

great! Is this just a 'LAME' invention or does that came with the mp3 standard...because I don't think FhG uses it that much...

Isn't there the ability to create 288kbps streams with MP1? (and even MP2?). I presume the frame header is still limited to 4 bits, 288 seems a more sensible option to have than, say, a lot of options around the 32-64 zone..

It is my understanding of the standard, and FhG uses that much.

Well, complaining now won't help, as changes to the bitrate table aren't possible without breaking compatibility.
MP1 supports 288 kbps, but as stated above, there are no steps between 32 kbps and 64 kbps which might be useful for voice.