I am using the latest version of EAC to rip to MP3 using the LAME3.98 encoder.
Additional Command Line Options: -V2 %s %d.

Question: If -V2 is meant to represent the ~192kbps, why do I get bitrates as low as 111kbps and bitrates as high as 280kbps. On average, most of my MP3's bitrates are between 210-->240kbps.

It is called variable bit rate - the encoder can use more or less bits when it deems it necessary to do so.

Of corse. I understand the concept of VBR. Just I thought it would have a minimum and maximum bitrate range based around whatever quality setting you have it set to.

Lame does have a minimum and maximum bitrate range: 32kbps to 320kbps. Lame does not care about bitrate but rather quality. The bitrate ranges shown on the Lame wiki page are simply estimates and your mileage may vary. I find that rap tends to encode at lower bitrates with some songs coming in at the 160kbps range while metal can produce songs in the 250kbps bitrate ranges and this is all when using -V 2. There are even some songs that cause Lame at -V 5 (~130kbps) to produce bitrates of 200kbps and above. So, when using a -V setting, Lame will encode your music to that quality even if it means using a extremely low or extremely high bitrate.

True VBR encoding means that an encoder has access to all bitrates at all time to produce the best quality. People who used to use programs such as CDex and WinAmp can often be confused by this as those programs have dialog boxes letting you chose the lowest and highest bitrate that will be used. You don't want to choke down an encoder such as Lame, you want to let it encode your files as normal.

Thank you very much.

Because of the 32 to 320 kbps limitation in MP3, LAME is not a true VBR codec, right? (There are parts to encode where more than 320 kbps is needed to keep the same quality)

I have noticed, just in passing, that LAME 3.98 seems to produce somewhat larger files than setting than LAME 3.96 at the same VBR setting. But I have made no quantitative meassurements so I could be wrong about that. I do agree that one should let the encoder make the decicions as to what bitrates are appropriate. That seems to me to be the whole point of VBR. If you want to control the filesize, use ABR.

I believe that OGG Vorbis has true VBR. My understanding is that frame sizes can be varied at will in that format, but what decisions the encoder makes given that freedom I don't know.

I have a problem similar to that of TheAlmighty. I was using EAC happily for a couple of years but had to reinstall it after having to reinstall Windows due to a corrupted registry.

I am now using the latest version of EAC to rip to MP3 using the LAME3.98 encoder.
Additional Command Line Options: -V2 %s %d

Whereas I was previously able to rip MP3s to roughly 192 kbps, the very same files are now almost all coming out at 320 kbps.

What is going on? Have spent all day searching for an answer on the internet.

I'm beginning to think that something must have changed in LAME 3.98. I saw, I think, 280 kbps the other day (at -V0) and I have never seen that before. Around 230 was a much more representative figure (with LAME 3.96). If I find the time, I may do some tests. I do have something riding on this.

You can still download LAME 3.96 from free-codecs.com (http://www.free-codecs.com/Lame_Encoder_download.htm). Maybe that tells us something...

3.98 produces higher bitrates than 3.97. Therefore it supports floating point quality settings. We've found out that 3.97's -V5 --vbr-new is similar to 3.98 -V5.7.

You can check it out yourself. LAME is open source. Here's changelog if you don't want to read source code: http://lame.cvs.sourceforge.net/*checkout*...ml/history.html



I don't see any problem with this. If you want bitrates around 230, use -V 2, -V 2.434352, -V 3 whatever. Just try out what suits you best and produces bitrates in the range you want.

As Sebastian said, obviously LAME 3.98 produces somewhat higher average VBR bitrates than LAME 3.97 did when the same -V setting is used.

I did extensive testing for the new MP3 VBR listening test and found out that LAME 3.98 -V5.7 is quite equivalent with LAME 3.97 -V5.

I have experienced a similar change with -V0. I'd say that now LAME 3.98 -V1 or maybe -V1.5 would be roughly the same as LAME 3.97 -V0, but I have not run a full test set yet. I am planning to do that using all -V values in 0.5 step increments. If I get it done I'll publish the results.


Edit: My old LAME 3.97 bitrate test results are still available here: http://www.hydrogenaudio.org/forums/index....st&p=328558

Even entering Additional Command Line Options: -V5 %s %d gives a file of 256 kbps whereas the same file was previously 192 kbps using my old -V2 settings.

Sounds like a problem with your EAC setup.

Where would the problem be?

I'm feeling very frustrated at this stage.

I'm no expert for EAC, but you may look there:
http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame

pen name,

In addition to rechecking the EAC settings you could temporarily replace the LAME 3.98 exe file with LAME 3.97 or some other older LAME version to confirm that the problem exists only with LAME 3.98.

Actually, where did you get the LAME 3.98 binary? Did you download the first/main LAME Bundle from rarewares or something else?

280kbps at V0, is very common with me on my music collection. Thats why I don't use V0.

I would specifically ensure that you have User Defined Encoder set.

Hi TA. As others have pointed out you should simply adjust your -V setting up a little bit until you're getting an average (over a large number of tracks) of about 192. Something around about -V2.5 should do it.

As for the wide variation in bit rate that's the way it's always been for Lame VBR because it targets a given quality level and not a specific bit rate. Since some material is inherently more difficult than others to encode to a specific quality then you get the large spread.

The most common situation where you get much lower bitrate than expected is where the material is mono or near mono. Under these conditions Mid/Side stereo decomposition gives a huge bitate reduction without loss of quality.

Another situation that reduces the bitrate is if the source material has limited frequency content, for example if it was originally from a 64kb/s wma file or something (don't laugh I've seen people do it).

On the other hand you tend to get higher than expected bitrate with material that's very dynamic, lots of high frequency and lots of stereo difference between left and right. It's harder to encode to the same quality so Lame just uses more bits but maintains quality regardless.

Not sure if this applies here, but what are you using to see the bitrate of your mp3 files? If you are looking at them in Microsoft's Windows explorer, it is a well known fact that it doesn't calculate bitrates correctly for vbr files and will often show 320 for many vbr files.

Bob

That would be extremely useful information, thank you. If you could post it (or a link to it) back to this thread that would be appreciated.

Just for context, our software uses LAME to encode to MP3 format (a) when recording from an analog source, and (b) when saving split-up tracks in MP3 format (from a master recording in WAV format, more often than not).

We have recently switched over to LAME 3.98 (from 3.96.1) and my concern is that (hard-coded) file-size estimates used to decide how many tracks to let a user add to his MP3 CD image might break (we only generate the files when the burn has actually been initiated). Call the concept flawed if you like, but it's what users expect. We do err on the conservative side, but we might need to change a few numbers in the code.

Your 3.97 stats fit in pretty well with the estimates we are currently using. We did tweak these for Lame 3.98, based on a few measurements we ourselves made, but possibly not enough. Here are the figures, based on some easy-listening (but very pleasant) Barbara Dickson tracks:

-V0: you (3.97): 241; we (3.98): 235
-V4: you (3.97): 154; we (3.98): 175
-V7: you (3.97): 104; we (3.98): 128

I think our V0 figure might be a little low.

TIA and good luck!

Good point. A better calculation is:

(file_size_in_bytes / file_duration_in_seconds) * 8 / 1000

Windows Media Player (10) seems to get it roughly right but I'm not sure I would trust it for a definitive answer.

No, the limitation is on the MP3 format. 320kbps is the maximum the mp3 format supports.

To whom it may be interesting. I have compressed several hundred songs using LAME 3.98 at V3 (most metal, rock, and electronic music) and the average bit rate is 169 kbs. I have done several ABX tests and could not differentiate a single song at all from the originals.

That is my general consensus but I was surprised to see so many "metal" songs with bitrates similar to Lame 3.97 at the -V 3 setting. I normally start to see bigger differences whenever I encode using -V 2 or -V 0. A song encoded with 3.97 at -V 2 will produce a 200kbps overall bitrate but 3.98 will increase the bitrate to 220kbps or so. 3.97 at -V 0 will go up to about 250kbps while 3.98 will commonly go up to 280kbps. I tend to find more similarities at the -V 3 setting and below.

I don't mind this though as I find -V 3 to be perceptually transparent, that is better than using -V 2 with any Lame mp3 encoder as the file sizes are smaller. So it does seem that 3.98 produces higher bitrates especially when using -V 2 and above. From my experience, 3.98 is able to produce about the same bitrates when using -V 3, -V 4, and -V 5 (though -V 5 is more hit or miss in terms of the bitrate matching 3.97).

Lame being limited from 32kbps to 320kbps does not mean that it isn't a true VBR encoder. It just means that the encoder is at the limit of the format. The Nero AAC encoder can go up to about 480kbps (if I remember correctly) so does that mean it is not a true VBR encoder? Not at all. Technically speaking though, the mp3 format can use higher bitrates up to 600kbps (again, if I remember correctly). This is known as free format with very limited software support along with slim-to-none hardware support. Now, limiting Lame to encode using a bitrate range of 192kbps to 320kbps would be throttling the encoder down. The files could still be VBR but not true VBR in the sense that one is limiting what Lame normally does. That is why it is just best to let Lame have its normal upper and lower limits of 32kbps and 320kbps. Limiting the encoder could actually produce sub-par results.

I recommend you to not mix things. First, freeformat can only output a CBR file, implying that it doesn't exist in the context of VBR encoding.
Next, freeformat should not be considered .mp3, for the scarce support in playback (it is not mandatory) and that, by definition, it does not conform to a common mp3 stream.

I don't have the knowledge, but to me, freeformat seems more like it was a tool to get a RAW stream, without headers or bitrate limitations, so that testing could be easier.

I really didn't want to complicate things by adding free format but I also didn't one someone to come along and say "I have 600kbps mp3 files so 320kbps is not the maximum bitrate that mp3 supports." For all intensive purposes (in the practical world), mp3 is limited to 320kbps.

We find that higher bitrate files work better with our declicker. Lower bitrate files tend to 'round off' the clicks, which makes them harder to detect.

That's what I also found out, and I don't have metal music.

Metal does greatly suffer from the sfb21 issue due to lots of high frequency conent.

It sure does. Seeing V2 encodes at 220 - 260 (3.97), is unfortunely normal to see on my music collection. Which is really making me, to consisder using AAC instead or the -Y switch.

I was listening to Satriani's Super Colossal, and I was wondering how many artifacts would you spot in this entire album, there is plenty cymbals on this album and V0 is getting me down to a doubt.