LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released Options

[no404error]

Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.

And once again

x86
LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2

x64
LAME 3.99 64bits (http://lame.sf.net)
CPU features: , SSE (ASM used), SSE2

[robert]

That's actually not a bug for the x64 compile, only a glitch in the display routine, nothing to worry about.

[markanini]

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?

[no404error]

That's actually not a bug for the x64 compile, only a glitch in the display routine, nothing to worry about.

Bug, glitch, feature... Never mind, but it's looks like too lame xD

[halb27]

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.

This post has been edited by db1989: Oct 18 2011, 19:37

Reason for edit: fixing quote/attributions

[inrobert]

Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.

Thanks! Works well now.

This post has been edited by inrobert: Oct 18 2011, 19:28

[Agent69]

http://lame.cvs.sourceforge.net/viewvc/lam...ml/history.html

October 15 2011: 3.99 beta 1 becomes 3.99

And compiles are at Rarewares!!

I just wanted to say thanks for providing these compiles John.

[punkrockdude]

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]

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!!

[Steve Forte Rio]

Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?

[lvqcl]

Apparently Reaper is a program that uses lame_enc.dll

The code from BladeMP3EncDLL:

CODE

typedef    unsigned long    HBE_STREAM;
typedef    HBE_STREAM    *PHBE_STREAM;
...
PHBE_STREAM phbeStream;
...
lame_global_flags* gfp = NULL;

// Init the global flags structure
gfp = lame_init();
*phbeStream = (HBE_STREAM)gfp;
...
lame_global_flags* gfp = (lame_global_flags*)hbeStream;

This code works only when sizeof (unsigned long) == sizeof(pointer).
(Or when the upper half of a pointer is 0. Maybe setting largeaddressaware=0 to Reaper executable should help)

This is in the change log of Reaper 3.35:
x64: now requires libmp3lame.dll or lame_enc64.dll (old x64 lame_enc.dll was broken)

IMHO 64-bit libmp3lame.dll is better than lame_encXX.

This post has been edited by lvqcl: Oct 18 2011, 22:09

[punkrockdude]

lvqcl, thank you very much for the detailed reponse. DO you know where I can find the other dll using latest 3.99. I have only found lame_enc64.dll. Regards.

[ShotCaller]

Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?

I'd be interested in hearing what the developers have to say about this as well. Are these high frequencies truly inaudible? Can their presence have an effect on the audible range?

[lameboy]

For Mac-users there's a plugin available for XLD (scroll down to the download-section):

http://tmkk.pv.land.to/xld/index_e.html

Extract it to ~/Library/Application Support/XLD/PlugIns

[kwanbis]

Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?

I'll be interested on knowing too.

[IgorC]

++
My guess is that it's something to do with pre echo handling.

This post has been edited by IgorC: Oct 22 2011, 09:01

[krafty]

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...

Any developer to explain this?

This post has been edited by krafty: Oct 23 2011, 20:59

[Gregory S. Chudo...]

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)?

This post has been edited by Gregory S. Chudov: Oct 24 2011, 21:08

[lvqcl]

Why do you want to use lame_enc.dll, but not libmp3lame.dll?

( both x32 and x64 DLLs for LAME 3.98.4 are available at http://lame.bakerweb.biz/ )

[Gregory S. Chudo...]

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...

This post has been edited by Gregory S. Chudov: Oct 24 2011, 21:18

[[JAZ]]

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 )

[Frankie]

3.99 works fine but on my machine (Intel Dual Core E5300) runs ~12% slower then the latest 3.98 (both are from rarewares).

[Destroid]

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.

Thanks LAME team and HA!

[Alex B]

A quad-core AMD Phenom II, XP Pro 32-bit, foobar2000, four simultaneous encoding processes, -S -V2 --noreplaygain - %d, source: 25 various wave tracks.

3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

The 'icc-patcher' compile (x86):
Total encoding time: 0:51.359, 107.04x realtime

3.99 (the main bundle from Rarewares)
Total encoding time: 0:48.500, 113.35x realtime

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.)

[lvqcl]

Results of "lame -S -V2 --noreplaygain test.wav nul" on Intel Core2: encoding time in seconds

Rarewares compiles:
x32: 148 s
x64: 116 s

My compiles (MSVS 2010, fast math + SSE enabled):
x32 NASM: 125 s
x32 SSE2: 135 s
x64 SSE2: 119 s

Also, Rarewares Lame 3.98.4:
x32: 130 s
x64: 144 s