Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Shouldn't there be a 288kbps bitrate (Read 12730 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Shouldn't there be a 288kbps bitrate

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...
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

Shouldn't there be a 288kbps bitrate

Reply #1
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.

Shouldn't there be a 288kbps bitrate

Reply #2
Quote
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.
[a href="index.php?act=findpost&pid=260355"][{POST_SNAPBACK}][/a]

ok, that makes sense. However, why didn't they make the bitrate index bigger than? Where would be the disadvantage?
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

Shouldn't there be a 288kbps bitrate

Reply #3
Quote
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.

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.

Shouldn't there be a 288kbps bitrate

Reply #4
Quote
Quote
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.

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.
[a href="index.php?act=findpost&pid=260375"][{POST_SNAPBACK}][/a]

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.
gentoo ~amd64 + layman | ncmpcpp/mpd | wavpack + vorbis + lame

Shouldn't there be a 288kbps bitrate

Reply #5
Quote
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.
[a href="index.php?act=findpost&pid=260351"][{POST_SNAPBACK}][/a]
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, [span style='font-size:8pt;line-height:100%']384, 448, 512 (okay, so these don't exist. I stuck them in to finish the pattern)[/span])
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.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

Shouldn't there be a 288kbps bitrate

Reply #6
Quote
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.

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.

Shouldn't there be a 288kbps bitrate

Reply #7
Quote
Quote
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.

Well, those extra bits will perfectly fit into the bit reservoir.
[a href="index.php?act=findpost&pid=260375"][{POST_SNAPBACK}][/a]

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
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

Shouldn't there be a 288kbps bitrate

Reply #8
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.

Shouldn't there be a 288kbps bitrate

Reply #9
Quote
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.
[a href="index.php?act=findpost&pid=260600"][{POST_SNAPBACK}][/a]

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...
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

 

Shouldn't there be a 288kbps bitrate

Reply #10
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..

Shouldn't there be a 288kbps bitrate

Reply #11
Quote
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...

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

Shouldn't there be a 288kbps bitrate

Reply #12
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.