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: Some unusual results in lame 3.99.5 (Read 17354 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Some unusual results in lame 3.99.5

Hello All: Back once again for some more questions and I thank all that gave me a better understanding of VBR's and Bitrate. I have installed Foobar and its a great listening tool. I still prefer Media Monkey as its more user friendly, at least more friendly to me. I found it didn't have the latest version of lame installed since I was getting different bitrates in vbr mode when using mediamonkey vs foobar. I believe that the latest version of lame is is 3.99.5 I installed this into media monkey and have some strange results when encoding mp3's in vbr 0 mode. I understand that Bit Rate isn't always a means of measuring quality but I have seen some strange jumps in Bit Rate using the lastest version. I have no idea what the last version that was installed on Media Monkey, but I compared it to some songs that had the old encoder. I found what I thought were some unusual results. Here are some results of my bit rates and I will explain after I list them...

1. In VBR0 with old version of lame: Steely Dan's Black Cow=230kbps
2. Same setting with version 3.99.5 = 254kbps

1.VBRO old Version of lame-Cattle Decapatations "Testcular Manslaugther" = 298kbps
2.New 3.99.5 version=284kbps

I understand that bitrate doesnt always mean what it should when in vbr mode, but aren't these some strange jumps. Steely Dan gained 14bits. Cattle Decapatation lost 14 bits. Doesnt that seem odd? Is my version of lame good (i checked its not a beta) and if it isnt what version do people reccomend. I want the version that is going to be the most rock solid in VBR mode for me, since lame is choosing the quality for me. And a bonus question so to say: Does anyone have any scientific proof that a higher or lower average BR by lets say 15-20bits will make a difference. I understand BR isnt everything but the average does mean something. I was cruising along encoding, I know I am confused about this behavior.
PS---I reseached this version of lame, couldnt find anything about its reliability or anyone that had any problems, so if it was posted already in a previous forum, i applogize, I couldnt find anything on that particular version.

Some unusual results in lame 3.99.5

Reply #1
Different versions can give different results, so no this is not at all surprising.

As far as sound quality goes, no one will be able to tell you what you will or won't hear.  You will need to perform your own personal tests to determine this.

Have you tried to see if you can tell the difference using a lower quality setting with either encoder?  If you can't tell the difference with a lower quality setting, I wouldn't worry about what happens at a higher quality setting.

Some unusual results in lame 3.99.5

Reply #2
Different versions can give different results, so no this is not at all surprising.

As far as sound quality goes, no one will be able to tell you what you will or won't hear.  You will need to perform tests on your own personal tests to determine this.

Have you tried to see if you can tell the difference using a lower quality setting with either encoder?  If you can't tell the difference with a lower quality setting, I wouldn't worry about what happens at a higher quality setting.

No differences at all, at least with a listening test. Is this the newest version of lame?? Only reason I ask is it seems each version gets better. The Orginal reason I was turned off with MP3's from a few years ago was because of  the orginal encoders, well at least at 128CBR and below, weren't so hot. Now, with the better VBR's (well at least while trying to remain transparent) each version seems to get more technical and really create better transparency at lower bit rates. I just tested Linkin Parks Papercut VBR with V1 @ 238mbps vs a 320WMA version..No difference at all, at least I cant hear one, since Im not really sure how WMA's behave vs MP3's (There is hardly anything on WMA's, does anyone even use them anymore, well besides me until I ditched them last week and am turning my library into MP3 VBR's.

Some unusual results in lame 3.99.5

Reply #3
I  believe it's been several years since the LAME developers have changed anything that would affect sound quality.  (LAME changelog).

I don't know why you re getting different results, but there might be a different setting (or different default setting).  There are quite a few Lame Settings in addition to the 'V' or bitrate settings.

Quote
Does anyone have any scientific proof that a higher or lower average BR by lets say 15-20bits will make a difference.
Probably not at V0.    It depends on the program material and the listener, but V0 is generally overkill.  (You are more likely to hear differences at lower bitrate/quality settings.)

A lower bitrate at V0 might mean that the encoder settings are giving you more efficient compression (smaller files for the same quality) or it could mean that you are getting lower quality.  The only way to evaluate that is with a listening test.

If you can acheive transparancy (sound identical to the original) then there obviously can be no improvement with a higher bitrate (or higher quality setting).    On the other hand, if you are hearing MP3 compression artifacts at V1, you are probably going to hear them at V0 also.

Some unusual results in lame 3.99.5

Reply #4
The settings in Media Monkey are pretty basic: You can choose frm VO-V9. I choose VO. There are min and max bitrate which I leave at default (they are empty) and two boxes to check. The Bit Resoviour I have checked (enabled) and the Iso isnt checked. I was just shocked that One Song goes up in BR and another different song goes down. It like all my jazz and classic rock numbers are going up, and my hard rock and metal and going down. I cant hear a difference, but I just want to make sure I didnt screw anything up when I put the new encoder in. I did it by dragging and dropping. Download Lame. Unzip it, and replace the lame.dll file with the older one. Pretty Basic Stuff. As for all the command lines that you can add or delete, that looks pretty hardcore, more for people with programming knowledge, I guess??

Some unusual results in lame 3.99.5

Reply #5
Quote
The settings in Media Monkey are pretty basic: You can choose frm VO-V9. I choose VO.
Exactly!    We don't know everything Media Monkey is doing...    I could assume that every LAME front end/host would use the normal standard defaults, but something is different.

Realistically, unless you are trying to squeeze the best performance out of LAME, trying to get the smallest possible transparent files (or the smallest files with acceptable quality), I wouldn't worry about it. 

In fact, that's basically what I do...  I'm not too concerned with fle size, so I just use V0 and I don't worry about it...  If you are using low-quality settings, you should worry a bit more! 

Quote
I was just shocked that One Song goes up in BR and another different song goes down.
I don't understand that either, but I don't understand the detals of the psychoacoustic model or other internal workings of LAME.  ...So, I'm not that surprised when it does something I don't understand.

Some unusual results in lame 3.99.5

Reply #6
Behavior is normal.
With version 3.99 (maybe it was already with 3.98) the Lame devs had decided to stretch the -V0 / quality demand relation for the highest quality settings significantly more into the direction of higher quality demands. Sure a higher quality demand means higher average bitrate (when nothing else changes). Now average bitrate for a collection of various pop music is ~256 kbps for -V0. It was something like ~240 kbps before this decision, and varies from Lame version to Lame version a bit anyway as was said before.
MediaMonkey simply uses an old Lame version, and of course the current version should be used.
Whether this has an audible impact is another question, but this question is essentially the same question whether you use -V0 or -V1 (or any other -V level). With the Lame devs' decision your range of choices for quality demand is just extended a bit.
Another deveopers' decision was about the frequency range above 16 kHz. This frequency range has a significantly bad influence on bitrate because of a certain limitation mp3 has. The phenomenom is known as 'sfb21 bitrate bloat'. A hint for a sfb21 bitrate bloat is when a track's average bitrate is ~300 kbps. 3.99.5 deals with sfb21 bitrate bloat much better than old Lame versions did. So bitrate can also be lower than when using an old version.
I just realize that this is another example for 'lower bitraze = higher efficiency, not lower quality'.

You really care too much about bitrate.
lame3995o -Q1.7 --lowpass 17

Some unusual results in lame 3.99.5

Reply #7
Quote
The settings in Media Monkey are pretty basic: You can choose frm VO-V9. I choose VO.
Exactly!    We don't know everything Media Monkey is doing...    I could assume that every LAME front end/host would use the normal standard defaults, but something is different.

Realistically, unless you are trying to squeeze the best performance out of LAME, trying to get the smallest possible transparent files (or the smallest files with acceptable quality), I wouldn't worry about it. 

In fact, that's basically what I do...  I'm not too concerned with fle size, so I just use V0 and I don't worry about it...  If you are using low-quality settings, you should worry a bit more! 

Quote
I was just shocked that One Song goes up in BR and another different song goes down.
I don't understand that either, but I don't understand the detals of the psychoacoustic model or other internal workings of LAME.  ...So, I'm not that surprised when it does something I don't understand.


Thanks for clearing this up. I did a test and put the same version of Lame in Foobar v1.2.5 and same result. Did a test with Metal Band Vital Remains:
Foobar V0 Bitrate=285 & File Size is 15822kb
Media Monkey VO Bitrate=285 15786
So pretty much same stuff even with different media players.
I have analyzed many files with Foobar, it seems like nothing hardly ever hits the 320 mark..I see 305 usually at peak, strange, I guess this is why the 320CBR isnt even used anymore or should I say recommended. Mp3 has come a long way, even though viewed as lossy, the lossy part is almost non-existant at high bit rates.

Some unusual results in lame 3.99.5

Reply #8
Behavior is normal.
With version 3.99 (maybe it was already with 3.98) the Lame devs had decided to stretch the -V0 / quality demand relation for the highest quality settings significantly more into the direction of higher quality demands. Sure a higher quality demand means higher average bitrate (when nothing else changes). Now average bitrate for a collection of various pop music is ~256 kbps for -V0. It was something like ~240 kbps before this decision, and varies from Lame version to Lame version a bit anyway as was said before.
MediaMonkey simply uses an old Lame version, and of course the current version should be used.


I just update the version of lame to 3.99.5. Is this the current version? I still am only able to put V0~240 in media monkey, unless there is a way to change this. Same thing with Foobar. OR
I could just set the min bit rate setting to 256 cause I have that option in vbr mode. Even though this is more like a ABR mode, Im sure it wont hurt the MP3 encoding process or the quality.

Some unusual results in lame 3.99.5

Reply #9
The codec receives -V0 from the player when encoding.  The ~240 was added to the display by the developer of the player in order to give the user an idea of what the bitrate might be.  It has no bearing on the encoding process.  The number will need to be changed in order to more accurately reflect what is provided by the latest version of Lame.

Some unusual results in lame 3.99.5

Reply #10
The codec receives -V0 from the player when encoding.  The ~240 was added to the display by the developer of the player in order to give the user an idea of what the bitrate might be.  This number will need to be changed in order to more accurately reflect what is provided by the latest version of Lame.

I figured I would have to mess with it..Do I have to add something in the program lines to lame, and if so is there a topic or forum to show me how to do so in media monkey. Thanks


 

Some unusual results in lame 3.99.5

Reply #12
Please read my edit.

In case it is still not clear, the ~240 is for informational purposes only.  Who knows what MM actually sends to Lame.exe.

I got watcha are saying..crystal clear, and Im sure that at the high bit rates im choosing and the quality of VO, im sure it doesnt matter

Some unusual results in lame 3.99.5

Reply #13
I could just set the min bit rate setting to 256 cause I have that option in vbr mode. Even though this is more like a ABR mode, Im sure it wont hurt the MP3 encoding process or the quality.

I see you snuck this one in.  I think I'll go get some popcorn.

Some unusual results in lame 3.99.5

Reply #14
I could just set the min bit rate setting to 256 cause I have that option in vbr mode. Even though this is more like a ABR mode, Im sure it wont hurt the MP3 encoding process or the quality.

I see you snuck this one in.  I think I'll go get some popcorn.

LOL..already tried it and didnt make a difference...my OCD strikes again!! Having a CD that is giving me problem, its a Drum and Bass/Acid Jazz Mix. VBR @ V0 was given lower bitrates that I have seen for this kind of music. Average Bit Rate was 221 and when the bass hit low, it was a bit distorted. Switched to a ABR file with max setting of 310 with bit resouviour turned on. Average Bit rate went up which my OCD likes, but the sound was better. I guess even Lame farts once in awhile. Before you shred me to pieces, I dont care what the final number is, but when it comes out unsually low and there is some distortion @ VO it makes me wonder. Only time I experienced this, yet I am still new to the process

Pleaxe read my edited post. It should explain everything you started with in this thread. It also shows why Mediamonkey displays '240 kbps'.
Yes, 3.99.5 is the current version. Forget about bitrate, use 3.99.5  -V0 which brings you so much to the safe side that many users consider it a total overkill.
To ensure you how much you are on the safe side you might try -V5 which uses much lower quality demands than -V0 does, but I bet you'll have a hard time to find any issue when using -V5.
Did you really ABX the bass issue you were talking about? What were your results?
lame3995o -Q1.7 --lowpass 17

Some unusual results in lame 3.99.5

Reply #15
Yes, and brainless me did a test on the wrong song (well one right song and one wrong song, hence not the Same song), I was only using the bass parts which roll so they are similar and about the same time, then I listen for more then 30 seconds and a different part of the song kicks in..I think its time that I get off the puter..lol..ughhhh

Some unusual results in lame 3.99.5

Reply #16
Yes, and brainless me did a test on the wrong song (well one right song and one wrong song, hence not the Same song), I was only using the bass parts which roll so they are similar and about the same time, then I listen for more then 30 seconds and a different part of the song kicks in..I think its time that I get off the puter..lol..ughhhh

Next time post your ABX log.  We would have seen that you tested the wrong tracks.  This is assuming you actually conducted an ABX test.

Some unusual results in lame 3.99.5

Reply #17
Yes, and brainless me did a test on the wrong song (well one right song and one wrong song, hence not the Same song), I was only using the bass parts which roll so they are similar and about the same time, then I listen for more then 30 seconds and a different part of the song kicks in..I think its time that I get off the puter..lol..ughhhh

Next time post your ABX log.  We would have seen that you tested the wrong tracks.  This is assuming you actually conducted an ABX test.

I will do so for now on. well abx test of course..when i get done re-ripping this library, can i hire somone to do this please..lol

Some unusual results in lame 3.99.5

Reply #18
when i get done re-ripping this library, can i hire somone to do this please..lol
Sorry if this has already been mentioned, but are ripping from CD directly to MP3? The usual advice is to rip to lossless, if disk space is not a concern for you: doing so, you do the hard work once and can then easily batch convert to whatever lossy format you want.

HTH.

Alessandro

Some unusual results in lame 3.99.5

Reply #19
I understand that bitrate doesnt always mean what it should when in vbr mode, but aren't these some strange jumps. Steely Dan gained 14bits. Cattle Decapatation lost 14 bits. Doesnt that seem odd?
Not in the slightest. Why should one expect that changes to the algorithm will result simply in a uniform gain or decrease in the mean bitrate for every possible input? Also, it’s kbps, kilobits per second.

Quote
Is my version of lame good (i checked its not a beta) and if it isnt what version do people reccomend.
I mentioned in your other thread that default settings are usually default for a reason, and analogously, the latest version of any given program has usually been released for a reason, specifically the fact that the developers are confident that it represents an improvement over the last. Otherwise there’d be no need to ever update anything, and everyone would still be using certain (in)famous versions from years ago… something that some people don’t seem to want to let go of.

Quote
Does anyone have any scientific proof that a higher or lower average BR by lets say 15-20bits will make a difference.
How can someone ‘prove’ this? An altered bitrate on which song(s)? To which listener(s)? How many of each do we need to sample before the summarised results will be representative of you or any other potential listener(s)? If previous references to proper methods of testing haven’t made it clear yet, the performance of a lossy codec ends up mattering only in terms of whether or not it encodes a given signal transparently to the specific person who is listening to it. We simply cannot answer questions this vague with any confidence. Unfortunately the world does not always work easily enough that people can provide you with one-shot answers for things. Again, it comes down either to performing your own tests and trusting their conclusions, or to trusting the conclusions of other people’s tests (N.B.: tests, not evidence-free subjective ramblings) and that they will be applicable to you.

Some unusual results in lame 3.99.5

Reply #20
Im sorry to have not been more specific. I was looking to see when developers are programming lame, do they have a target bitrates in mind when they are writing the code for VBR mode? My feeling from what I am reading from others is that it looks like they are trying to make lame produce the best of both worlds. Smaller file sizes with less transparency. Im not sure if the following statement is true but if the bitrate is larger, wouldnt the file size also be larger??  I am not stating this as a fact or opinion, but as a question. I can only think that with this newer version of lame it seems like they increased bit-rate on songs that would previously use less bits, and the songs that used more bits, they decreased, almost like a happy medium. ONce again, I have no idea if this is true, I am only taking a educated guess and have no way of backing this up, it just seems logical. I also see from foobar that when I play my songs, the bit-rate doesnt usually go over 300. Im I to assume that lame developers are finding that music is hardly using those bits in the high range. Its really cool stuff, and I love how the technology has grown. Sorry, its a long statement, but I am hoping I am getting a better idea of lame is doing as it advances to a newer version.

Some unusual results in lame 3.99.5

Reply #21
The frame sizes have to be 320, 256, 224, 192, 160, 128, etc.
The developers will use the smallest size that will accommodate the data needed for a certain quality level.
So if to get the desired quality level, they need a 300 kbps frame, they will have to use a 320 kbps frame.
They're not going to try to fill up the extra space.
But that is what the bit reservoir does... that extra space is available for the next frame.

Some unusual results in lame 3.99.5

Reply #22
Im sorry to have not been more specific. I was looking to see when developers are programming lame, do they have a target bitrates in mind when they are writing the code for VBR mode?


In what follows, 'transparent' means audibly-indistinguishable from the original lossless audio.

No, as a crude rule of thumb, usually LAME is optimized to be usually transparent at around -V2 or -V3 (-V2 was once called 'standard' preset for that reason) and uses only just as much accuracy as it needs and hardly any more (which means it allows almost as much distortion or noise at it can get away with). The data is then packed into as few bits as possible, so the bitrate simply falls where it may rather than being targetted.

Over the years, problem samples or 'codec killers' have been found, revealing errors in the psychoacoustic model that decides how much of which types of distortion is allowed, leading to corrections that 'fix' the problem samples without wasting too many bits on non-problematic samples.

For the most part, settings such as -V1 and -V0 add in a little extra margin of safety by requiring slightly higher accuracy than was calculated by the psychoacoustic model. This accounts for a lot of the extra bitrate they consume and the amount of margin allowed might have been chosen by the developers with the resulting bitrate increase over a large corpus of music in mind, but with no idea of the bitrate from moment to moment.

The extra accuracy in -V1 or -V0 is spread thinly over reducing distortion across the frequency range and increasing temporal accuracy somewhat, so it might marginally reduce the audibility of subtle flaws in the psychoacoustic model compared to the -V3 or -V2 version, and might make a subtle flaw at -V2 become just inaudible and thus transparent at -V0, for example.

Any major flaws in the psychoacoustic model will not have the extra bits applied only to the problematic part (because the model doesn't know where it should have applied them), so major flaws will often be only marginally improved by higher quality settings.

For example, flaw A might go from 'very annoying' at -V2 to 'somewhat annoying' at -V0 while flaw B might go from 'somewhat annoying' at -V2 to 'perceptibly different but not annoying' at -V0, and a different flaw C might go from 'somewhat annoying' at -V2 to 'transparent' at -V0. It varies from case to case, with different classes of problem sample.

The aim of the LAME developers is typically to fix flaws in -V2 or -V3 by improving the psychoacoustic model so that it allocates extra accuracy (and as a consequence, momentarily-higher bitrate) to just the right places in those problem samples without increasing the accuracy and thus without increasing the bitrate for the majority of non-problem samples. The developers have naturally concentrated their efforts on most of the annoying problem samples in early years, and now that LAME is mature, they have few annoying problem samples remaining.

Below is a crude picture of how an 'only just transparent' idealized Constant Quality (i.e. Variable Bit Rate) audio encoder might work.
There are complexities I'm omitting for simplicity, and I'll use the word 'chunk' instead of the words like 'frame' or 'granule' to avoid implying that I'm referring to specific details of an encoder such as LAME.

1. Divide the audio into 'chunks' of a few tens of milliseconds

2. Analyze the current 'chunk' of audio, deriving its frequency spectrum (the loudness of each 'pitch' in the sound)

3. Detect whether a fast 'transient' sound, highly localized in time, occurs within the current chunk or not.

4. If a fast 'transient' was detected, subdivide the chunk into a number of short blocks. Short blocks allow the transient to be encoded with high time resolution using relatively few bits at the expense of reduced frequency resolution (for technical reasons I will omit), and frequency resolution is usually less important during transients.

5. If there was no 'transient' detected, use long blocks to encode high frequency resolution with fewer bits at the expense of lower time-resolution.

6. Apply a Modified Discrete Cosine Transform (MDCT) to each block in the current 'chunk' to convert it from a loudness-versus-time representation to a loudness-versus-frequency representation, divided into some 'subdivisions' roughly comparable to certain aspects of human hearing.

7. Calculate the Masking Threshold of the signal as a function of frequency (and if following a transient, calculate masking as a function of time, too - called Temporal Masking). This uses the fact that the ear becomes less sensitive to subtle difference for sounds that are close in pitch to a louder sound, allowing their loudness to be encoded with less precision without sounding any different. (Temporal masking uses the fact that the ear is less sensitive for sounds that occur immediately after a brief loud sound)

8. Apply an offset to the calculated Masking Threshold if you want to provide more margin of safety (a bit like LAME -V0) or less margin of safety (a bit like LAME -V5). For example you might add 10 decibels of safety margin to all frequencies.

9. For each 'subdivision' of the MDCT data from step 6, calculate what bit-depth will ensure that the quantization noise caused by that bit depth will remain just below the calculated and offset Masking Threshold from step 8 and quantize to that bit-depth. This quantization is the main LOSSY step in the process.

10. Losslessly pack the data in an efficient manner using similarity between left and right channels and so on to improve efficiency. The number of bits this takes up (which equates to the bitrate) is not known before this stage. Store it according to the format specification so that a decoder can reconstruct the lossy audio later.

11. Move on to the next 'chunk' of audio and repeat from step 2.

You'll note that this idealized constant-quality encoder does not decide on the bitrate, it just emerges naturally from the decisions made and the analysis of the audio and how well the lossless part of the packing happens to work.

In reality, the choices available to the developers in tuning the quality scale such as LAME's -V n scale are more varied than suggested by step 8 above.

One aspect is the frequency of the low-pass filter, which is raised at higher quality settings like -V0 and lowered at low settings like -V5. A few semitones of extra bandwidth at the top end costs a lot of bits, and reducing the lowpass to around 16kHz can save a lot of bits to spend where they really mattter more on -V5.

Likewise at lower quality settings, a developer may choose to sacrifice a little accuracy at the extreme frequencies to allow more accuracy to be retained at the most important frequencies for typical music and at higher settings, the extremes may receive less of the extra margin of safety than the most important frequencies.

So, even once the 'problem samples' have been 'solved' in the early stages of encoder tuning, the developers can still choose how to make the varying scale of adjustments from the supposed ideal Masking Threshold and the standard low-pass filter frequency as the quality number is changes. The developers do have a range of choices, which will affect the bitrate, and especially for lower-quality settings, they'll affect the quality. They also occasionally come up with more efficient ways of working round limitations of the format (e.g. 'sfb21 bloat' was mentioned elsewhere) which will allow lower bitrate for the same quality but may also allow a greater margin of safety at the same typical bitrate for the higher settings like -V0.


Some more advanced formats than MP3 include special tools that can provide pretty good accuracy using very few bits. Sometimes these achieve high accuracy with fewer bits than older encoders. Sometimes they allow reduced accuracy in the less important aspects of audio to concentrate the lower bitrate on the most vital aspects. An example is in low-bitrate AAC audio, the HE-AAC version makes an approximation of the high frequency spectrum estimated from the low-frequency spectrum and relatively few numerical parameters (this is called Spectral Band Replication) and performs better than LC-AAC at around 64kbps. At even lower bitrates, the precise stereo image is replaced with a method of steering portions of the monophonic audio with a few numerical parameters. This is called Parametric Stereo (in HE-AAC v2, where it works in conjunction with Spectral Band Replication) and it performs better than HE-AAC at around 32kbps. Both of these methods allow what little bitrate is available to be spent on encoding the most important parts of the signal better. Similarly, Ogg Vorbis and Opus/CELT have some special tricks up their sleeves to allow the spectral envelope to be encoded quite efficiently to eliminate certain nasty artifacts and improve the bitrate efficiency of transparent encoding.
Dynamic – the artist formerly known as DickD

Some unusual results in lame 3.99.5

Reply #23
... I can only think that with this newer version of lame it seems like they increased bit-rate on songs that would previously use less bits, and the songs that used more bits, they decreased, almost like a happy medium. ...

Bullshit. I explained you all that's necessary here for those tracks you think have an unusual behavior when encoded with 3.99.5.
You have a totally insane imagination about what is going on only because of your primary love for bitrate as a quality criterion while disregarding everything you're told here.

But I'll try to explain what the devs do with the VBR encoding process when they develop a new Lame version.
Point 1: They definitely don't think about bitrate the way you do. period.
Point 2: What they do in a nutshell is: they change the parameters which control the psychoacoustic model (for example the sensitivity with which the ATH curve is taken into account, or the way  sfb21 is treated), they make changes to the various decision processes which happen during the encoding process (for instance whether the left/right or mid/side representation of the music should be used or whether long or short blocks should be used), and other things like that. You don't have to know about them, just trust the devs. These things are changed for good reasons, for instance because a certain audible issue is tackled.
Changes in bitrate are consequences of this, not the motivation for it. And of course it's trivial that the net result of all these changes can bring bitrate up for trackA and bring it down for trackB, depending on the musical content of these tracks.

You really shouldn't care about bitrate.
If you still do despite everything you are told you are probably not the person to use VBR. If you're so inclined to see a correspondance between bitrate and quality (and you even do on a single-track-basis which is insane+ for VBR encodings) you may find better peace of mind by using ABR.
lame3995o -Q1.7 --lowpass 17

Some unusual results in lame 3.99.5

Reply #24
No, this is totally the information I was looking for. Hey, unfortuanally the average users who use rip music, use media players that have the such settings such as CD quality at 128, or 320Best Quality. Thats how I looked at it for years, and until this week I'm learning and moving myself in directions of vbrs. I cannot comment on them since I havent done ABX testing on them, but lets just say Im satisfied, even though you all think I am insane with bitrate. I only figured that Bitrate had something to do with the development, only because its been jammed down average users throats for years, including myself. I love when people get into comments such as "well screw joint stereo" im going stereo man." But I cant blame them because there had been so much trash littered over the web about MP3's and lossy music. Another factor is bad experience with MP3's at low bitrates. I remember when my buddy first got his MP3 player and MP3 was still new technology. Might have been the first version of lame it was so long ago, but lets just say that they didn't impress me then, and when I found out the BR he was using, I was like, Man when I get my player, its 320 dude, the heck will those little BR's...LOL..For all i know they could have been fine, but with quick research I was persuaded to use high bit rates, and yes with no evidence of test studies, just word of mouth from all those that said 128 is garbage. It takes me some time to get a feel for new things, espically when you are breaking my so called routine of ripping in high bit rate mode for years, LOL. I have been doing some sound testing, not ABX testing, and since its not ABX I cannot give you my results, but lets say Im glad I took everyones advice here. Enough Said. Lets just try to pass great info on to other users, so maybe they will save some space, and not have sleepless nights cause something came out at 197. LOL. I did like you part b of your results the best, because that really answeared my question that I have been looking for. So for all the moderaters and programmers that have just been put through hell, thank you. I am one stingy SOB. Dont worry though, others will come crawling looking for information and might not even make it as far as I did. Thanks again, even though I am a bit insane..LOL