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: LAME 3.99 is out (Read 297568 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.99 is out

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

LAME 3.99 is out

Reply #27
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?

LAME 3.99 is out

Reply #28
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

LAME 3.99 is out

Reply #29
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.
lame3995o -Q1.7 --lowpass 17



LAME 3.99 is out

Reply #32
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.

LAME 3.99 is out

Reply #33
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!!

LAME 3.99 is out

Reply #34
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)?
🇺🇦 Glory to Ukraine!

LAME 3.99 is out

Reply #35
Apparently Reaper is a program that uses lame_enc.dll

The code from BladeMP3EncDLL:

Code: [Select]
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.

LAME 3.99 is out

Reply #36
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.

LAME 3.99 is out

Reply #37
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?

LAME 3.99 is out

Reply #38
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

XLD // ALAC // OGG VORBIS

LAME 3.99 is out

Reply #39
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.

LAME 3.99 is out

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

LAME 3.99 is out

Reply #41
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?

LAME 3.99 is out

Reply #42
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)?
CUETools 2.1.6

LAME 3.99 is out

Reply #43
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/  )

LAME 3.99 is out

Reply #44
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...
CUETools 2.1.6

LAME 3.99 is out

Reply #45
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 )

LAME 3.99 is out

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

LAME 3.99 is out

Reply #47
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!
"Something bothering you, Mister Spock?"

LAME 3.99 is out

Reply #48
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.)

LAME 3.99 is out

Reply #49
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