In comparison to Winamp mp3 plugin, the modern LAME recommendations-- do not even mention -q-- do not dwell on bitrates -- instead settle on --vbr-new by making it default-- instead explain a lot about -V for VBR that are not offered by Winamp

apodtele: the link you've directed at me doesn't seem to be the one i remember seeing some time back on what is meant to be done in a UI for controlling lame. which was http://lame.sourceforge.net/lame_ui_example.php and as i've not followed things closely, my comment was worded as such to cater for things having changed with those suggested guidelines (though looks like i remember it being).

either way, no one is disagreeing that Winamp's mp3 encoder config needs to be overhauled, but trying to base what is currently there against documentation which has most likely changed since the encoder's ui was created (which if i remember correctly goes back to the original Winamp dev team) is never going to match up. also without checking, i was under the impression that the encoder's defaults have changed over time time to better fit with more of the 'preferred' options even if it's still based on the -preset method.

then again if you don't like it, you don't have to use it and just use whatever actually fits with what you want to use / get the results you deem important (plus i'm pretty sure the mp3 encoder is only available if you're a pro user...).

not sure where to post this. I just encoded a 32000Hz wav file with foobar and LAME 3.99.3 64bit (from rarewares) with the setting "-V 5". For the result mp3 file Foobar says: Codec Profile: MP3 VBR V3 (132kbps)

I ran upon this phenomenon while working on 3.99.3x.-V level is remapped when using 32 kHz sampling frequency. It's a feature.It would be better of cause if the user demanded -V level would be used to compute the quality item within the Lame tags which tools like foobar use for recalculating the -V level (the -V level isn't stored directly in the mp3 file).

If this is something that bothers you, you can use 3.99.3x where I fixed this. When using 3.99.3x with the usual -V n 3.99.3x works exactly like 3.99.3 does.

Only goes up to ~15% per process (max would be 25%). Total encoding speed was around 120-130x, which is much slower than normal. I was doing the same thing yesterday and all 4 cores were maxed. I don't have anything running in the background. Could it be a HD speed issue? The input and output paths were on the same drive, but it's a WD Black so it's not terribly slow, and I didn't hear any drive noise.Update: have since tried writing to a RAM disk as well as a different drive than the source; it goes a bit faster, but I still can't reliably max out each core. I feel as if there is wasted potential here. The CPU will often be maxed at the start of the batch, but drop off soon after.

What's the deal with the lowpass filter? Is it on both v3.98 and 3.99? Has anyone viewed the frequency spectrum of two files at the same quality setting?

Are you suggesting that there is a difference that you can actually hear and it has gotten worse with the new version?

If not then I fail to see why this matters!

By George of course I'm not

All versions of lame are transparent to me so I'm not concerned about any difference in sound. I'm just curious about it because I'm in engineering and people like me are interested in stuff like that lol.

As a reader who finds valuable information on this great board I have to say that the only posts distracting from the flow of information are your regular attempts to shove in reminders about TOS #8, even if it was not the typical "320kbps rulez" kind of post.

If you own thousands of CDs you try to inform yourself thoroughly before switching your encoder and reencode. Technical background information and details about the developer's motivation to change things in the code helps with that decision.