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.

Poll

Should the officially recommended version of LAME be upgraded now if possible, or should we wait for 4.0?

Keep 3.90.3 forever, baby! It works fine!
[ 19 ] (5.2%)
Let's thoroughly test 3.96 now, and then possibly upgrade.
[ 306 ] (83.4%)
I'm in no hurry, let's wait a year or two for 4.0.
[ 42 ] (11.4%)

Total Members Voted: 494

Topic: Upgrade the official HA LAME version? (Read 53588 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Upgrade the official HA LAME version?

Reply #50 –
It seems to me people want to keep "waiting" to test the LAME because the Newest, Ureleased Code will be Bigger, Better and Faster (In a sense)....

I think why continue to wait and lets test 3.96...If you keep waiting for the bigger/better product you will be waiting forever 

There is no time like the present....

*EDIT* I just did some quick test of some songs. Lame 3.96 has reduced some 3.90.3 MP3's by 1.5meg...That is a huge improvement and it is faster too...

This new version 100% needs to be tested, considering how much faster and space it could save...

Upgrade the official HA LAME version?

Reply #51 –
Howdy,
Here is a quick test I did of 4 songs that vary a little bit. Promising results considering how much space/bitrate was saved using 3.96....All were encoded using alt-preset standard

Lame 3.90.3  - Bill Medley And Jennifer Warnes - (I've Had) The Time Of My Life.mp3  205     00:04:50     7,464,328     
Lame 3.96b  - Bill Medley And Jennifer Warnes - (I've Had) The Time Of My Life.mp3  188        00:04:50    6,821,741

Lame 3.90.3 -  George Michael - Amazing.mp3                    206       00:04:27    6,891,347    
Lame 3.96b  -  George Michael - Amazing.mp3                    167                00:04:27    5,595,479    

Lame 3.90.3 - Guy Sebastian - Angels Brought Me Here.mp3               198       00:04:00    5,957,192    
Lame 3.96b  - Guy Sebastian - Angels Brought Me Here.mp3             170       00:04:00    5,132,260    

Lame 3.90.3  - Nick Skitz - Slave To The Music (Skitz Airplay Mixx).mp3          217       00:03:36    5,880,020    
Lame 3.96b  - Nick Skitz - Slave To The Music (Skitz Airplay Mixx.mp3          178       00:03:36    4,830,701


Cheers

Upgrade the official HA LAME version?

Reply #52 –
Quote
Howdy,
Here is a quick test I did of 4 songs that vary a little bit. Promising results considering how much space/bitrate was saved using 3.96....

Lame 3.90.3  - Bill Medley And Jennifer Warnes - (I've Had) The Time Of My Life.mp3   205     00:04:50     7,464,328     
Lame 3.96b   - Bill Medley And Jennifer Warnes - (I've Had) The Time Of My Life.mp3   188    00:04:50  6,821,741

Lame 3.90.3 -  George Michael - Amazing.mp3           206     00:04:27  6,891,347 
Lame 3.96b  -  George Michael - Amazing.mp3           167              00:04:27  5,595,479 

Lame 3.90.3 - Guy Sebastian - Angels Brought Me Here.mp3           198     00:04:00  5,957,192 
Lame 3.96b  - Guy Sebastian - Angels Brought Me Here.mp3        170     00:04:00  5,132,260 

Lame 3.90.3  - Nick Skitz - Slave To The Music (Skitz Airplay Mixx).mp3       217     00:03:36  5,880,020 
Lame 3.96b   - Nick Skitz - Slave To The Music (Skitz Airplay Mixx.mp3       178     00:03:36  4,830,701


Cheers

you encoded all using APS?

Upgrade the official HA LAME version?

Reply #53 –
*EDIT* Yes, All were encoded using alt-preset standard

Upgrade the official HA LAME version?

Reply #54 –
I just put together some samples of my own, but I have no idea how good they are, as samples go.  I encoded the whole set to both 3.90.3 modified and 3.96b1 at --alt-preset 128.  3.96 seemed faster (but I did not get the exact speed), and produced slightly larger files in all cases except one (in which it was 1 KB smaller than 3.90.3) - on average, 2% larger.  I'm not sure how representative 30-second samples are, though.

I ABXed what I'm guessing is the biggest problem sample (a selection from (-) Ions by Tool), comparing wav to 3.90.3, wav to 3.96, and 3.90.3 to 3.96.  I won't post any results until I have completed ABX tests of the oher 9 samples (maybe in a week - my ears still hurt from this one).  I don't feel comfortable trying to ABX -aps, though. 

Basically, I'm all for testing out this newest release of LAME.  I agree that this far down the line, how fair can we be if we keep saying that 3.90.3 is the "best" version, if we really don't know much about how the more recent ones compare?  Maybe the test will show that 3.90.3 is still the best - I really don't know.  If that's the case, we've still done the LAME developers a service by thoroughly testing their latest offering, and giving a lot of feedback.  I think that they would appreciate it, no matter what the results are.  If people are willing to give some of their time, it's basically a win-win situation.  We either get a new (and possibly faster) recommended version, or we give the LAME team some much-needed feedback.

Upgrade the official HA LAME version?

Reply #55 –
The poll results are overwhelmingly towards (B) 'Let's thoroughly test 3.96 now, and then possibly upgrade.' That's my position aswell. So despite the vocal minority most people by far (currently almost 20 to 1) *aren't* saying stick to 3.90.x.. hope this encourages the devs.

Upgrade the official HA LAME version?

Reply #56 –
I voted for the 'test and possibly upgrade' option here. I never touch MP3 encoding anymore except for a few rare occassions now but it seems logical to me if the new release is good to use the refinements that have been done since 3.90.3
And as previously mentioned the wider the user/test base, the faster issues can be found and addressed.

Upgrade the official HA LAME version?

Reply #57 –
Having started, then read through this whole thread, I am increasingly of the opinion that Guru is right, and that barring any ABX results suggesting a regression on certain samples, we should upgrade NOW. I mean, all things being equal, the new version is better already.

So, we should start a thread for people to post possible regressions in 3.96b. If no one posts anything important in the next month or two, why don't we just bump the version on the FAQs?

EDIT: I started the thread here.

Upgrade the official HA LAME version?

Reply #58 –
Quote
But why do we need a grand test before changing the official recommandation? Couldn't we simply use lame 3.96 for two or three weeks, and then decree 3.96 fully safe if nothing wrong was reported? It makes sense. I don't see anybody keeping Buschman 1.78c encoder, just because Klemm's encoders weren't collectively tested. Same for AAC, same for vorbis, etc... From where come this idea of a big, collective and complete check-up? And why is it so specific to lame? When a new Nero version is released, all people expect a new release of aacenc32.dll; they're not saying to Ivan "sorry, but PsyTEL 2.15 was more tested than Nero 2.6.2.0, I'll consider Nero AAC in two years if stable. Bye."

If people really care about a possible and serious regression, they have to prove it. It's not to other people to prove that the newest version is superior to the 27 months (!!) old 3.90.x.

I guess it's all about quality. Many people come here and demand to know the utterly best quality mp3 machine. That is what HA.org stands for.

I dread the following scenario: a newer version is recommended after not so rigorous testing, lots of people adopt the new version and spend a lot of time encoding music, someone finds a serious flaw, fury is unleashed upon HA.org. OK, I'm exaggerating, but that is why I think serious testing is needed.

Outside of the HA.org community I think most people are allready using the latest and greatest version of LAME. Also note that the majority here uses LAME with aps for near transparent encoding and it is very close to flawless. As has been shown, the presets are very sensitive regarding changes to the encoder and have been broken in the past.

Most tunings happening around OGG Vorbis and AAC concern the "good enough" quality range and are more easily verified than near transparency settings. In a similar fashion the superior performance of Garfs' tuned Vorbis encoder (which is recommended on HA.org) can be verified because the version you are comparing it to has large room for improvement. The situation with LAME here is different, the recommended version is much closer to optimal and as such it is much harder to improve uppon, let alone confirm this by listening tests.

When work was being done on MPC, it was done by one very knowledgable person dedicated to high quality. There have been a few very critical listeners that have been running their own tests for each new version. The AAC team at Ahead has this "quality assurance" thing which should at least catch major hickups. Apart from the experimental tuning done by some dedicated people here on the forum, OGG Vorbis has only developed very little since the final release. The development process of LAME as a whole and especially the priority given to quality related issues as well as the acceptance of quality related user feedback have been subject to criticism in the past.

What will happen if it turns out that 3.90.3 beats 3.96 quality wise? If 27 month old code is superior to today's. Will we get the same response from the LAME team as in the past? "We only do this in our free time as a hobby so don't you dare expect anything from us. If you don't like it...". If feedback is unappreciated, then I won't give any. Seing that 3.95 now uses the presets as default, maybe this attitude has changed.

I would like a new version to be promoted to recommended mainly because of its speed and closer real-world-usage resemblance. (For example I've allready been usnig 3.95.1 and will now use 3.96b to transcode my mpcs for my portable.)

Upgrade the official HA LAME version?

Reply #59 –
Quote
If 27 month old code is superior to today's. Will we get the same response from the LAME team as in the past? "We only do this in our free time as a hobby so don't you dare expect anything from us. If you don't like it...". If feedback is unappreciated, then I won't give any. Seing that 3.95 now uses the presets as default, maybe this attitude has changed.


I hope that you do not want to start a flamewar...In case you really want, please check and provide facts before.

Upgrade the official HA LAME version?

Reply #60 –
First, for vorbis, the final 1.0 was immediately adopted. It was twice faster (at least) than RC3. But people used it without hesitations: they were just happy, and I never seen HA.org warning for this new release. On the other side, Nero AAC "quality team" seems to be something really new; therefore, it's not an argument, because people used to adopt each new version without deep verification (I'm maybe wrong, correct me if needed)

Second, we can't say to lame developers "we need to test thoroughly the new encoder before recommending it" and then never test anything.
HA.org testing model is not something optimal. It's even not something working at all. As far as I saw it in the past, the attempts to test alphas of lame 3.94 were completely anarchic, and never exceed a week. Lame 3.95 was released some times ago: no serious test.

Last, if there are serious flaws in lame 3.96, we don't need 6 months to find them. Two weeks of daily use of the encoder should be enough to find them. Again, if some people on HA.org or elsewhere fear that something wong might occur with a new encoder, they have to found it. That's why lame team released 3.96 as a BETA, not as a stable version, and give us three weeks for testing. If we can't test lame in three weeks, I suppose it's not responsible nor respectful to wait for a future and highly hypothetical collective investigation.
And don't forget that -Z switch is now something official. It means that the "deeply tested", widely used and strongly recommanded 3.90.1/.2 missed this important (?) switch. Therefore, I think we could accept that possible minor flaw might appear in the future with a new developping branch. No?

Upgrade the official HA LAME version?

Reply #61 –
Quote
I hope that you do not want to start a flamewar...In case you really want, please check and provide facts before.

I don't want to start a flamewar so this will be my last post to this thread concerning this issue. I just recall some threads that were "weird" to say the least. The issue has been discussed to death allready and to me it seems that there is no common ground.

http://www.hydrogenaudio.org/forums/index.php?showtopic=3836
http://www.hydrogenaudio.org/forums/index.php?showtopic=4582
http://www.hydrogenaudio.org/forums/index.php?showtopic=4544

If you tell me that the test result, whatever it may be, will be put to good use by the developers and hopefully motivate them, I'll be happy to believe you until proven otherwise.

Upgrade the official HA LAME version?

Reply #62 –
What you can see/read from these threads is that the 'problem' of lame development compared to Musepack, Vorbis or Nero's AAC encoder is that it is a lot more chaotic and  less controlled. Many people contributing/fixing stuff is definetly a good thing, but also carries dangers.
The other mentioned encoders have only one person activly working on the core for a good reason, the chance of breaking something by turning the wrong screw is just too high.

Developing an encoder is a difficult task and there's a German saying, which states that 'many cooks don't make a good soup'; in this aspect codecs are a lot like soup.
"To understand me, you'll have to swallow a world." Or maybe your words.

Upgrade the official HA LAME version?

Reply #63 –
Quote
If you tell me that the test result, whatever it may be, will be put to good use by the developers and hopefully motivate them


Tests results are always usefull.
But in no way that means that results from tests will be immediately put in use to correct flaws/problems. The biggest problem is available time.

Tests results do not increase our available time, se we can not promise anything regarding when a specific problem will be corrected.
However, you can be sure that test results are helping to use our time more efficiently.

Upgrade the official HA LAME version?

Reply #64 –
Quote
What you can see/read from these threads is that the 'problem' of lame development compared to Musepack, Vorbis or Nero's AAC encoder is that it is a lot more chaotic and less controlled.

You are right, and also gave the obvious explanation:
Quote
The other mentioned encoders have only one person activly working on the core

Upgrade the official HA LAME version?

Reply #65 –
That's why 'problem' is in quotation marks.
"To understand me, you'll have to swallow a world." Or maybe your words.

Upgrade the official HA LAME version?

Reply #66 –
I am all for change, but not for its own sake. I have to admire the optimism of some of the posters here. Surely the overriding issue with regards to the adoption of a new recommended version is is the quality similar, or better than 3.90.2/3? Whether, or not, it is faster is completely irrelevant unless the quality is maintained. If speed is your main consideration, go use Fhg, or Gogo.

There seems to be an automatic assumption that newer is better. This is just not necessarily the case. The whole point of 3.90.2/3 was that it took the tuning of LAME to a level that surpassed anything that was done before, or, in my opinion, since. Since then, the core of the encoder has changed, and so has the structure of the presets. This is not necessarily a bad thing, but without some comprehensive testing of the quality output by the latest encoder, something that has not been done since Dibrom's original work, this is no benchmark upon which to say that the the recommendation of HA should be changed from 3.90.3 to a later encoder; it simply flies in the face of everything that was done in the development of 3.90.2/3.

To adopt a newer version after a period of time simply on the basis that no one has objected to the quality seems to me to be completely contrary to the basic ethos of HA.

Upgrade the official HA LAME version?

Reply #67 –
Quote
First, for vorbis, the final 1.0 was immediately adopted. It was twice faster (at least) than RC3. But people used it without hesitations: they were just happy, and I never seen HA.org warning for this new release. On the other side, Nero AAC "quality team" seems to be something really new; therefore, it's not an argument, because people used to adopt each new version without deep verification (I'm maybe wrong, correct me if needed)

I don't recall that Vorbis RC3 had undergone any rigorous testing and tuning which is the key difference here. So unlike LAME 3.90.3, it was not "tested and approved". Maybe the way how 1.0 was adopted wasn't exactly optimal, that is why we should avoid such mistakes here.

I don't know much about Ahead's QA. I also have no insight in the way that quality related changes were made to the original Psytel encoder.

I'd like to turn the argument around. In general it isn't good practice to blindly adopt new software versions without testing. In the industry you will see lots of Windows NT stations and old Linux Kernel versions because there people have to be anal about tried and tested reliability. In a similar fashion some people are just as anal about the quality of their mp3s. Other concerns, such as encoding speed, are so minor that they do not make a new version appealing enough, if it hasn't been "tested and approved".

Quote
Second, we can't say to lame developers "we need to test thoroughly the new encoder before recommending it" and then never test anything.
I agree.

Quote
HA.org testing model is not something optimal. It's even not something working at all. As far as I saw it in the past, the attempts to test alphas of lame 3.94 were completely anarchic, and never exceed a week. Lame 3.95 was released some times ago: no serious test.
Unfortunatley, yes. So we need to spend further effort on coordinating the testing process, if we want to get it right. Proposals have been made but discussion circles more around LAME development organization and it has been questionable if the desired goal of an improved LAME version can be reached.

Quote
Last, if there are serious flaws in lame 3.96, we don't need 6 months to find them. Two weeks of daily use of the encoder should be enough to find them. Again, if some people on HA.org or elsewhere fear that something wong might occur with a new encoder, they have to found it. That's why lame team released 3.96 as a BETA, not as a stable version, and give us three weeks for testing. If we can't test lame in three weeks, I suppose it's not responsible nor respectful to wait for a future and highly hypothetical collective investigation.
Hm... but at least aps wasn't just made for daily use but also for critical use. Maybe we would be able to find most serious flaws, but we also want to rule out subtle flaws as much as possible. I don't think daily use is going to cover that.

Quote
And don't forget that -Z switch is now something official. It means that the "deeply tested", widely used and strongly recommanded 3.90.1/.2 missed this important (?) switch. Therefore, I think we could accept that possible minor flaw might appear in the future with a new developping branch. No?

At least this shows that HA.org is indeed capable of adopting changes to the recommended version if further testing reveals an improvement.

Upgrade the official HA LAME version?

Reply #68 –
I would like to suggest adding at the top of the "recommended compile" thread something like "As a HA member, you are strongly encouraged to use LAME 3.96 b1 (or the latest alpha/beta version that is out) whenever possible, and report any problems to the forum." in bold type.

Would this work?

Upgrade the official HA LAME version?

Reply #69 –
I am always using the latest version of LAME since 3.92. I never used 3.90.1!

I trust the people who are behind LAME and that they learned from the 3.93 desaster. I think, no one can test the entire set of music of the world, so no one will ever knew, if one version is always better than another. But I hope, that their set of critical material is big enough to ensure a statistical chance.

Let's make the latest version always the recommended version!

Upgrade the official HA LAME version?

Reply #70 –
I'm going to start using 3.96 from here out.  My initial results have been promising.  Definitely faster and definitely smaller files.  So long as nobody else has big issues with it, I'm thinking about doing a re-encode of my entire ~250CD collection  .  It currently takes up about 26-27GB, and if I could get that down a couple gigs, it would be worth the trouble.

Upgrade the official HA LAME version?

Reply #71 –
I would wait and see over the next few weeks...
It looks as if this test isn't going to happen THO...

Upgrade the official HA LAME version?

Reply #72 –
The thing is... people are looking at different aspects of this debate separately, which isn't right.

On one hand most of us seem to come to the conclusion that unfortunately, and despite the hard work of a few people, listening tests around here lately are... not what you'd hope, for several different reasons already mentioned earlier in this thread.

...And then on the other hand a lot of people are happily saying "Hell yeah, let's test the latest version, it would be great to have a new compile!" It would, but a lot of people already agree with the above paragraph, which makes that solution unworkable... it's a bit like saying "OK the solution is to have LAME 4 ready and stable in a month or two." That would be fantastic but it's not feasible, just as having a successful extensive test of the latest compile probably isn't feasible either.

So to sum up those last two paragraphs, I think most people are not looking at the real problem - the testing. The first step to the final solution here is to sort that out, give it some real structure and very clear goals (after determining which goals should be achieved; i.e. which settings to test most, whether to ABX against 3.90.3 or the original wav, or both, etc.). Then we need to see whether that is a realistic aim... for example, I and many others would love to be involved in a test of ABXing --aps 3.96 against 3.90.3; but our hearing just isn't good enough and so taking part in the test would be useless at best and counter-productive at worst. On the other hand, I'm not too keen on testing new compiles at lower bitrates either... because I don't use them and won't use them in the future.

However if a structured test was arranged where many people with the skills to ABX --aps agreed to do things like that, under the understanding that people with lesser hearing such as me took some time to ABX bitrates ~128... that's a different story. But this is what I was talking about in my first paragraph, we need a planned structure for this mass test with clear goals otherwise it probably won't work. But if we do plan it correctly and everyone does their bit then it would result in us all having a shiny new tweaked compile to play with. If.

A follow-on point to all that is that it might still not be worth it - that's a massive amount of effort for a lot of people, with minimal gains - i.e. --aps 3.90.3 and 3.95.1 are transparent for most people. I think the desire for this "shiny new tweaked compile" might result slightly from the placebo effect we all talk about so regularly, albeit about something slightly different.

Weighing up all the views/opinions/conjecture/suggestions brings me no conclusions, there's just too much to bear in mind. So looking at it logically I would have to say that as 3.90.3 has never failed or disappointed me with either quality or filesize, and version 4 is being developed (no matter how slowly...), I'd rather concentrate on saving my efforts for testing that.

I think that a massive point here is that a mass-tested and highly-tweaked version 4 compile would make 3.90.3 pretty much obsolete - if not with regards to quality of sound for most people, then with regards to speed and filesize. On the other hand, a tweaked 3.95.1/3.96 will be a fairly minor step in comparison. Again, I say that whilst comparing it to a tweaked version 4 and pointing out the massive effort and organisation involved in arranging a suitable test.

Last of all I'd like to say that unfortunately (and I do mean that) I think the results of this poll are completely useless. I am convinced that most results are people chosing the "let's test 3.96 now and have a new recommended version!" option because they hope lots of other people will work hard, so that in a few weeks they can proudly download a new recommended compile from Rarewares and feel good about themselves. I'm sure I don't need to point out that when most people take that stance, it's not going to happen. I say that not to patronise people; I admit that I did exactly the above myself on my first read of this thread about 2 days ago. Hopefully this post can put my mistake right.

Upgrade the official HA LAME version?

Reply #73 –
Well that is your opinion...Why shouldn't we test 3.96 tho? 3.90.3 was tested so long ago that IMO I think it would be nice to be able to use the latest version of Lame...Testing would also help the LAME developers...What is LAME V4 dosen't see the light of day for years and years? We will be waiting forever. I say test now and hopefull upgrade....

Upgrade the official HA LAME version?

Reply #74 –
You know why I don't bother switching from LAME 3.90.3?

Quite simple, because no one has organized a listening test that is guarenteed to be listened to by the LAME developers.

There is many reasons why --alt-preset standard has been so successful. Tossing aside the obvious quality gains, Dibrom's internal tweaks, and so on, these what stood out to me when I watched development take place as a user (I hope I am remembering right, it has been so long and I wasn't an active poster at the time, just a reader):

1. Dibrom asked in a thread on the forums for people to test out an alpha/beta version against all known killer samples plus normal everyday music.
2. Everyone (especially those wanting to leave --r3mix behind) followed Dibrom's instructions pretty much to the letter. Tons of music and killer samples were tested using ABX.
3. The results of the tests were posted on the board. Dibrom and the rest of the community was able to verify or debunk results very easily with another ABX test, this time by themselves.
4. New compiles were posted, new listening tests were organized, and everything was pretty much repeated.
5. The entire time Dibrom and those who helped him out were talking practically in real-time with the community, asking for input, trying to isolate problems. Everyone could read these discussions and everyone knew what was going on practically to the minute.

At the end, we had the most amazing MP3 encoder ever released. Dibrom and those who worked with him did all of the hard code work, but we as the community were able to have communication enough with him that we could easily organize a strong effort to test his work. The results speaked for themselves.

Then Dibrom left LAME development.

Communication has broke down between the community and those who do LAME development. If the LAME developers even bothered to post on Hydrogenaudio, it was and still is briefly and not often.

My impression has been that users (including myself) feel the developers just don't care about us. No one that we could rally behind was or is giving instructions and guidance on where to focus our endless energy. No one was or is even telling us what is upcoming in the future.

All of us are very interested in development of our favorite MP3 encoder. Sure AAC, OGG, MPC, etc. maybe sexier right now, but last time I checked MP3 by far is the most universal and standard codec today. Any improvements, even small ones, can effect the MP3 world for the better in a big way. That is why we are all drawn to LAME. That is why --alt-preset standard was such a huge success. If you asked me years ago when I was used Napster if we would get --alt-preset standard quality from MP3's at a reasonable bitrate, I would laugh my butt off. But look, it truly happened! It wasn't some large corporation or business trying to sell us the latest Musicmatch or RealPlayer type software. It was a community of dedicated people from across the world, with diverse music tastes, languages, and even time differences that put this together.

It used to be that there would be a big announcement on when a new alpha or beta version of LAME was released. All of us who crash the FTP servers just to get our hands on the release to test it. Now, we jumped from version 3.95 to 3.96 stable without one public notice of test alpha/beta versions that I can remember seeing and I check Hydrogenaudio daily. In the meantime, companies/people that release software that uses LAME always upgrade to the latest version that could/probably have bugs in it that would of easily been caught had there been a proper test early on in the alpha/beta stages.

What happened to the organized tests? What happened to the developers showing everyone that they care? Dibrom back in the day (man I sound like we are talking about 50 years ago!) gained his huge following because he cared about those who would be using his work. I guarentee Dibrom gained more staisfaction (and still does to this day) about how many people enjoy LAME (and talking with everyone about how how he improved/fixed certain issues) because of --alt-preset standard and his work then the satisfiaction he got from coding it.

Developers, show us you care about our feedback and that you want us to use LAME and we will show endless passion in return to help out. You may lose a little coding time, but in the long term you will gain a ton more.

If the developers don't care about us and don't change, worst case we are stuck with 3.90.3 as the last truly stable and tested version. That isn't the end of the world (there are still millions of people who are missing out on these benefits from --alt-preset standard), but we can still do better.

This is your chance LAME community and the developers. This is all I have to say.
iTunes 10 - Mac OS X 10.6
256kbps AAC VBR
iPhone 4 32GB