Hi guys,

As you know lame isn't very fast to encode (on my home computer at least) but it is worthwhile because quality is there.

I am looking for an encoding platform which has to be very fast. I mean, less than 60 seconds to encode 60 minutes of audio to mp3. (work for my studies)

That's why I am looking to high-end computers. I don't know if that's a good solutions. You maybe have better ideas (clustering...??)

Thanks for your help.

LAME at 60x? don't think it can be done right now.

Thank you,

What speed can we expect at the best ?
I saw a multithreaded version of lame which may be faster on a dual/or more processors.

the best i have seen is 18x IIRC.

Helix encoder is faster than Lame but I don't know if even it can do 60x.

thank you for these answers.

I will do some research and perform some tests.

But the more the project goes on, the more it becomes irrealistic

Well, this cries for extreme measures... After some testing I got Lame encoding at 65x on my Celeron M 1.4Ghz.

Here's my commandline:



The quality is better than I had expected from -q9, and you might compensate somewhat by cranking up the bitrate. Also please note that the input file was probably still cached, you need 10Mb/s transfer rate from your harddisk to read a wav at 60x.

MedO

Wow, yeah that does work! and on the hyperthreading version I get 113x!!!

My AMD Athlon 64 3000+ (overclocked from 2.01 to 2.29GHz) can encode at ~19x -V 5 --vbr-new -q 0.

edit: I forgot to mention that I use -q 0

Somehow i think that is untrue. My PC is P4 4.2Ghz, (overclcoked from 3.8) and can only manage 4x at that quality, and seeing how AMD's are worse at encoding, its pretty difficult

What lame versions you are talking about? 397b2 has no working q0 switch used this way. It is forced to use q2.
MuncherOfSpleens speed is about right for his system then. I wonder why you only get 4x

Edit: Sorry, don´t know if V5 uses q2 by default but it is locked for sure.

I just got 11.253x with those settings on a 2 GHz Athlon XP 2400+.

Im using Lame 3.97 b1, which is not forced to use q2. Should i be using another one

Sorry! my fault! i typed in the command wrong. I typed in --vrb-new instead of --vbr-new....

I get 25x with those settings

Sure it is forced! As soon you give a V value its default q setting is used. Doesn´t matter if you add the q0 switch. This is for 397b1 also.

you are incorrect, just try it and see! q2 is not forced

It doesn´t give an error. Watch the resulting file. They are bit identical even if you add the q0 switch. btw. i just noticed V5 uses q3.

then explain why -q0 encodes slower than -q2 if -q2 is forced?

We are talking about the commandline above. There is no speed difference when q0 is added. As this is --vbr-new it doesn´t change anything with the 397 betas.

To get On topic again. This --noreplaygain switch gives about 5-8% (estimated) speed improvement here.

There IS a speed difference. Try it! im now using 3.97 b2

-V5 --vbr-new ~ 23,420
-V5 --vbr-new -q0 ~23,465
The speed is indeed different maybe i moved my mouse to long for that difference?

on my machine, i got 26x on q3, and 24x on q0

The "Lame encoding speed"-Thread has shown the opposite IMO. AMD Processors in general and intel processors based on the P3 or Pentium-M core seem to handle the encoding pretty fast, while the P4s were WAY slower even at double the clock speed.
Didn't anyone wonder why the next generation Pentiums will be based on the Pentium-M instead of the P4? Well, now you know.

OK I'll explain the usage of -q values with LAME 3.97b

For --vbr-new only -q0 through -q4 produce identical results. -q5 is by itself, and -q6 through -q9 produce identical results. This is the word from the LAME devs themselves.

Even though the Penitum-M is a modified P3?

But back on topic,

I just encoded a mix which was 3hr 9min long, using -q9 -b128 --noreplaygain

It took 1min 51sec. Average 101.69x

Pretty good for lame!

I think Helix is better suited here. I get about 60x speed with std. vbr or cbr encodings on my XP 1800+ - Quality might be better than what lame produces in it's lowest quality mode...

From Wikipedia, http://en.wikipedia.org/wiki/Pentium_4:



I heard the thing from a friend who knows a lot about hardware stuff... I know it says here that the heat problem was the final decision factor. I didn't know about that one until I read the text just now, but I doubt it was the only consideration.

Yeah, weird that one. I havent tried helix encoder yet, but gogo lame encoder, seems to run slower than normal lame at -q9. hm..

To give a quick and dirty summary:

Imagine I have two machines, both produce the same widget but they are built very differently internally.

Machine one (P3) spins its framistat at 1000 rpm, and produces 10 widgets a minute.
Machine two (P4) spins its framistat at 2000 rpm, and produces 10 widgets a minute.

While I find it is initially easier to make machine two's framistat faster (and at the same time, I have to decrease the widgets per RPM slightly), I find that it is extremely difficult to make it faster than 4000 rpm. Then, in the meantime, I find ways to make machine one produce 15 widgets per minute at 1000 rpm and also how to increase the number of RPM's to 2000.

The end result of this example:
Machine one (Pentium M derivative) spins its framistat at 2000 rpm, and produces 30 widgets a minute.
Machine two (Modern P4) spins its framistat at 4000 rpm, and produces slightly less than 20 widgets a minute.

These numbers are purely for example. For more reading, please see
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2627
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2648

Yeah i understand why the P3 technology is better, but what is not true, is that AMD cpus, are better at encoding than P4's, as multiple tests have proven this to be untrue.

To play Devil's advocate,
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2484&p=9

and

http://www.tomshardware.com/2005/08/01/dual/page11.html

It really depends on the situation.

EDIT: Added Tomshardware link.

jimhaddon, you could also try a different compile of lame, maybe the one you use isn't well optimized for P4s.

My build is optimised for P4s, I find the HT version of lame very good too!

Your CPU might also be throttling to prevent overheating. There was another thread about all this a while ago, search for "LAME encoding speed" or similar. I just find it weird that you get less than third of the encoding speed I get, while your CPU is clocked three times as fast. If this was completely a processor architecture thing, this would mean that the Pentium M worked ten times as efficient, which sounds too strange to me.

wooooww I will test with that presets.

Thank you to all of you.

I remember when the P4 was first launched, an overclocked P3 was considerably faster. The P4 was really just Intel's attempt to make a stripped back CPU in order to win the clock speed race to impress ignorant corporate customers.

I think its because the HT version of lame works much faster on my machine than the gogolame. My cpu is not throttling, i have performed MANY stress tests on it.

The current HT version of Lame is reducing quality, beware...

O i know that, dont worry im only using it for testing purposes, not actual encoding. Still, it works very well!