I use Lame 3.90.3 and 3.97b. I noticed that the encoding speed (CPU/Real) on my system would start out at 7.0x and then trailed off to an average of 2.5x per track by the second track. I expect between 6 and 7x for my P4 3.2 Prescott which seems to be the norm. Lurking around here, it looks like users are getting between 5 to 7 x for a stock P4 at +3.0 GHz.
I am suspecting CPU heat is slowing down any and all processes. I know Prescotts run hot so I have 5 fans in my case and mine will still get up to 71° C (159°F) under load. I have a Vantec 550W PS and a stock heat sink I was told was adequate, and used Artic 5 Silver Compound. I'm puzzled that the CPU's temp could shoot up so dramatically under load.

Looking under the Windows Task Manger, Lame and System Idle were the two processes accounting for 100% of the resources, so overhead is not an issue. I have to do some re-encodes of my collection, if not all of them and I shudder at the thought of the process going at a third of the pace.
Would your suspicion be an overheating CPU slowing down Lame?

P.S. is there a link here in HA about uploading images? I serached in HA help and failed. I wanted to upload an image or text file of my system config to aid troubleshooting.

LAME 3.97b --preset fast standard is around 3.9X on my system (P4 1.4GHz willamate)

you didn't mention the settings you've used, different settings will result in a different encoding speed....never mind, I've tried a few settings, nothing that is as slow as 2.5X...man, your CPU is a 3GHz, should be 2X+ faster than mine

your CPU is really hot too, mine won't go up to more than 65°C

http://www.hydrogenaudio.org/forums/index.php?showforum=35
upload forum??

but 71C is quite normal for 3GHz prescott, it can go up to 100C without a problem, IIRC

I'd suggest you to use RMClock:
http://cpu.rightmark.org/products/rmclock.shtml

With this tool you will know if your processor is throttling while encoding.

hm, I get 10-12X on my AthlonXP 1700 with 3.97b using vbr-new.
The non fast presets are more in your area.

I tried this with my Hyperthreaded P4 2.6 GHz on XP. The MSI MB has an automatic overclocking feature and MSI's diagnostic tool reported 2.859 MHz during the encoding. Surprisingly the CPU temp was only 38° C with a standard Intel CPU fan (boxed). Though, the case has four extra 60x60 mm fans.

I encoded four completely different wave files with a plain command line LAME 3.97b encoder. I got these results:
-V2 => 11-12.5x
-V2 --vbr-new => 15-16x

The CPU usage was only 50% during the encoding. I guess that is because LAME doesn't take any advantage of the Hyperthreading function and uses only one of the virtual processors. In this light the other speed results here are quite low.

I have also previously found that --vbr-new makes a speed increase of about 1.3-1.4x.

WOW, is your CPU 1.5 GHz, I know Pentium 4 willamate(the oldest version of P4) might be slower than P3 1GHz?

really regreted .....I should have bought AMD's athlon, cheaper and faster

Might SSE2 optimised version help, I don't know any sse2 optimised lame dll.

I've got too a P4 1.5Ghz ( 100x15 ) and it is twice slower than my new notebook with a Celeron M 1.5Ghz Processor.

My Celeron M (based on the P3 core AFAIK) notebook at 1.4 Ghz manages about 12x-13x on -V2 --vbr-new, with lame 3.97b, running WinXP Home. Tried several different files just now.

WTF? The slower the PC the faster the encoding?

I have the same processor as you (P4 presscott 3.2Ghz s478) on Abit IC7. I'm currenlty reencoding my music from APE to mp3 using lame 3.97 beta 1 (i bought a laptop). I'm converting via foobar2000 - it reports speed around 9,76x. CPU temperature is around 53 - 54C. Ealier I had standard P4 cooler - temperature was about 70 - 75C (with 6 other fans in my big tower!!!).

Recently I bought this heatsink:

http://www.scythe.co.jp/cooler/20050427-115151.html

and big 120mm Chieftec cooler. Now in stress my CPU reaches around 55C and no more!!!

Huh? That is really slow, are you sure you're using the right compile?

I get around 5x on my AMD 800 MHz

cca 2.0x for a P4 truly IS weird!!!

Here is the result with my slow Celeron 433 MHz:

C:\temp>lame.exe -V2 --vbr-new 05.wav
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 05.wav to 05.wav.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
3427/3427 (100%)| 0:40/ 0:40| 0:40/ 0:40| 2.2304x| 0:00
32 [ 7] %
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 0]
112 [ 0]
128 [ 1] %
160 [ 138] ****
192 [2635] %%%*****************************************************************
224 [ 645] %%%**************
256 [ 0]
320 [ 1] %
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
196.4 6.0 94.0 99.9 0.1 0.0
Writing LAME Tag...done
ReplayGain: -2.6dB

You really should look into this!!!

Y'all may talk about the speed itself but the slowing down from 7x to 2.5x average for the encode is what I find really weird. Do some processers have built-in slow-down if they get too hot, as the thread-starter hypothesizes? Or is there some other cause? (Maybe the music all starts out really simple and gets more complex as the song goes on. Though I doubt it.)

Btw, I get speeds of around 1.7x with --vbr-new. But I need to get a new motherboard/processer etc. soon. My computer is really, really old (with AMD 5x100mhz processer), but with nice new HD and disc drives.

Yes, indeed they do. Some Pentium 4s automatically slow down if they heat up too quickly, or to a high temperature. As Gabriel said:
My money is on the fact that this behaviour is heat-related.

Important thing to remember here is, it's normal for a computer to get a bit warm! As long as your CPU temp doesn't regularly go over 70°C, you're fine. AFAIK the shutdown of CPU features only occurs at such high temperatures anyway.

I have a 3.0GHz Prescott. It used to be that I'd get almost 80°C under load... Now, still with the standard Intel heatsink, but with 4 case fans... as long as I keep everything free of dust, the highest CPU temp I ever see is around 68°C.

Go ahead and buy exotic $200 heatsinks or hydrocooling rigs if you want. You're just helping someone make a living.

(FYI, I get about 7× encoding speed, constantly. No slowdowns.)

Mine too, might be good to check in the Bios or motherboard jumpers for the CPU's voltage level. Higher voltages allow more overclocking but makes more heat/throttling/heatsink, lower voltages lower maximum attainable speed but make a cooler, smoother system.

what? a 1.4GHz celeron can encode up to 12X

well I tried again,

LAME 3.96.1 fast standard = 5X
LAME 3.97b1 fast standard = 3.8X
LAME 4.00a14 -V2 = 12X

weird...........even a celeron 433 can encode at 2.23X, what's wrong with P4.....

Something is clearly screwed up with your system. Even my ancient AMD Duron 750 was faster IIRC. It's time to run a few system analysis programmes
OT: I really don't know what Intel did to these P4 processors. You could as well build a PC around a volcano. My current Athlon64 never, ever gets hotter than 51 degrees celsius, and that's just with one case fan and the cheap standard CPU fan that came with the processor.

Can anyone help.....try FLAC 1.1.2 "-5" (thanks in advance)
I got around 20X with system, I would like to know how other CPUs perform, I just wanna know whether P4 is the evil, just slow in everything, or it is just LAME that is not so "P4 friendly"

On my piii celeron 800 MHz,
Lame 397 beta2, preset fast standard : 6x
Flac -5 : about 12x

iirc Prescot P4s can perform well when configured right (just check out some old reviews - lame is usually benchmarked), but the heat throttling and producing behaviour needs minded.

When I encode wav to flac, delete the flac and encode again, the second encode is about 1/3 faster, don't really know why. I haven't been able to time it very good, but the second encode is more like 40x (2:38 in about 4 seconds, 3:47 in about 6 seconds).

Also tried the other LAME versions.

3.97b1 and 3.98a2 (both -V2 --vbr-new) run at about 12x-13x
4.0a14 (-v2) was about 18x-20x

My system specs again:
1400 Mhz Celeron M, 448 Mb Ram, running WinXP Home

MedO

seems your 3.97b1 exe was compiled without NASM or otherwise suboptimal, as there shouldn't be such a difference between those two.

Athlon XP 1700+ (1467 MHz, FSB 266, DDR RAM 333): 29.5x.

Modern operating systems (Windows 2000/XP, Linux, OSX) cache files to memory when they are used, to speed up future accesses. If you have a large amount of free memory, the entire file can remain in cache. The speed up you are seeing is because the data is cached, saving on disk seek and read time.

I'm doing a re-encode as I browse this topic (Boston - Third Stage) and it's running at 2.5x (CPU/REAL). Using AsusProbe, CPU temp creeped up to 71°C and when down fell back to 62° C. I think I'm just going to take my box to a techie and let him fight with it. I sit right by the box with the side panel open and all the fans whinin and it sure brings warm relief when I turn the thermostat down in my house. The only option I am considering is a copper-based cooler and a duct with a fan to the @#$%'n thing! Gee, I'm curious, I wonder if I overclocked would it fry it?

I forgot to mention something about my setup.

Using rounded IDE cables actually helped cool my system down a bit more. It lets the air pass from my front case fans and through the case more easily.

Anybody else running a Prescott might want to try nestling their IDE ribbon cables in such a way that they aren't blocking the front case fans... or just replace the ribbon cables with rounded cables.

So did you run the utility Gabriel suggested or not?

tried again (fast standard), compiles from rarewares and mitiok

lame 3.96.1(mitiok) = 5X

lame 3.97b1(rarewares) = 3.8X
lame 3.97b1(mitiok) = 7X

lame4.0a14(rarewares) = 12X
lame4.0a14(mitoik) = 14.5X

ummh, finally i know what is the culprit......rarewares's compile!!!
Although i can't get speed as high as 12X for a 1.4Ghz Celeron, at least there is significant improvement.

nmake -f makefile.msvc COMP=INTEL ASM=YES MMX=YES

what's ASM?? does it mean SSE? Why there is SSE2 build for LAME in raewres or anywhere else? I can't find a SSE2 optimised LAME

On my computer : AMD Athlon64 3400+ @ 2.7GHz/1GB Ram @ 450MHz/SATA Seagate 7200.8 250GB
cbr lame 3.96.1 encoding speed is about 20-24x
-V2 -vbr--new lame 3.97b(from rarewares) encoding speed is about 12x
hmm.. It is necessary to try the codec from a mitiok's site...

Tried mitiok's compile, but there's no significant difference in speed on my Celeron M. Maybe it's just a bit more optimised for newer processors.

OK, on my system - AthlonXP64 3000+ (Venice), 1GB GeiL Golden Dragon PC3500 (2,3,3,6), all at stock speeds (GeiL @PC3200 speed):

1. Compiled by me, ICL4.5 with slightly changed compile options:

2. Current compile for standard 3.97b at Rarewares:

3. Mitiok's compile:

4. Same compile as (1.) but using ICL9.0:

Clearly there are speed differences, albeit barely worth mentioning.

Not much differences on my system (Pentium-M 1.7GHz). Rareware's compile is a bit slightly faster.

This one is Rareware's compile



This one is Mitiok's compile



But the thing I wonder is why these 2 compiles produced different ReplayGain values.

Edit: Grammar

AMD Athlon64 3500+ (2200 MHz, Winchester), NForce 4 chipset, 1024 MB dual channel memory
Windows XP prof SP2
Mitiok compile runs about 1% faster. This may be within the error margin as well.
Rarewares:


Mitiok:

tried again......

dbpoweramp as frontend, this time, i calculate with better accuracy, the encoding time divided by the length of the audio

lame_enc.dll (rarewares) = 3.575X
lame_enc.dll (mitiok) = 6.75X

lame.exe (rarewares) = 6.5947X


lame.exe (mitiok) = 6.8192X


very confused now, dll and exe are different? Now, is dbpoweramp to blame?

oops it was -V2 (without -vbr--new) key....
P.S. Kingston 1GB DDR 400@450 MHz (2.5-3-3-6-1T) and mobo is Asus K8N(Nforce3 - 250)

Hi there all you intelligent people!

As english isn't my main language and I'm not advanced at the technological side of encoding mp3's I need some down to earth, easily understood, help here from you guys. Or more precise I just want to make the developers of LAME 3.97b aware of that it isn't really working better than the previous version 3.96.1; I'm sorry to say. At least not on my computer!

For a long time I've enjoyed using Lame_enc.dll from inside Audiograbber 1.83 to rip and encode my own CD's to and then burning the songs to Mp3-CD compilations to use in my car. Almost without exception I've settled to use CBR at 256 mbps as I think it produces a fine result.

Now to the problem: I've now tested both 3.97b and 3.96.1 (lame_enc.dll that is) at that setting on my long trusted Athlon Thunderbird 1.2 GHz computer using Windows 2000. And what I find is that with 3.97b the encoding speed is not faster as you declare it should be. Nor is the size smaller. In fact it's twice as slow!

The exact same wave-file encodes into a mp3-file that has the exact same size and no audible difference (to my ear). But 3.97b takes the double time to do it! The song I've used is about 4 min long. It takes Lame 3.96.1 approx 24 sec to encode, but 3.97b approx 52 sec!

Why is that??? Would you please help me out 'cause I do love the encoder and what it normally produces!

What encoding setting did you use exactly?
BTW, CBR 256 files are all the same size, that's why they are called *constant* bit rate

It could be the use of -h (or -q 2), which is equivalent to previous -q 1. Anyway, the time increase shouldn't be as high.

I knew you were intelligent! Sounds obvious now when I consider it that constant mean just... constant...

Anyway as I'm not into this with command lines I just used the "clickable" quality options available in Audiograbber. In BOTH cases I used the settings:

"CD-ROM access-method: ASPI", "Rippingmethod: Buffered burst" and "Rip as much as possible to RAM".

Then "Copy first to WAVE then to MP3" as well as "Rip all songs before encoding" and "Make ID3v1 tag".

Also I settled for "high" and "stereo" because I wanted a high quality file and I've read somewhere that "joint stereo", even though you might gain available bits, causes certain artifacts at higher bitrates and therefore producing a worse sounding file. But I'm open to be corrected!

Any more suggestions? Please!

You could take a look at the Lame recommended settings thread:
http://www.hydrogenaudio.org/forums/index....showtopic=28124
To cut it short, neither constant bitrate and normal stereo are recommended. By using variable bit rate (VBR), the encoder is much freer to allocate the bits, which results in higher quality and/or smaller file size. As for stereo, there have been endless discussions about this, time and time again The overwhelming consensus (see FAQ) is: joint stereo improves quality, even at very high bitrates.
For transparent quality, the current recommendation is to use
--V2 --vbr-new
which gives VBR files around 192 kbps. In audiograbber, you need to set VBR quality to 2 and use the "NEW" VBR method and joint-stereo - or just set lame.exe as an external encoder and use the commandline above.

[/quote]
You could take a look at the Lame recommended settings thread:
http://www.hydrogenaudio.org/forums/index....showtopic=28124
To cut it short, neither constant bitrate and normal stereo are recommended. By using variable bit rate (VBR), the encoder is much freer to allocate the bits, which results in higher quality and/or smaller file size. As for stereo, there have been endless discussions about this, time and time again The overwhelming consensus (see FAQ) is: joint stereo improves quality, even at very high bitrates.
For transparent quality, the current recommendation is to use
--V2 --vbr-new
which gives VBR files around 192 kbps. In audiograbber, you need to set VBR quality to 2 and use the "NEW" VBR method and joint-stereo - or just set lame.exe as an external encoder and use the commandline above.

[/quote]

Thanks a lot sTisTi! I,ll try those settings out! Still... I just can't understand why such a huge change in encoding speed took place in between 3.96.1 and 3.97b! But I guess that is something only the developers of LAME can explain! As for changes in the code and so on. So I believe I have to live with the fact that encoding takes a longer time if I want to use 3.97b in the future... and I want to! After all the latest build is the one recommended now, and because of that it should produce the best end results... Too bad it doesn't come across that way on my old computer. Maybe Santa Claus will look kindly towards me this Christmas and bring me a new one... Thanks once again, you all!

Other people are not experiencing this slowdown.

OK, too bad for me then... It's not always something positive about being unique I guess... But a big thanks för responding Gabriel! It's at least nice to know that you are aware of my dilemma. Maybe it works faster with the VBR settings. I'll try that out. Thanks for the work you pour down into the LAME encoder, and for letting us benefit from it!
Best regards

Just go a sudden idea... Could the problem be that I have an old LAME ACM Codec installed on my computer? I installed a long time ago when I fancied experimenting with video and sound in Virtual Dub (something I don't do nowadays). The version is v0.8.0-3.92. Could it be that it interferes in some way. If that's the case... how can I get rid of it?

The presence of the ACM Codec shouldnt affect other instances of Lame, if you are reading the speed from a 'dosbox' -its not the ACM running, no need to remove it.
Since your Athlon Thunderbid lacks SSE machine code instructions, perhaps there is a scheduling issue with the compile on your old chip. Wouldnt be unusual for a Beta. I think there are at least a couple of different compiles of the new Beta out now.

I also experience ~5X to ~.5X slowdowns during transcoding from WavPack in foobar, im using -V3 --vbr-new. I think it happens during silent or very quiet parts.

Your English is fine.

That's what you get using dumbed-down apps - dumbed-down results. :P
Go to RareWares and get the lame_enc.dll modified to use INI File Setup. Replace the DLL in Audiograbber's directory with it and see how it goes.

Yes, it seems that the replayGain computation is very slow on silent parts.

Floating point underflow can be a bitch performance-wise.

It's a little gross, but inserting "+ 1e-10" into the formula beginning on line 147 of gain_analysis.c fixes the problem for me. I only tested it at 44100Hz though.

--John

Not that this is the right place, perhaps, but I'd like to say how amazed I am that the encoding speed has increased so much with the step from 3.90.3 to 3.97b1 on my PC. When my PC (low budget no-name Athlon 1700) was new i got around 4.5x with --aps. However, soon the encoding got slower and slower, and for the last 2+ years I've had aound 1.5x. Nobody has been able to pin down the reason for such poor performance; a PC benchmark program suggested that there were problems with the RAM performance.

I was astonished when I switched 3.97b1 and -V2 --vbr-new. I now get over 7x for the most time.

These reports are very interesting. Soon after 3.97b1 came out, I did a bunch of speed tests on my Athlon 64 3200+ running Linux 2.6.12-mm. I ripped five or so CDs and encoded them, one including extremely longs silences (Green Day - Dookie). Compiles were with gcc-3.4 (although gcc-4.0 gives similar results) in 64 bit mode, with no ASM.

The composite score with 3.97b1 was 15.2x, with 3.96.1 it was 12.7x and with 3.97b1 modified similarly to the way rompel describes in this thread it was 15.5x. The slowdown that people have reported is extremely interesting, given how much faster 3.97b1 appears to be on my system.