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

[lvqcl]

Has anybody tried to compile with the Open64 compiler?

Since it is Linux only, I doubt it.

[no404error]

So as to be sure that my compiles work on both Intel and AMD CPUs, I've changed my development system to a Phenom II X4 840 with 8GB of Corsair DDR3.

Checking the latest compiles, I also produced VC10 compiles for comparison. The Intel compiles, after running through icc_patch are between 5% and 10% faster on the above system than the VC10 versions.

Intel Pentium G630, DDRIII 533Mhz, Windows 7 Home Basic x64

lame -V0 test.wav nul

lame3.99-20111101-2
33.144x

lame3.99-64-20111101-2
41.422x

lame3.99-libsndfile-20111101-2
33.121x

lame3.99-libsndfile-64-20111101-2
41.348x

This post has been edited by no404error: Nov 2 2011, 17:54

[Alex B]

Using the same test setup as before,

LAME 3.99 32-bit (the latest main bundle, Intel Compiler 11.1, 2011-11-01_2):
Total encoding time: 0:46.703, 117.71x realtime

LAME 3.98.4 (to make sure that my system has not changed significantly, I retested the 32-bit Intel compile from the old "3.98.4 main bundle")
Total encoding time: 0:40.875, 134.50x realtime
(my previous 3.98.4 result was: Total encoding time: 0:40.922, 134.34x realtime)

[viktor]

john, any chance for a 64 bit lamedropxpd build?

[robert]

@Alex
Just trying to figure out, what is so special on your report. Can you please run a single instance of LAME from the command line and see how encoding times compare there?

edit:
OK, I can confirm Alex's observation: John's older vc6-intel compiled version is 20% faster on my Athlon64X2, than the newer ic11.1 one. Though, my own VC9-NASM compiles are equally fast, but 11% slower than John's IC11.1 one.

This post has been edited by robert: Nov 2 2011, 22:22

[Alex B]

@Alex
Just trying to figure out, what is so special on your report. Can you please run a single instance of LAME from the command line and see how encoding times compare there?

I created a consolidated wave file from the same 25 wave tracks that I used in the previous tests and tested the encoders in a cmd window.

Apparently my quad-core Phenom II doesn't produce very repeatable results when it is not fully stressed. When a single encoder runs in a cmd window the results vary greatly. I have the Asus E-PU 4-Engine "power saving engine" running. It was set to "High Performance" during the tests, but either it or the power features that are enabled in BIOS make the results rather unreliable.

For example, I could now have posted these results and made 3.99 look even slower than it is:
3.99: 21.624x
3.84: 32.890x

-- but after running several test runs I think the following results are quite correct (they are about average from all runs):

LAME 3.99

CODE

C:\Soft\LAME\399>lame -V2 --noreplaygain "S:\Test\Testfile.wav" "F:\Test\HA\399s
peed\lame399.mp3"
LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame399.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:33/    3:33|    3:33/    3:33|   25.715x|    0:00
32 [   862] %
40 [     9] %
48 [    20] %
56 [    29] %
64 [    78] %
80 [    84] %
96 [    71] %
112 [   219] %
128 [  3292] %**
160 [ 53858] %%%%%%%%%%****************************
192 [ 94613] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*********************************
224 [ 29853] %%%%%%%%%%%**********
256 [ 18511] %%%%%%%******
320 [  8964] %%%%%**
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  197.5       43.8  56.2        87.6   6.4   6.0
Writing LAME Tag...done

LAME 3.98.4

CODE

C:\Soft\LAME\3984>lame -V2 --noreplaygain "S:\Test\Testfile.wav" "F:\Test\HA\399
speed\lame3984.mp3"
LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame3984.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:16/    3:16|    3:16/    3:16|   27.952x|    0:00
32 [   884] %
40 [     4] %
48 [     5] %
56 [    12] %
64 [    24] %
80 [    33] %
96 [   160] %
112 [   951] %
128 [  5223] %****
160 [ 53089] %%%%%%%%************************************
192 [ 80140] %%%%%%%%%%%%%%%%%%%%%%%*******************************************
224 [ 36470] %%%%%%%%%%*********************
256 [ 18169] %%%%%%*********
320 [ 15299] %%%%%%%******
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  201.6       29.5  70.5        87.6   6.4   6.0
Writing LAME Tag...done

A bit surprisingly 3.99 creates quite a bit more LR frames than 3.98.4. Is this an intended change?

This post has been edited by Alex B: Nov 2 2011, 23:06

[john33]

john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.

[robert]

A bit surprisingly 3.99 creates quite a bit more LR frames than 3.98.4. Is this an intended change?

That's a consequence of PSY model corrections in 3.99, so yes, it's intended.

[Alex B]

For comparison here is LAME 3.97. I have no idea about the compiler, but probably my archived encoder is from the past Rarewares "main bundle".

LAME 3.97

CODE

C:\Soft\LAME\397>lame -V2 --vbr-new --noreplaygain "S:\Test\Testfile.wav" "F:\Te
st\HA\399speed\lame397.mp3
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame397.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:55/    3:55|    3:56/    3:56|   23.339x|    0:00
32 [   972] %
40 [    54] %
48 [    41] %
56 [    31] %
64 [    21] %
80 [   103] %
96 [   493] %
112 [  3200] %**
128 [  9556] %********
160 [ 54917] %%%%%%%********************************************
192 [ 71955] %%%%%%%%%%%%%%%%%%%%**********************************************
224 [ 40066] %%%%%%%%%%%%*************************
256 [ 21026] %%%%%%%*************
320 [  8028] %%%%****
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  195.8       24.8  75.2        91.5   4.8   3.8
Writing LAME Tag...done

The tendency seems to be to use more LR frames in each new version.

Regarding my speed results from running a single lame instance in a cmd window, perhaps you should ignore them. I ran a few additional tests and the results really vary too much from one run to another. When foobar2000 runs four simultaneous encoder instances, the results seem to be quite reproducible.

This post has been edited by Alex B: Nov 3 2011, 01:10

[robert]

So as to be sure that my compiles work on both Intel and AMD CPUs, I've changed my development system to a Phenom II X4 840 with 8GB of Corsair DDR3.

Checking the latest compiles, I also produced VC10 compiles for comparison. The Intel compiles, after running through icc_patch are between 5% and 10% faster on the above system than the VC10 versions.

Running some test with my above ~45 min track:

Rarewares compiles:
3.98.4 : 1:46
3.99.0 : 2:08

My own VC9 compiles :
3.98.4 : 2:24 (Release NASM)
3.99.0 : 2:24 (Release NASM)
3.99.0 : 2:01 (Release SSE2)

My own VC11 compile:
3.99.0 : 2:10 (Release)
3.99.0 : 1:46 (Release SSE2)
3.99.0 : 1:38 (Release SSE2, 64-bit)

It looks like John's IC11.1 compile isn't using optimized code paths, or at least no SSE2 optimizations.

This post has been edited by robert: Nov 3 2011, 01:54

[Fishman0919]

I did a quick test of VC 11 w/nasm 2.10rc8 and MinGW on a AMD Phenom 9950 X4

VC11... nmake -f Makefile.MSVC PREC=DOUBLE



MinGW... ./configure




noticeable difference in size and speed between the two

This post has been edited by Fishman0919: Nov 4 2011, 04:12

[viktor]

john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.

thanks, eagerly waiting!

[john33]

john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.

thanks, eagerly waiting!

Don't hold your breath!! I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.

[viktor]

Don't hold your breath!! I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.

kk, thanks already!

[krafty]

Still not a word on the lowpass case for -V0 ???

[ZinCh]

LAME 3.99.1 released

lame-3.99.1.tar.gz

Fixes for several issues with ID3v2 unicode tags, using Big-Endian text encodings. Because of several other software (like Windows Media Player), LAME writes Little-Endian unicode tags only.

[john33]

Don't hold your breath!! I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.

kk, thanks already!

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro...1-3.99.1-64.zip

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.

This post has been edited by john33: Nov 6 2011, 23:34

[lvqcl]

BTW, 3.99.1 was released.

[viktor]

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.

many thanks!

btw. John, while you're at it, would you be so kind as to provide us with FLAC x64 ICC builds? i'd love to compare them with my MSVC builds.

This post has been edited by viktor: Nov 6 2011, 13:30

[john33]

BTW, 3.99.1 was released.

Good to know!

Full set of compiles now at Rarewares including the 64 bit LamedropXPd. The 64 bit libsndfile compile now works with FLAC files.

[john33]

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.

many thanks!

btw. John, while you're at it, would you be so kind as to provide us with FLAC x64 ICC builds? i'd love to compare them with my MSVC builds.

All in good time - probably!

[Broadway]

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.

John, 64bit-version of lamedropxpd based on lame 3.99.1 does not create lame tags, 32bit-version does.

[john33]

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.

John, 64bit-version of lamedropxpd based on lame 3.99.1 does not create lame tags, 32bit-version does.

Thanks for the heads-up, I'll look into it.

[john33]

Having just checked, it appears to fine here. Anyone else have a problem?

Edit: When I say this it is because lametag.exe says so.

This post has been edited by john33: Nov 6 2011, 19:55

[robert]

Hm, yes.

Dumpzusammenfassung
-------------------
Dumpdatei: WERCE17.tmp.mdmp : C:\Users\robert\AppData\Local\Temp\WERCE17.tmp.mdmp
Letzte Schreibzeit: 06.11.2011 22:24:06
Prozessname: lamedropXPd.exe : T:\tmp\john\lamedropXPd.exe
Prozessarchitektur: x64
Ausnahmecode: 0xC0000374
Ausnahmeinformationen:
Heapinformationen: Nicht vorhanden

Systeminformationen
-------------------
Betriebssystemversion: 6.1.7601


Edit: sorry, I've used an outdated link. Latest version does work here.

This post has been edited by robert: Nov 6 2011, 23:23