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: Improving LAME - another point of view (Read 5242 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Improving LAME - another point of view

Especially to Dibrom and other LAME devs & compilers:

http://homepage1.nifty.com/herumi/gogo_e.html

Could there be something in the GOGO NoCoda that could be implemented back to LAME? Naturally I am talking about speed - not quality issues. Speed is never a bad thing, and actually APS is quite slow without the fast-switch.

BTW, it would be (just for fun) interesting to see some GOGO results in the EAN tests.

Improving LAME - another point of view

Reply #1 –
I talked to the guys that made gogo.

They explained me that it would be very difficult to port all the optimizations (especially the smp ones) to lame because of portability.

Lame should be really portable, but gogo doesn't have to. It's easier to optimize when you only have to care about x86 compatibility.

Btw a few of those optimizations are already into Lame.

Improving LAME - another point of view

Reply #2 –
Quote
Originally posted by cd-rw.org
Could there be something in the GOGO NoCoda that could be implemented back to LAME? Naturally I am talking about speed - not quality issues. Speed is never a bad thing, and actually APS is quite slow without the fast-switch.


I'm sure there are probably some more optimizations from GOGO that could work in LAME, but the problem is that not many people seem to have time to port them.  However, the ASM code currently present in LAME originated from GOGO I think.

Another interesting bit of information is that I think (though I'm not certain) that GOGO in general (even based off the newer LAME versions) "cuts some corners" so to speak to encode at the speed that it does.  If that's true than it may not be possible to use certain optimizations (which may end up being the most critical ones) from this encoder.

I don't really know much more about it than that, but I think Gabriel does, I've seen him talk about GOGO at times.. maybe you should ask him  Edit: Guess he responded before I could

Improving LAME - another point of view

Reply #3 –
As far as I remember, I think that Gogo disabled the GPSYCHO part of Lame, which probably speeds up the encode a hell of a lot, however I read this in a forum so I don't know how true this is.

Also, I've found traditionally that Gogo was based upon out of date versions of LAME, so perhaps its only useful for rush encoding for say, 128kbps encoding. I'd hate to throw anything else at it.... however, I'm finding that lame is darn fast at the moment anyway.

Ruairi
rc55.com - nothing going on

Improving LAME - another point of view

Reply #4 –
Quote
Originally posted by rc55
As far as I remember, I think that Gogo disabled the GPSYCHO part of Lame, which probably speeds up the encode a hell of a lot, however I read this in a forum so I don't know how true this is.
Umm, gotta admit I don't know almost anything about GOGO, but it doesn't sound believable that GPSYCHO (full psychoacoustic model) is disabled...
I think more likely is that it's highly speed optimized.
Juha Laaksonheimo

Improving LAME - another point of view

Reply #5 –
I don't think GPSYCHO is turned off by default in GOGO, but I do remember that one of the main switches allowable is to turn off the psymodel, and that doing so greatly increases speed.

Improving LAME - another point of view

Reply #6 –
Quote
Originally posted by Dibrom
one of the main switches allowable is to turn off the psymodel, and that doing so greatly increases speed.

...and greatly decreases the quality. If you want speed, use Xing.

x86 optimizations would be nice but as the months go by, new CPUs get faster and faster. LAME aps operates at about 2x real-time on my Celeron-800. On an Athlon XP 1800+ perhaps the speed would be 5-6x real-time. That's pretty speedy encoding. Perhaps there are still people stuck with PII-400 systems but hyper-fast machines aren't terribly expensive nowadays. Time will minimize this need for speed (and the need for lossy encoding as hard disks grow and DVD-Rs proliferate).

Improving LAME - another point of view

Reply #7 –
Regardless of the exponential nature of system speed (as of present, I still think that optimising the encoding speed is paramount, just as much as quality, and I'm sure the majority of people would agree.

Users - in general - fall for the AudioCatalyst selling point, 10x rip and encode on the fly. I've always found it hard to appeal to the general users (I often promote HQ encoding in my workplace - a computer retail shop), when they find that their drives ripping securely take time and the encoding using special presets also takes more time.

Lame as of late is taking the right steps! Dibrom's presets have the right mentality - great quality, for the majority, and still Lame has the flexibility for specific environment.

Still, however good this is, I have to say I do get frustrated at having to invest so much time to encoding. I know I have the choice to encode at such quality but we the users will always be frustrated at the time things in general take, but we're always pleased when its cut with optimisations.

So stay on the right track! Optimise

However -- just as an aside, my dream version of LAME would probably be one that would integrate with CD ripping a lot better, regardless of platforms. EAC (the latest beta) is making the right moves, however its still not as seamless and intuitive to the average user. Secure ripping and alt-preset encoding from one application is what I'd like, CDDB, the lot, also with the flexibility to tweak for specific environments.

Yes -- I know at the moment, what I want to achieve is achievable but I'd like to think I could point friends at a single application to meet all needs thats INCREDIBLY easy to use.

SatCP, r3mix, projectmayhem, dibrom and everyone here have made the transition to good encoding for me quite easy, but I feel what's needed is unification... no tutorials just an easy solution for everyone else I want to get converted.
rc55.com - nothing going on

Improving LAME - another point of view

Reply #8 –
Sorry to interfere just like that but:

Quote
Originally posted by rc55
Users - in general - fall for the AudioCatalyst selling point, 10x rip and encode on the fly. I've always found it hard to appeal to the general users (I often promote HQ encoding in my workplace - a computer retail shop), when they find that their drives ripping securely take time and the encoding using special presets also takes more time.


Yeah, that works for me too... fell for EAC secure + mpc... 20x rip & encode on the fly @16.5x (Athlon XP 1.9+, Asus 52x)... don't know but I guess that LAME could be improved to encode at 10-12x at least on such a system.

The way I see the LAME programming (some people might get mad here, because this is just a "newbie" assumption) is that the code is patched & repatched for quality, and has never been properly optimized for speed or as soon as it gets some speeds improvements something else is changed.

Improving LAME - another point of view

Reply #9 –
lucpes: Yeah, mpc is a great format for encode speed and quality, its a shame its not as universal as mp3.

As far as the speed goes, check the LAME history/changelog, very often speed optimisations are submitted and released:
http://www.mp3dev.org/mp3/history.html

Ruairi
rc55.com - nothing going on