Some people in this forum started using Lame 3.93 already, probably assuming as usual, it must be at least as good as the previous 3.92. I have reason to believe this is not the case this time. Something has really gotten messed up this time, without anyone noticing in time.

I'm still looking for intermediate windows binaries to find out when it went wrong.

Here is a directory of some well-known samples, encoded with --alt-preset cbr 128 on both 3.92 and 3.93 compiles by Mitiok. For reference I added --alt-preset cbr 320 (=insane).

I think the difference heard between the 3.92 and 3.93 samples need not much further explaining!

Hans

Edit: samples and link removed, this issue is solved with Lame 3.93.1.

Yeah, the degradation is pretty apparent. Steer clear of 3.93, at least if you use alt-presets.

There was simply no quality testing for Lame 3.93 obviously by any party. Not by the Lame devs and not by Dibrom or anybody else here. This was said in my "Lame 3.93 released" -thread as well.

I think this was pretty much what can be expected, when there's no communication at all.

Only thing what can be said is: Don't use Lame 3.93.

Anyway the external switch preset like --alt-preset cbr 128 has never been very good at these extreme samples, but now it's pretty destroyed in 3.93.

Since for example --alt-preset cbr 128 is actually pretty straightforward preset using external switches, I believe that the problem can't be corrected by simply tweaking that preset, rather it's probably a problem in internal stuff.. psychomodel or something else.

Pretty weird that Lame devs renamed --alt-preset to --preset, but didn't even check the basic samples whether there's any difference to earlier versions or not.

There was also reluctancy by Dibrom to do anything for 3.93 because of various reasons. So when we sum it all up, we get completely f*cked up Lame 3.93 release..

Are the various binary download sites offering 3.93 as the latest stable release?

A person that finally decides to switch to Lame or start out with Lame that then finds out that the release has problems may just go with something else.

Or not find out and have inferior encodes until they decide to check the binaries again.

It's hard enough to get someone to use Lame as it is.

Sadly, yes, although Mitiok does also still offer 3.92.

I'll keep 3.92 with a big red notice on my mp3 page

Since a lot of people are reading your page, Bejamin, Could you change the recommended version to 3.90.2 (same goes for your audiohq site)? It is still the best tested and tuned version for use with the alt-preset and besides the lack of the --alt-presets for bitrates under 80kbps it offers the same features as 3.92.
dev0

This is incorrect. The LAME development team knew about the problems but chose not to address them properly. The release manager seemed not to actually accept them as real issues, instead confusing the matter and claiming that those pointing out the problems were "windows users whining about more features", assuring us that there were no additional quality issues with 3.93 over 3.92 besides the apparently irrelevant fast preset issue because, after all, LAME 3.93 was supposed to be a "bug fix" release. It's kind of ironic considering that because the main point that 3.93 is supposed to address is some rather obscure bug that does not happen that often.. and for this, stability and quality in the widely used presets have been sacrificed. Don't ask me how that makes sense.

I also might point out that this is the second time that the alt-presets have been regarded in this manner.. (as in, not very important "officially") the first time was with 3.90.2 which I had to release "unofficially" because a bug in the fast presets apparently wasn't important enough to make a seperate release for.

This goes to show a problem with the priorities of LAME development, a lack of planning and coordination, and a lack of management. I've said it all before though, so I won't really get any more detailed than that.

Dibrom,

Is there any way that development could be forked?

Ruairi

done, volcano is doing the same with audiohq so that we can spread the information!

Well, we have a problem.
I'd want to point that we (at least I) were not aware of problem with the abr presets.
The question is now how to solve it, but not why is it like that or who's fault is it.

But if you have constructive proposals about how to avoid that in the future, please explain them.

Regression testing using listening tests before each release would be a good idea. We have a whole community of interested people right here on hydrogenaudio that I'm sure are more than willing to participate in listening tests to ensure quality in future lame releases.

I am an outsider to the LAME developement, but these issues involve me as I maintain a software download site.

From time to time there seems to be problems in the LAME developement and the problems seem to be at the organisational level. I think the whole way that LAME project is maintained needs serious re-thinking and total re-organisation. When compared to some other open source projects, LAME is a very small one and involving only few people, but still LAME seems to be in chaotic state at time to time.

Dibrom and other have done a lot of effort by tweaking LAME to the max, and websites has pushed the "--alt-presets" to the public. Now that the "--alt-presets" have gained a good amount of public acceptance a release like this comes out. Thats a disgrace.

Do you have any suggestion for re-organisation?

One positive thing is that both you and mitiok (you guys probably form the biggest download source for Lame binaries, if distribution with 3rd party software doesn't count) warn people about the quality problem.

Anyway, the question remains, what will happen in the future. And how to continue from here?

Is Dibrom committed to tweak or at least maintain --alt-preset (now --preset) testing for 3.94? Or is there gonna happen something else?

Speak up, people..

Gabriel,

Who is the project owner/leader at the moment? Who is in charge?

There is no project leader now (at least I think).
Alexander is the release manager, but the whole project is driven by a consensus. Included people are mainly Alexander, Takehiro, Robert, and me.

But anyone could speak on the dev mailing list, and will be listened if bringing constructive points.

You can consider Mark as beeing an honorary member.

It seems obvious that none of us has time or ability to do deep listening tests for a verification phase.
I would be happy to have someone in charge of it.

Deep listening tests wouldn't have needed for this. Very simple ones reveal this.

I have to admit that I didn't do any listening test either, because I thought that it was just a bug fix release with practically nothing new, and I wasn't very fascinated about that.
Well there isn't practically nothing new except some rare bug fixed and destroyed quality..

But what has happened has happened.

IMO the least what should be done, when any change is made by a developer, is that he reports if the change has even a remote probability to affect sound quality, and has he tested it (how much, which clips, which settings) if he noticed any differences in quality, and does he think it needs further testing. This info should be presented in clear "form-style", not buried in some technical explanations. Then at least there's a chance that some people will check it more closely in time.

It wouldn't hurt if the release manager would proclaim a public testing period, lets say at least 2 weeks before the intended release day, where it's publicly asked people to test the release candidate as much as possible.

Well, theorically sound quality changes should be caught automatically by the automated test scripts.
However, practically it was not, as nspsytune settings are not included in those tests.

I think that we need both tests: automatic, in order to quickly catch sound changes, and human in order to evaluate those changes when needed.



This seems a good idea.
I hope that we well manage to turn this into a constructive thing.

***************call for help**************

I will try to find when did the thing went wrong on abr presets. Basically it means retrieving the cvs from a given date, and check if it is ok or no. Then based on the result, continue searching up to the interesting date.

But it's likely to take time. So if there are people concerned about this issue, you could also try searching.
We could even go faster by sharing the temporary results of our quest.

Note: in the cvs, there is a changelog file that could help in this task

Actually, I'd say it's cbr, which is more severely damaged than abr. Also the examples Hans provided are cbr.

Incredible but true, a week ago I did a big cleanup, trashing obsolete cdrom's. Just now I remembered there was a 'downloaded software' cdrom among them, and rescued it from the garbage bag! And yes, Dmitry's lame-20020716.zip was on it. The test samples still sound ok on it, so I think we can limit the search from 16 July onward.

Could we use the front news thread for results of this search?

Current result: 16 july was ok. (I compiled a few binaries in order to test, link is in the "news" post)

Just wanted to add that we found when it became bad.

Garbiel,



Then you would need a project leader? Concensus is nice, but in the end some has to call the cards. If there is no time to do the listening comparisons, then why not utilize this board for that - even more than currently. Make Release Candidate versions, and collect feedback before going final. Do you have any roadmaps, milestones - tools to keep things organized...

Very hard for me to give suggestions since 1) I am not involved directly 2) I lack programming expertice.

But if Mozilla is able to stay organized, then it must be possible for LAME too.

But Mozilla has some people paid for organizing...
Really, you can not compare Mozilla to Lame. The size of projects are very differents.

Thread split. Please keep on topic..
http://www.hydrogenaudio.org/forums/index....=ST&f=15&t=4535