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: Can someone explain Bit reservoir for me? (Read 12060 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Can someone explain Bit reservoir for me?

Reply #1
It allows you to slightly vary the bitrate in CBR files without using vbr.

Can someone explain Bit reservoir for me?

Reply #2
FLAC has no bit reservoir because it is VBR.

Can someone explain Bit reservoir for me?

Reply #3
FLAC doesn't have it because it's not part of the spec for FLAC. It's an MPEG audio thing (MP3, AAC).

It's not just for CBR, but that's where it's used the most, because you get the most benefit there.

Since you've already seen the wiki article, I'm not sure how we can explain it any more simply, but I'll try.

An MP3 is segmented into frames, each one corresponding to the same amount (time-wise) of audio.
Each frame has a fixed size (data-wise), depending on its bitrate. You can think of it like different-sized hopper cars in a train. They only come in certain sizes (e.g. 320, 256, 224, 192 ...).
The audio data spit out by the encoder varies in size for each frame, because some sections of the music will just be simpler to encode and will compress better than others.
So, each hopper usually goes not-completely-filled, but occasionally some need to be overfilled.
If the file is going to be VBR, the bitrate can vary from frame to frame (different-sized hoppers can be used). That's usually sufficient to avoid wasting space in frames.
If the file is going to be CBR, though, the bitrate has to stay the same from frame to frame (the hoppers must be the same size), which pretty much ensures some space will be wasted.
Someone thought, "when a frame isn't filled up, why not use the leftover space to hold some of the data for the next frame?"
So every frame has a pointer that says how far back that frame's audio data really begins. This distance is the "reservoir".
It's like there's a reserve of space in the preceding frame(s) which can be used to overfill the current frame, if it ever needs it.
In effect, it's like a limited form of VBR. It lets some frames have more than their alotted amount of data.
The downside is that the reservoir can't grow very big, and once it's used up (by overfilling frames), it has to grow again.


Can someone explain Bit reservoir for me?

Reply #5
I should have said that FLAC is VBR, AND it is not limited to specific frame sizes, therefore it has no use for bit reservoir. Each frame contains exactly the number of bits that it needs.


Can someone explain Bit reservoir for me?

Reply #7
The back pointer "main_data_begin" should be Null for the very first frame, so the picture is misleading there. (I only found that picture, I didn't make it.)

Can someone explain Bit reservoir for me?

Reply #8
I've seen lots of post about using bit reservoir, and some say to use it, but does it actually degrade from the orginal source. I understand that MP3 is already lossy, and I am trying to get best quality that I can. I have posted a topic on this earlier and have got lots of help. I am messing around with Foobar but there isnt a bit reservoir option with V0 VBR. Question is use BR when using a VBR? Is there a difference if this is left off? I noticed it makes the VBR's lower on average depending on music. Metal seems to cut abr by about 15 where in jazz and rock seem to cut it by 20-even 30. Smaller doesnt always worse, espically since VBR's are supposed to be better then CBR's at a lower bitrate. So use it or not????

Can someone explain Bit reservoir for me?

Reply #9
I understand that MP3 is already lossy, and I am trying to get best quality that I can. I have posted a topic on this earlier and have got lots of help.


If thats your goal then none of this matters.  The encoder will manage it for you.  Pick the quality level you want and use that.  Implementation details only matter to developers. 


Can someone explain Bit reservoir for me?

Reply #10
I understand that MP3 is already lossy, and I am trying to get best quality that I can. I have posted a topic on this earlier and have got lots of help.


If thats your goal then none of this matters.  The encoder will manage it for you.  Pick the quality level you want and use that.  Implementation details only matter to developers.

I am guessing that I should leave bit resoviour alone when choosing my v0 choice. Even though some members here have said it should make a difference in quality, my guess is that v0 vbr is already determining the quality (well the lame encoder) for you so there is no need for using these and other advanced settings. There are those that have warned me "unless you know what you are doing, when using vbr leave the advanced setttings alone" (and I believe bit resouviour is off by default)

Can someone explain Bit reservoir for me?

Reply #11
The resERVOIr is on by default.

The only reason I can recall as to why one would need to disable it is for compatibility with problematic players.  Without concrete evidence, claims that its usage may degrade quality should be classified as bunk.

Can someone explain Bit reservoir for me?

Reply #12
Here's a simpler way (maybe) to explain the Bit Reservoir.  MP3 was originally designed for things like internet radio rather than for storing files on disk.  In order to be able to "tune in" to an MP3 radio stream, the encoder sends periodic data called a sync word that players look for.  The 4-byte sync words are transmitted in intervals that match the well-known bitrates.  The Bit Reservoir allows for the audio bitrate and the sync word bitrate to differ from each other slightly.  This allows encoders to have finer control over the bitrate on an instantaneous basis, rather than requiring each audio packet to be one of 14 sizes.

I've glossed over some of the details, but this might help. 

Some older decoders (early 90's) would not handle MP3 files encoded using the bit reservoir.  This is the only reason that encoders even allow you to turn it off.  From a technical perspective, there is absolutely nothing to be gained from turning it off.  I suspect that most encoders even do bad things when you turn it off, as the bitrate-choosing algorithms were designed with finer control in mind.

Can someone explain Bit reservoir for me?

Reply #13
The audio data creation process is exactly the same no matter whether bitreservoir is turned on or off with one important exception which is relevant in situations when the Lame VBR method finds a very compley spot in the music which needs a lot of bits.
With bitreservoir turned off Lame can use only the amount of data available in a 320 kbps frame (<320 kbps because of frame overhead). With bitreservoir turned on Lame can also use unused data space from within preceding frames. Bitrate can locally go up to ~580 kbps this way.
That's why it's foolish to turn bitreservoir off.

With bitreservoir turned off there's always a certain amount of unused bits in every frame. That's why average bitrate is higher, but not for any good reason. The higher amount of bits are bits in the mp3 file which are not used. Another reason why turning off bitreservoir isn't useful.

At the upper levels the mp3 encoding process isn't very difficult to understand:
The track to be encoded is subdivded into blocks (called frames) of 1152 wave samples each. Each of these blocks is encoded seperately, and for each block the encoder decides which audio data bitrate to use depending on the complexitiy of the music. Let's assume the encoder thinks that the current block needs 257 kbps. The audio data of each block are packaged into a corresponding container. When using mp3 these containers can't be of arbitrary size. They can only have a size wich corresponds to a bitrate of 320, 256, 224, 192, 160, 128, ... kbps. Now that the encoder needs 257 kbps, it must take a container of 320 kbps size, because the next smaller one doesn't allow for 257 kbps. Sure the 320 kbps container is too big. All the bits which belong to a bitrate beyond 257 kbps remain unused!!!! And if the encoder had demands for more than 320 kbps there is no chance that he will get the data space needed !!!! This is the situation with bitreservoir turned off. With bitreservoir turned on in contrary the encoder keeps in mind that we have a lot of unused data space in our 320 kbps container because only 257 kbps are used. This way the currently unused data can be used when it comes to encode the next block of 1152 wave samples. So when it comes to this the encoder can use more bits than available from a 320 kbps container alone which is very welcome when encoding a complex passage. At any rate the encoder will fill up the otherwise unused data in our current container with audio data from the next block.
That's why the bitresevoir is so useful.
lame3995o -Q1.7 --lowpass 17