...and I came across something rather unusual. So I thought I would just pick the brains of the HA gurus.


I ripped a song to 320 CBR using Lame 3.97.

Then I ripped the same song at the same bitrate using Lame 3.98.

My intent was simply to do an A-B between the two files to see if I could detect anything audible. But that's when I discovered something odd. When I opened the files in EncSpot, I found that the file encoded with 3.97 made rather extensive use of the bit reservoir.





But the file encoded with 3.98 barely used the reservoir, if at all.





And it's NOT an isolated fluke. I have ripped at least ten different songs from varied genres of music...metal, classical, jazz, rock, fingerstyle guitar, all kinds of stuff. And the results are always the same.

Now here's the question. I can plainly see this. The difference is not subtle. The only question in my mind is what, if anything, does it mean? Anyone have any info? Thoughts? Musings? Rants?

Abx please?

I think he just means the visible difference between reported reservoir usage.

Anyway I thought bitreservoir usage was re-introduced with 3.97b2.
We had a fruitful discussion about that then.
Why is bitreservoir given up again which allows audio bitrate to go up into the 400 kbps range?

For compatibility with strangely constructed decoders there should be another solution (let anything like that go into the strict-iso or a more advanced compatibility switch) IMO.

Or is it just to make the weakness in the psy model more transparent 3.98 is about to solve?

Correct. And thanks for not letting your knee jerk.

Hoosierdaddy: on another unrelated note, please don't use JPEGs for screenshots of programs with solid blocks of color like that. Use PNG, so you can avoid ugly artifacts.

Some mp3 decoders (such as the crappy fhg decoder on wmp) have had problems with LAME 3.97 320 kbps CBR due to the bit reservoir, which could be fix by using the --strictly-enforce-ISO.

LAME 3.98 forces the --strictly-enforce-ISO switch might have might have made some notable changes to the bit reservoir.

It took me a moment to realize what this meant: -strictly-enforce-ISO means that there should never be more bits in a frame, counting those bits associate with this frame but stored in another (via the reservoir) than would fit in a standard 320kbps frame? Less is OK, but never more with this flag?

And since at 320kbps CBR, all frames will be already be 320kbps frames, adding *anything* to the bit reservoir would cause the final bitrate of some frames to exceed 320kbps? Breaking compatibility with some devices...

-brendan

So in other words, the absence of anything in the bit reservoir is a good thing? Then I'm really confused. Because I seem to recall a rather lengthy thread around these parts discussing how use of the bit reservoir was a positive thing.

Perhaps a non-technical explanation of what the bit reservoir is and it's purpose is in order? Just for us non-scientists of course.

Only in the case of "320kbps CBR". If you use "< 320kbps CBR" or any "<= 320kbps VBR", then the bit reservoir will be used.

The issue, again, is that some devices cannot handle more than 320kbps-sized frame data, even if the data that makes the frame > 320kbps is stored in a different frame.

-brendan

By "devices" you mean hardware devices...like MP3 Players...right? Because I've never had an issue playing any of my rips on a PC with a software based player.

That is correct.

-brendan

I've never had any MP3 players screw up with pre-LAME 3.98 encoded files

I was in a lengthy discussion with Gabriel about that some time ago cause in 3.97b1 bit-reservoir was not used with cbr 320. However bit reservoir was used in a way that was quite mixed up depending on lame usage mode.

It's like this:

a) The less the restrictions are on the usage of bit reservoir the higher is the quality potential of the encoder.
320 kbps frames which additionally are allowed access to the bit reservoir can have an audio bitrate in the 400 kbps range.

b) The mp3 standard is not very clear about 320 kbps frames. It can be interpreted in the sense that 320 kbps frames are not allowed access to the bit reservoir. In fact this is the interpretation which is most probably correct. FhG encoders behave this way.

c) Looking at it from the decoder side it would be pretty foolish to make sure this 320 kbps frame side condition is fulfilled for the usually 44.1 kHz sampled tracks.
That's why very few decoders bahave badly in this respect. As for compatibility there is other stuff at least of the same concern as this. Some decoders don't play 320 kbps tracks at all, some have difficulties with vbr, some with other features of the mp3 format.
The reason why real decoders usually don't have problems with 320 kbps frames using bit reservoir is simple. In case there is no explicit check (which would be foolish as it was an extra effort and would unnecessarily restrict usage of the decoder) the only problem can be a limited buffer size. But as buffer size needed is small anyway, and as a decoder has to work with 320 kbps 32 kHz sampled tracks, it is pretty safe to use bit reservoir at least to the extent that anything needed during frame decoding fits into the buffer of a size needed for 320 kbps 32 kHz sampled frames. This is essentially how 3.97b2+ is working (but IIRC bit reservoir is restricted a little bit more).