Thanks for the info.I don't like having no or an extremely high low-pass. It's probably a concession towards those people who come up here occasionally demanding for the settings which allow for the 'full range'.

But it's not a problem as we can use --lowpass. Maybe it's not bad to find out for ourselves where to put the lowpass.

Would this be recommended? My experiments with tones and filtered noise suggest I don't hear anything past 16kHz at sane levels. Which then bears the question: Should I use -Y switch or the lowpass switch?

Thanks for the info.I don't like having no or an extremely high low-pass. It's probably a concession towards those people who come up here occasionally demanding for the settings which allow for the 'full range'.

But it's not a problem as we can use --lowpass. Maybe it's not bad to find out for ourselves where to put the lowpass.

Would this be recommended? My experiments with tones and filtered noise suggest I don't hear anything past 16kHz at sane levels. Which then bears the question: Should I use -Y switch or the lowpass switch?

That's a question of taste. Both methods help. If you consider to use a high lowpass frequency > 17.5 kHz, -Y is expected to be more efficient. That's why it's automatically used internally with -V3 and below.If you can allow for a lower limit frequency as it looks you can, I'd use a lowpass. I am very happy with using --lowpass 16.7.

John33: do you know why the x64 version does not work in Reaper x64 when your x86 compile works in Reaper x86? maybe difficult for you to answer if it is a Reaper issue. I have made a thread over at Reaper's forum as well. http://forum.cockos.com/showthread.php?p=831811 . Regards.

John33: do you know why the x64 version does not work in Reaper x64 when your x86 compile works in Reaper x86? maybe difficult for you to answer if it is a Reaper issue. I have made a thread over at Reaper's forum as well. http://forum.cockos.com/showthread.php?p=831811 . Regards.

I'm afraid I have no idea as I don't even know what Reaper is!!

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

I too noticed that there is no lowpass using -V0. Can this be to "compete" with iTunes which doesn't apply a lowpass with 256 kbps VBR setting anymore?There may be people "feeling" more comfortable using AAC or OGG, than MP3 just because of this...

I'm using lame_enc.dll in CUETools, and have some problems with it's BladeEnc interface, for example it cannot write LAME header to files with Unicode paths, because beWriteInfoTag uses ASCII string.

lame_enc.dll also exposes alternative lame_* interface, and i was considering using it, but the .def file wasn't updated for a long time, so many of the functions are not available. It seems that Audacity has the same problem, so they use their own version of lame_enc.dll (http://lame1.buanzo.com.ar/) which exposes more functions, but there's only a 32-bit version there, and they also don't expose some important functions, such as lame_get_lametag_frame() and lame_set_VBR_quality().

John, would it be possible to make lame_enc.dll expose the full LAME API (like libmp3lame.dll)?

That would be the alternative, yes. But it still would be nice if people could use the builds from rarewares too. I wouldn't ask if blade_enc.dll was exposing _only_ BladeEnc API, but it does also expose some subset of LAME API, why not all of it? Such a .dll could probably work for all applications - EAC, Audacity, CUETools...

That would be the alternative, yes. But it still would be nice if people could use the builds from rarewares too. I wouldn't ask if blade_enc.dll was exposing _only_ BladeEnc API, but it does also expose some subset of LAME API, why not all of it? Such a .dll could probably work for all applications - EAC, Audacity, CUETools...

I'd say the answer is around the lines of why to use .mkv or .mp4 instead of .avi.

Remember that the API of blade_enc was defined more than 10 years ago. There was not even the concept of 64bits. (Aside of some Alpha stations and other types of supercomputers )

I was about to post LAME 3.99 b1.2 test I ran compared to 3.98.4 that the newer LAME (at -V2) has better efficiency with tracks containing more mono data and that overall bit rate is the same if not more "flexible" for critical sounds. This was in light of my latest album release and wanted to analyze how lossy dealt with the tracks. I don't expect LAME 3.99 final to be too radically different.

The 3.99 release compile is yet again slightly faster than the last beta compile was, but 3.98.4 is still almost 20% faster on my machine. (I did my best to reproduce the earlier test conditions, run the test several times and picked the middle result.)