IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Can someone explain Bit reservoir for me?
djchristian
post Jan 29 2013, 17:04
Post #1





Group: Members
Posts: 41
Joined: 22-December 09
Member No.: 76233



I try to struggle to understand what this does. I am relatively new on this area

http://wiki.hydrogenaudio.org/index.php?title=Bit_reservoir

What does it do really? Does FLAC have Bit reservoir too?

Thanks in advance!
Go to the top of the page
+Quote Post
saratoga
post Jan 29 2013, 17:35
Post #2





Group: Members
Posts: 4865
Joined: 2-September 02
Member No.: 3264



It allows you to slightly vary the bitrate in CBR files without using vbr.
Go to the top of the page
+Quote Post
pdq
post Jan 29 2013, 18:14
Post #3





Group: Members
Posts: 3374
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



FLAC has no bit reservoir because it is VBR.
Go to the top of the page
+Quote Post
mjb2006
post Jan 30 2013, 05:25
Post #4





Group: Members
Posts: 758
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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.

This post has been edited by mjb2006: Jan 30 2013, 05:29
Go to the top of the page
+Quote Post
robert
post Jan 30 2013, 08:44
Post #5


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



http://finalscratch.sourceforge.net/bit_resevoir_image.png
Go to the top of the page
+Quote Post
pdq
post Jan 30 2013, 13:33
Post #6





Group: Members
Posts: 3374
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



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.
Go to the top of the page
+Quote Post
mjb2006
post Jan 30 2013, 16:59
Post #7





Group: Members
Posts: 758
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (robert @ Jan 30 2013, 00:44) *


That's a good graphic. I'm surprised to learn that main_data_begin for the first frame is the beginning of its header, not its main info. Is that right?
Go to the top of the page
+Quote Post
robert
post Jan 30 2013, 17:08
Post #8


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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.)
Go to the top of the page
+Quote Post
ThomasG3rd
post Apr 29 2013, 03:03
Post #9





Group: Validating
Posts: 30
Joined: 26-April 13
Member No.: 107852



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????
Go to the top of the page
+Quote Post
saratoga
post Apr 29 2013, 03:23
Post #10





Group: Members
Posts: 4865
Joined: 2-September 02
Member No.: 3264



QUOTE (ThomasG3rd @ Apr 28 2013, 22:03) *
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.

Go to the top of the page
+Quote Post
ThomasG3rd
post Apr 29 2013, 03:46
Post #11





Group: Validating
Posts: 30
Joined: 26-April 13
Member No.: 107852



QUOTE (saratoga @ Apr 28 2013, 19:23) *
QUOTE (ThomasG3rd @ Apr 28 2013, 22:03) *
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)

This post has been edited by ThomasG3rd: Apr 29 2013, 03:47
Go to the top of the page
+Quote Post
greynol
post Apr 29 2013, 04:51
Post #12





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
benski
post Apr 29 2013, 05:26
Post #13


Winamp Developer


Group: Developer
Posts: 670
Joined: 17-July 05
From: Brooklyn, NY
Member No.: 23375



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.

This post has been edited by benski: Apr 29 2013, 05:31
Go to the top of the page
+Quote Post
halb27
post Apr 29 2013, 12:36
Post #14





Group: Members
Posts: 2424
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Apr 29 2013, 13:36


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th July 2014 - 18:58