IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Improving LAME - another point of view
cd-rw.org
post Feb 15 2002, 10:45
Post #1





Group: Members
Posts: 176
Joined: 5-October 01
Member No.: 217



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.


--------------------
http://www.bitburners.com - We Burn a Bit
Go to the top of the page
+Quote Post
Gabriel
post Feb 15 2002, 11:33
Post #2


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
Dibrom
post Feb 15 2002, 11:34
Post #3


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



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 smile.gif Edit: Guess he responded before I could smile.gif
Go to the top of the page
+Quote Post
rc55
post Feb 15 2002, 11:41
Post #4





Group: Members
Posts: 366
Joined: 15-October 01
From: Exeter, UK.
Member No.: 300



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
Go to the top of the page
+Quote Post
JohnV
post Feb 15 2002, 19:31
Post #5





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



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
Go to the top of the page
+Quote Post
Dibrom
post Feb 15 2002, 19:35
Post #6


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



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.
Go to the top of the page
+Quote Post
mithrandir
post Feb 15 2002, 20:07
Post #7





Group: Members
Posts: 669
Joined: 15-January 02
From: SE Pennsylvania
Member No.: 1032



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. wink.gif

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).
Go to the top of the page
+Quote Post
rc55
post Feb 15 2002, 23:00
Post #8





Group: Members
Posts: 366
Joined: 15-October 01
From: Exeter, UK.
Member No.: 300



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 smile.gif

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. smile.gif


--------------------
rc55.com - nothing going on
Go to the top of the page
+Quote Post
lucpes
post Feb 16 2002, 11:05
Post #9





Group: Members
Posts: 517
Joined: 9-October 01
Member No.: 254



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.
Go to the top of the page
+Quote Post
rc55
post Feb 16 2002, 12:10
Post #10





Group: Members
Posts: 366
Joined: 15-October 01
From: Exeter, UK.
Member No.: 300



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
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd December 2014 - 05:38