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 benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new) (Read 8537 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

I'm wondering roughly how fast LAME 3.97 runs using -V presets and --vbr-new on Intel Core 2 Duo CPUs?

I currently have an Athlon X2 4600 CPU (2 X 2.4 GHz, 512 cache). It encodes using LAME 3.97 (-V5 --vbr-new) at around 20 X real time (per core). I'm wondering roughly which Intel Core 2 Duo CPU would be significantly faster (say at least 15 - 20%) which would mean at least 25 x real time using 3.97 -V5 --vbr-new?

Unfortunatley all the top PC hardware review sites don't use the -V presets! They often just encode to CBR, which is annoying, because surely VBR is a better test of CPU power than CBR?

Here are results I got encoding Under the Bridge by the Red Hot Chili Peppers. First with 3.97 then with 3.98 beta 1. Can anyone with a Core 2 Duo CPU tell me how fast the command line encoder is on their PC? I got my encoder compiles from Rarewares.org

Quote
C:\TOOLS\AUDIO\LAME>lame -V5 --vbr-new underthebridge.wav
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: 15826 Hz - 16360 Hz
Encoding underthebridge.wav to underthebridge.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
10118/10118 (100%)|    0:13/    0:13|    0:13/    0:13|  19.647x|    0:00

Curiously, for 3.98 beta 1 I only get ~16 X. Perhaps it was compiled differently?
Quote
C:\TOOLS\AUDIO\LAME398b1>lame -V5 underthebridge.wav
LAME 3.98 (beta 1, May 16 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding underthebridge.wav to underthebridge.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=0
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
10118/10118 (100%)|    0:16/    0:16|    0:16/    0:16|  15.989x|    0:00

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #1
Hi

I've got a Core 2 Duo @ 2GHz on my laptop with a 5400 rpm hard drive and 1 gig ram. When i use foobar, i usually get around 36X (for 2 songs so roughly 18X per thread). Note that this is:

a.  on a laptop
b. on a 5400 rpm hard drive
c. on a 1 gig @DDR-533

bumping it up to 7200 rpm and DDR@667 should yield better results.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #2
Hi

I've got a Core 2 Duo @ 2GHz on my laptop with a 5400 rpm hard drive and 1 gig ram. When i use foobar, i usually get around 36X (for 2 songs so roughly 18X per thread). Note that this is:

a.  on a laptop
b. on a 5400 rpm hard drive
c. on a 1 gig @DDR-533

bumping it up to 7200 rpm and DDR@667 should yield better results.


Thanks for this info. Are their major differences between laptop and desktop core 2 duos? I realise it is a different core, but are there certain sacrifices made in favour of power efficiency that means you can't directly compare same MHz C2Ds across both platforms?

Anyone with a desktop Core 2 Duo?

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #3
I ran the test

C2D E6600 @ 420 x 8 = 3.36 GHz

I used the same song, ripped with EAC from original CD.

With Lame 3.97 :

Quote
C:\TOOLS\AUDIO\LAME>lame -V5 --vbr-new under_the_bridge.wav
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: 15826 Hz - 16360 Hz
Encoding under_the_bridge.wav to under_the_bridge.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
10119/10119 (100%)| 0:07/ 0:07| 0:07/ 0:07| 35.842x| 0:00


And then with 3.98 b1 :

Quote
C:\TOOLS\AUDIO\LAME398b1>lame -V5 under_the_bridge.wav
LAME 3.98 (beta 1, May 16 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding under_the_bridge.wav to under_the_bridge.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
10119/10119 (100%)| 0:07/ 0:07| 0:07/ 0:07| 35.025x| 0:00


Almost same speed, 3.98 just a little bit slower.

Both compiles are made with ICL 9.1, it's strange that 3.98 is so slower on your comp.

Edit : Only the cache size changes between portable and desktop versions of C2D.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #4
My laptop has the same specs as kanak, and I get about the same results, as expected. I don't think a faster HD would improve results much, if at all. Note it is single channel ram (1 x 1Gb).

My desktop Pentim D840 3.20GHz, on Win64, is surprisingly also slower than my laptop (get about 32x with foobar). It has 4 x 1Gb 2.66 ram, and I suppose Dual channel is therefore enabled.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #5
b. on a 5400 rpm hard drive
c. on a 1 gig @DDR-533

bumping it up to 7200 rpm and DDR@667 should yield better results.

MP3 encoding is CPU bound even on very fast systems, so neither RAM nor disk speed will have much of an affect on things.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #6
On my E6600 not overclocked (9*266 MHz) and WinXP SP2:

Code: [Select]
F:\Progs\lame3.97>lame -V5 --vbr-new pvd.wav
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding pvd.wav to pvd.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
23935/23935 (100%)|    0:23/    0:23|    0:23/    0:23|   26.378x|    0:00


Overclocking by increasing the FSB speed increases the encoding speed proportionally.

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #7
On my E6600 not overclocked (9*266 MHz) and WinXP SP2:

Code: [Select]
F:\Progs\lame3.97>lame -V5 --vbr-new pvd.wav
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding pvd.wav to pvd.wav.mp3
Encoding as 44.1 kHz VBR(q=5) j-stereo MPEG-1 Layer III (ca. 11.9x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
23935/23935 (100%)|    0:23/    0:23|    0:23/    0:23|   26.378x|    0:00


Overclocking by increasing the FSB speed increases the encoding speed proportionally.

Thanks for that. I used Le Canz data to estimate that the E6600 at stock speed would be about 25X, but it looks like it is slightly better than my prediction. Thanks!

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #8
I ran the test
C2D E6600 @ 420 x 8 = 3.36 GHz

Doesn't the E6600 have a maximum multiplier of 9, instead of 8?
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #9
Doesn't the E6600 have a maximum multiplier of 9, instead of 8?


You're right, I use 8 for OC.

With my motherboard (Asus P5B Deluxe), FSB freq from +/- 370 to 399 MHz makes the system unstable (because of chipset's memory strap), and the CPU cannot handle 400 x 9.

So 420 x 8 is a good compromise

 

LAME benchmarks on Core 2 Duo CPUs? (3.97 -V5 --vbr-new)

Reply #10
it's about 8% slower here on linux, too.

perhaps the new fft/3dnow/assembler stuff is the culprit.


later