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 297618 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

Reply #78
john, any chance for a 64 bit lamedropxpd build?

LAME 3.99 is out

Reply #79
@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.

LAME 3.99 is out

Reply #80
@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: [Select]
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: [Select]
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?


LAME 3.99 is out

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

LAME 3.99 is out

Reply #83
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: [Select]
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.

LAME 3.99 is out

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

LAME 3.99 is out

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


LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

Reply #90
LAME 3.99.1 released

lame-3.99.1.tar.gz

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

LAME 3.99 is out

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

LAME 3.99 is out

Reply #92
BTW, 3.99.1 was released.

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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

LAME 3.99 is out

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