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: Is there a limit to how fast Lame can encode? (Read 10267 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is there a limit to how fast Lame can encode?

I briefly touched upon this on another thread, but thought it deserved it's own thread.

Is there a limit beyond which LAME cannot encode any faster? I use LAME 3.96.1 in conjunction with EAC. Using --alt-preset fast standard, my 1.7 GHz Centrino encodes at the same speed as my new 3.2 GHz P4.

If you look at Tom's Hardware (http://www6.tomshardware.com/cpu/20041221/cpu_charts-21.html), you'll see that encoding speed is not limited. Unfortunately, they don't say what settings are used in the test.

So is there some odd reason that I can't possibly fathom that explains why a 1.7 GHz Centrino is the same speed as a 3.2 GHz P4 when the P4 should be 30% or so faster.

And yes, I know the Centino is more efficient and runs faster than 1.7 GHz suggests. But every other benchmark I've run shows the P4 at least 30% faster. Why isn't it faster using LAME 3.96.1 --alt-preset fast standard?

Is there a limit to how fast Lame can encode?

Reply #1
Is it possibly I/O bound (e.g. a slow hard drive)?  Try putting the input and output files on a ramdrive.
I am *expanding!*  It is so much *squishy* to *smell* you!  *Campers* are the best!  I have *anticipation* and then what?  Better parties in *the middle* for sure.
http://www.phong.org/

Is there a limit to how fast Lame can encode?

Reply #2
Alternatively, if you are using foobar2k you can set it to cache the data to be encoded to RAM.

Is there a limit to how fast Lame can encode?

Reply #3
@gusmahler
are you encoding on the fly? try to rip your cd first and encode then.

Is there a limit to how fast Lame can encode?

Reply #4
perhaps the compiles are different, and if they are maybe they shouldn't be

Is there a limit to how fast Lame can encode?

Reply #5
Quote
Is it possibly I/O bound (e.g. a slow hard drive)?  Try putting the input and output files on a ramdrive.
[a href="index.php?act=findpost&pid=278604"][{POST_SNAPBACK}][/a]


It's a brand new, nearly empty 200 GB, 7200 rpm, Seagate SATA hard drive. I don't think the hard drive is limiting it (especially since the 1.7 GHz Centrino is reading and writing from a much slower hard drive (most likely a 4200 rpm)).

Is there a limit to how fast Lame can encode?

Reply #6
Quote
perhaps the compiles are different, and if they are maybe they shouldn't be
[a href="index.php?act=findpost&pid=278619"][{POST_SNAPBACK}][/a]


Considering I copied LAME from the laptop to the new computer, I don't think the compiles are different. 

Is there a limit to how fast Lame can encode?

Reply #7
Hmm, I've heard stories of P4s with iffy cooling (too little/too much heatsink goop for example) that overheat and throttle down during intensive tasks.  Could that be a possibiliity?

Did you perhaps use the secret --run-as-slow-as-my-other-computer switch?
I am *expanding!*  It is so much *squishy* to *smell* you!  *Campers* are the best!  I have *anticipation* and then what?  Better parties in *the middle* for sure.
http://www.phong.org/

 

Is there a limit to how fast Lame can encode?

Reply #8
Maybe try taking EAC out of the loop and encode a wav file from the command line on both machines.

Is there a limit to how fast Lame can encode?

Reply #9
Quote
Maybe try taking EAC out of the loop and encode a wav file from the command line on both machines.
[a href="index.php?act=findpost&pid=278774"][{POST_SNAPBACK}][/a]


Did that. Same result. Identical encoding speeds.

And to answer the other poster. I don't believe it is cooling related. First, the P4 is running under 50 C. Second, other benchmarks (SANDRA) show the P4 to be at least 30% faster than the Centrino.

Is there a limit to how fast Lame can encode?

Reply #10
Could you try some other similar benchmark?  Not only is sandra worthless as a benchmark, but its not a media encoder.  Try FAAC or something like that.  I'm guessing it'll behave like LAME.

Is there a limit to how fast Lame can encode?

Reply #11
Quote
Could you try some other similar benchmark?  Not only is sandra worthless as a benchmark, but its not a media encoder.  Try FAAC or something like that.  I'm guessing it'll behave like LAME.
[a href="index.php?act=findpost&pid=279067"][{POST_SNAPBACK}][/a]


My only point in using SANDRA was to show that my P4 isn't throttling down, as someone else theorized.

If you think FAAC will behave like LAME, why? Is there an ultimate limit beyond which LAME can't go any faster? It makes no sense to me. As I posted earlier, Tom's Hardware uses LAME as one of its benchmarks and it goes faster and faster with each step up in frequency. I just have no idea why it's not doing that on my computer.

Is there a limit to how fast Lame can encode?

Reply #12
This would be a prime example of "clock speed isn't everything." Clock for clock, the PentiumM (basically a revitalized PentiumIII-S or tualatin core chip) performs faster than the Pentium4 in a variety of benchmarks, substantialy so in some; LAME being one of them.

Here for example:
http://www6.tomshardware.com/mobile/200302...entrino-14.html

Yes, this is against a P4-M, but the reasoning still stands.

The new Dothan core PentiumMs tend to perform even better than the older Banias ones

Is there a limit to how fast Lame can encode?

Reply #13
Quote
This would be a prime example of "clock speed isn't everything." Clock for clock, the PentiumM (basically a revitalized PentiumIII-S or tualatin core chip) performs faster than the Pentium4 in a variety of benchmarks, substantialy so in some; LAME being one of them.

Here for example:
http://www6.tomshardware.com/mobile/200302...entrino-14.html

Yes, this is against a P4-M, but the reasoning still stands.

The new Dothan core PentiumMs tend to perform even better than the older Banias ones
[a href="index.php?act=findpost&pid=279085"][{POST_SNAPBACK}][/a]


that doesn't quite explain everything. A 1.7 GHz Centrino is about as fast as a 2.66 GHz P4. But I have a 3.2 GHz P4 and they run the same speed.

Can anyone with a 3+Ghz P4 tell me what speed they are encoding at? I'm encoding at about 15.5x using alt-preset fast standard.

Is there a limit to how fast Lame can encode?

Reply #14
From looking again at the Tom's Hardware CPU Chart (http://www6.tomshardware.com/cpu/20041221/cpu_charts-18.html), it looks like the particular P4 I got is remarkably slow with LAME. For example, in the video encoding test, the P4 540 Prescott I have is the same speed as an Ahtlon 64+ 3700. In LAME, the same Athlon 64+ is 11% faster than the P4 540 Prescott. In fact, in LAME, the 3.2 GHz Prescott is about the same speed as the 2.8 GHz Northwood.

Unfortunately, the charts don't show how fast the P4-M is. But, in other tests, a 1.7GHz Centrino is about the same speed as a 2.66 or 2.8 GHz P4.

I'll run some video encoding tests tonight.

Another interesting thing about the Tom's Hardware charts--I'm faster than that. It says 1:40 to encode a 173 MB file. I'm getting 90 seconds to encode a 233 MB file (Dream Theater's A Change of Seasons). The Centrino does it in 89 seconds. This is probably because they don't use switches. --alt-presest fast standard is faster than default encoding. I get about 12x with default encoding compared to 15.5x for --apfs.

Is there a limit to how fast Lame can encode?

Reply #15
P4-3.06 GHz (Northwood core)/Win2000+SP4 Pink Floyd "Dark Side of the Moon" encoded as one big  WAV with v3.96.1 --preset fast standard: 16.404X.

HTH

Have you tried encoding from command line?

Is there a limit to how fast Lame can encode?

Reply #16
Quote
P4-3.06 GHz (Northwood core)/Win2000+SP4 Pink Floyd "Dark Side of the Moon" encoded as one big  WAV with v3.96.1 --preset fast standard: 16.404X.

HTH

Have you tried encoding from command line?
[a href="index.php?act=findpost&pid=279265"][{POST_SNAPBACK}][/a]


I have encoded from the command line.

But thanks for the response, I think I've found the answer (thanks to you). The Prescott core is just slow (relatively speaking) with LAME. It's about as fast as a 2.8 GHz Northwood, which is why your 3 GHz Northwood is faster.

FWIW, in video encoding, the 3.2 GHz Prescott is about 17% faster than the 2.8 GHz Northwood (according to Tom's Hardware).

I guess I shouldn't complain because my old home computer (1 GHz Athlon) encoded at 5X.

Is there a limit to how fast Lame can encode?

Reply #17
FYI, "Dark Side of the Moon" preset fast standard encoded on my AthlonXP 1700 at 1.5 GHz (SuSE Linux 9.0)
Code: [Select]
LAME version 3.96.1 (http://lame.sourceforge.net/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding cdda.wav to x.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
98660/98662 (100%)|    3:52/    3:52|    3:56/    3:56|   11.082x|    0:00
32 [   57] *
128 [ 4565] %*******
160 [30452] %%%%%%%%%%%**************************************
192 [41140] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%*************************************
224 [12293] %%%%%%%%%%%*********
256 [ 6490] %%%%%%*****
320 [ 3666] %%%%**
average: 192.0 kbps   LR: 36321 (36.81%)   MS: 62342 (63.19%)

Writing LAME Tag...done
ReplayGain: -3.7dB

LAME version 3.97 MMX (alpha 7, Mar  5 2005 00:33:21) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding cdda.wav to y.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
98663/98663 (100%)|    3:50/    3:50|    3:55/    3:55|   11.192x|    0:00
32 [   61] %
128 [ 5719] %*********
160 [28498] %%%%%%****************************************
192 [41799] %%%%%%%%%%%%%%%%%%%%%%%%%******************************************
224 [12821] %%%%%%%%%%%**********
256 [ 6169] %%%%%*****
320 [ 3596] %%%%**
-------------------------------------------------------------------------------
  kbps        LR    MS  %     long switch short %
 191.8       30.9  69.1        93.4   3.7   2.9
Writing LAME Tag...done
ReplayGain: -3.7dB

Is there a limit to how fast Lame can encode?

Reply #18
Quote
Alternatively, if you are using foobar2k you can set it to cache the data to be encoded to RAM.
[a href="index.php?act=findpost&pid=278609"][{POST_SNAPBACK}][/a]


I've looked around but can't seem to find where I set foobar to "cache the data to be encoded to RAM"

Can anyone help me?
Someone asked me the difference between ignorance and apathy. I told
her "I don't know and I don't care."

Is there a limit to how fast Lame can encode?

Reply #19
Heres some more data points. AthlonXP 2600+ @ 2230MHz

Code: [Select]
D:\lame3_97a7\new>lame -V3 --vbr-new test.wav test.mp3
LAME version 3.97 MMX (alpha 7, Feb 26 2005 17:23:10) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used)
Using polyphase lowpass filter, transition band: 17960 Hz - 18494 Hz
Encoding test.wav to test.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=3
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
10081/10081 (100%)|    0:13/    0:13|    0:13/    0:13|   19.485x|    0:00
32 [    1] *
40 [    0]
48 [    0]
56 [    0]
64 [    0]
80 [    2] *
96 [  177] ***
112 [ 1309] *********************
128 [ 2775] *********************************************
160 [ 4220] %******************************************************************
192 [ 1010] %%***************
224 [  351] %*****
256 [  199] %***
320 [   37] %
-------------------------------------------------------------------------------
  kbps        LR    MS  %     long switch short %
 151.7        2.0  98.0        90.1   5.2   4.7
Writing LAME Tag...done
ReplayGain: -6.7dB


That's currently my preferred encoder and preferred settings. For 3.96.1 it's only very slightly slower.

I cant wait for Lame4 to go beta, it's speed is really amazing.

Code: [Select]
D:\lame4\alph12>lame -V3 test.wav test.mp3
LAME version 4.0 MMX, [E]3DNow!, SSE(alpha 12, Jan 15 2005 12:46:34) (http://www
.mp3dev.org/)

warning: alpha versions should be used for testing only

CPU features:MMX (ASM used), MMX2 (ASM used), 3DNow! (ASM used), E3DNow! (ASM us
ed), SSE (ASM used)
Using MDCT filter
 Lowpass  filter, transition band: 17923 Hz - 18009 Hz
Encoding test.wav to test.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
10079/10081 (100%)|    0:08/    0:08|    0:08/    0:08|   31.206x|    0:00
32 [    0]
40 [    0]
48 [    0]
56 [    0]
64 [    0]
80 [    2] *
96 [  133] **
112 [  940] **************
128 [ 2321] *********************************
160 [ 4676] %*****************************************************************
192 [ 1406] %%%%%***************
224 [  403] %%****
256 [  155] %**
320 [   45] %
average: 156.5 kbps
  LR: 500 (4.960%)   MS: 9581 (95.04%)
LR+i: 0 (0.0000%) MS+i: 0 (0.0000%)

Writing LAME Tag...done

Is there a limit to how fast Lame can encode?

Reply #20
look at your LAME4 setting, you are using -q5. 3.97 speeds up a little too if you use -q5.

Is there a limit to how fast Lame can encode?

Reply #21
Quote
look at your LAME4 setting, you are using -q5. 3.97 speeds up a little too if you use -q5.
[a href="index.php?act=findpost&pid=279475"][{POST_SNAPBACK}][/a]

Yeah I noticed that too, but that's what the preset (-V3) used so I just left it. 

Also I wasn't even sure if the Q settings in Lame4 are equivalent or different to the current ones in Lame3.x