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: --alt-preset sloooow??? (Read 5873 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

--alt-preset sloooow???

Wow. I'm using --alt-preset standard -B 256 on my Athlon 1133 (the B256 is a concession for my Sony D-CJ01 mp3 CD player), and it just took 6:20 to encode a 7:25 song. :eek: :eek: :eek:

Guess fast standard is the way to go. How much faster is it then? Let's see...

Is this normal? I'm using the current recommended compile, 3.90.2

--alt-preset sloooow???

Reply #1 –
Yeah that's normal... the --alt-presets need much longer than the "normal" lame settings
My Athlon 500 needs 20-30 minutes for a 7 minute long song

--alt-preset sloooow???

Reply #2 –
Quote
Originally posted by Joe Bloggs
I'm using the current recommended compile, 3.90.2

Is the "recommended" compile Mitiok's compile? Mitiok's are usually quite fast (2-3x realtaime on my Athlon 1200, withaout any other software than LAME running at the moment) ...

--alt-preset sloooow???

Reply #3 –
yeah, just use a lame 3.92  mitiok compile!

--alt-preset sloooow???

Reply #4 –
Quote
Originally posted by Benjamin Lebsanft
yeah, just use a lame 3.92  mitiok compile!


The recommended compile was made by Dibrom with ICL using switches similar to Mitiok's.

It makes no difference, quality-wise (talking about alt-presets), which one to use. Use the one that is faster for you.

Regards;

Roberto.
 

--alt-preset sloooow???

Reply #5 –
Quote
Originally posted by Joe Bloggs
and it just took 6:20 to encode a 7:25 song.

Is this normal? I'm using the current recommended compile, 3.90.2


No, that's not normal.  On a processor like that I'd believe you should be getting at least 3x or 4x realtime.

--alt-preset sloooow???

Reply #6 –
Quote
Originally posted by Slo Mo Snail

My Athlon 500 needs 20-30 minutes for a 7 minute long song


Hrmm.. I don't think this is normal either.  I'll have to check, but I believe I was getting the same speeds on my p2 300 laptop, which should be slower for sure.

--alt-preset sloooow???

Reply #7 –
i get 1.4x speed with mitioks exe and "--alt-preset-standard -B256"
on my Athlon650.

my own compile does 1.44x )

maybe you could try mitioks compile also, and if it is slow too, then you know it's not a problem of the lame exe.




bye,rocko
bye,rocko

--alt-preset sloooow???

Reply #8 –
where can we get your builds rocko ?

--alt-preset sloooow???

Reply #9 –
Btw, also of some importance:  What kind of music are you guys encoding (those with slow performance)?

LAME with the --alt-presets will slow down significantly on some test signals like fatboy.  If you're encoding music which is excessively heavy on this type of thing, that might be leading to these results.  Still, the song would have to be full of them, which is kind of unlikely..

This probably isn't the cause, just something to make note of.

--alt-preset sloooow???

Reply #10 –
Quite a bit of rock, but even the acoustic guitar stuff didn't seem faster for me (K6-2 333MHz 128MB).

Hey, I heard you (Dibrom) knows something about the workings of --aps ;-) I wondered what, if anything,  would happen if a LAME source was stripped to the essentials for using --aps before compiling. I was hoping it would speed up. Or is this a no-no for whatever licensing LAME uses?
"Something bothering you, Mister Spock?"

--alt-preset sloooow???

Reply #11 –
Mine was some Heavy Metal...

--alt-preset sloooow???

Reply #12 –
my builds are available on my harddisk 

for my Athlon i made an ICL 4.5 compile which has
no code for running on Pentium1.
P2 or higher required.

the mitiok compiles have this P1 code as far as i know, so that he doesn't have to distribute several different exes.

i also tried an ICL 6.0 compile only for P4...and it was even faster than the ICL 4.5 version.

i can send you the exe by mail, Benjamin.

bye,rocko
bye,rocko

--alt-preset sloooow???

Reply #13 –
Quote
Originally posted by Destroid
Hey, I heard you (Dibrom) knows something about the workings of --aps ;-) I wondered what, if anything,  would happen if a LAME source was stripped to the essentials for using --aps before compiling. I was hoping it would speed up. Or is this a no-no for whatever licensing LAME uses?


There would be little difference in speed from this because the code (functions) that is not used is not called.

However, there may be some code within certain functions which is unnecessary, but then it's not really a matter of "stripping down", it's more a matter of rewriting LAME. 

Yes, I do think LAME could seriously benefit from a rewrite from scratch.  There's a whole ton of messy and non-optimal stuff in there.  Who would actually take on such a task?  Good question.

It's certainly not going to happen given the complete lack of organization in the project right now, the lack of a team leader willing to drive the project properly (taking charge and setting goals that need to be met, etc), the fact that the current project mentality seems to be that of "let's just add more stuff and not worry about fixing the current default code", or the fact that there seems to be almost zero Quality Control or proper testing of code commits.

From a development point of view (especially in relation to improvements in quality and usability), LAME is in pretty bad shape right now, and a proper rewrite, implementing the most optimal techniques currently within LAME and disregarding the rest, is a pretty massive undertaking.

--alt-preset sloooow???

Reply #14 –
But from a 'quality' point of view LAME is still the best huh?

--alt-preset sloooow???

Reply #15 –
Well, when I'm encoding mp3s it's only in the background, there's LOTS of other things going on in my computer, so I guess there's the problem...

Is there any way for me to let LAME have higher priority?

--alt-preset sloooow???

Reply #16 –
Quote
Originally posted by Joe Bloggs
Well, when I'm encoding mp3s it's only in the background, there's LOTS of other things going on in my computer, so I guess there's the problem...

Is there any way for me to let LAME have higher priority?


Well, in EAC at least there's a setting to determine the ripping and encoding task priorities, in the main "EAC Options" section, in the Extraction tab near the bottom.

--alt-preset sloooow???

Reply #17 –
Anybody got an idea on how fast encodings I could get with my future AMD XP2000+? Anybody got anything close?

--alt-preset sloooow???

Reply #18 –
i've compiled the lame 3.92 sources from mp3dev.org with ./configure, make, make install on my PIII 533MHz, 256MB RAM using SuSE Linux 8.0 with standard gcc installation.

this binary reaches 1x realtime with --alt-preset standard on my machine.

is there an way to speed them up a little bit?

Dezibel

--alt-preset sloooow???

Reply #19 –
Quote
Originally posted by Dibrom

It's certainly not going to happen given the complete lack of organization in the project right now, the lack of a team leader willing to drive the project properly (taking charge and setting goals that need to be met, etc), the fact that the current project mentality seems to be that of "let's just add more stuff and not worry about fixing the current default code", or the fact that there seems to be almost zero Quality Control or proper testing of code commits.

From a development point of view (especially in relation to improvements in quality and usability), LAME is in pretty bad shape right now, and a proper rewrite, implementing the most optimal techniques currently within LAME and disregarding the rest, is a pretty massive undertaking.


I don't think it is because of lack of leadership or organization. IMHO, there are no such things from long time ago on LAME project

Once apon a time, LAME grows too rapid because there are too much "easy to find bugs" and "easy way of improving the quality". These obvious bugs/improvements are easily confirmed by everyone and everyone agreed to change the code. There are no big discussion and argument, and no leadership is needed because there're no conflicts of opinion.

But current LAME is matured much. Such easy way to improve the qualit/speed/etc. are almost done. We need a BIG CHANGES, and it needs LEADERSHIPS.

I am not full time developper of LAME and not good at discussion (and English). I am sorry to say that I can't be the leader. What I can do is only writing the code with big changes on my closed branch
May the source be with you! // Takehiro TOMINAGA

--alt-preset sloooow???

Reply #20 –
12345,
With --APS I get speeds of around 3.5x on my Athlon XP 1700. I'm guessing you'll see something between there and 3.9...
"We live as if the world were as it should be, to show it what it can be..." - Angel

--alt-preset sloooow???

Reply #21 –
Quote
Originally posted by takehiro
What I can do is only writing the code with big changes on my closed branch


Do you consider making this closed branch available?

--alt-preset sloooow???

Reply #22 –
Quote
Originally posted by rjamorim

Do you consider making this closed branch available?

already available as takehiro-2002_05_07-experimental branch on sourceforge cvs.
May the source be with you! // Takehiro TOMINAGA