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: Plans For --alt-presets, Etc, In Lame 3.93 (Read 47460 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #50
Quote
I can't think of any valid reason to release a new LAME version unless it offers a smaller compression rate with the quality we have come to expect from the "presets"


If 3.92 is good enough for you, you don't have to use 3.93 (and it's a good praise for those developers which invested their free time to bring LAME to a point where it is now). 

But please don't forget those people which aren't in the same situation as you are. We got some improvements from people which don't affect the majority of people, they affect some of the users of LAME and those fixes may even result in more users of LAME, so they are worth to get released. There's also a program (xmcd) which depends on some of those fixes.

And for those people who ask why we need e.g. 64bit fixes... there are new machines for your desktop in the wings, which have 64bit CPUs. Those CPUs don't only provide the possibility to address more RAM, they are also faster than actual CPUs. You may not buy such a fast machine to encode your MP3s with it, but such a machine may be used to produce Videos/whatever, and you want to have a working LAME for them, aren't you?

Quote
I mean, aps is transparent already in 3.92!!! What does 3.93 do for aps??? Encode it a slight bit faster? Who cares?


Those with slow machines. Or those which want to make embedded systems with it (e.g. digital VCRs).

Quote
It's too bad to see it delayed.


At the moment lame 3.93 isn't delayed. My actual schedule for it is the next weekend (or maybe one week later). If we don't have a fix for the fast preset it will get delayed then, but lets talk about this in two weeks... ;-)

Bye,
Alexander.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #51
Well, I for one don't care what LAME is released as: 3.93, 3.93b, or whatever.

I've played with the binary Dibrom posted, and I must say that I really do like the lower-bitrate presets! ap-portable is simply fantastic for encoding music for my iriver solid-state device (128MB)! Heck, even ap-radio sounds pretty darned good for portable listening!

So whatever you call it, I've already started playing with, and using, these portable presets, and I like them regardless of what "version" of LAME they come from.

Guys, just call it 3.93 and be done with it! A small-change release is fine (release early, release often). You can always put any "big changes" into a *4.00* release, if you ask me!

It's all just semantics, anyway. The software is the same.

And it's great. Thanks for all your hard work!

-Josh

Plans For --alt-presets, Etc, In Lame 3.93

Reply #52
Quote
Quote from: Dibrom,Oct 11 2002 - 10:01 PM
Quote
We have some users which may benefit from a new release so we should make a new release.


By the same token, we have many users to which it may be their detriment to make a new release without proper quality testing.


The changes between 3.92 and the actual code are bug fixes, portability fixes, speed improvements for "non-mainstreem OS's" (as you like them to call) and also new code (substep noiseshaping and some VBR changes). The portability fixes and speed improvements for other OS's are done in a way to not affect the quality. The substep noiseshaping has to be explicitely activated. So these changes can't change the quality per definition. Can we agree on this?


In regards to the "non-mainstream OS's", this is not a negative comment, it's a simple fact (look at the numbers).  I also think that most reasonable people would agree that there would be far more users encoding audio on a more multimedia friendly operating system than the ones for which the much touted bug fixes of 3.93 were made for.

If the code improvements which affect speed produce bit identical results, then yes I agree that these per definition would not change quality.  The VBR fixes do not provide bit identical output though, so you cannot be certain that they do not affect quality without rigorous testing.  Anything else is just an assumption.

Quote
Reading the public parts of their discussion and reading the commit log of the changes I had the impression they also did listening tests and made sure the quality at least stayed the same. Takehiro can tell you more about this.


Listening tests on what samples?  How many samples?  On what equipment?  How many people participated in the test?  Was it a blind test?

Simply "testing for quality" doesn't mean much by itself.  Before the --alt-presets supposedly all the rest of the code (including the "inferior" nspsytune) had been "tested".  I think that we can all say quite safely that most of the conventional knowledge about "quality" didn't really hold up once the --alt-presets were being created.  The thing is.. this is something the developers should have done... instead it took a user concerned about quality (because the developers weren't concerned enough) to come and fix it for them.  So please forgive me for not having very much faith in the testing conventions of the LAME development team.

And this is not to imply that I don't appreciate the work to improve the psymodel from many of the developers like Robert, Naoki, and Takehiro.  Many of them have done great work, especially when flaws in quality were pointed out to them, but as a whole.. LAME does not have very good quality control and testing habits at all

Quote
For the bugfixes: bugfixes are per definition improvements, even if they affect the quality in a negative way. If they affect quality in a negative way, the problem is the algorithm, not the bugfix. So if a bug results in better quality, this isn't a deterministic behavior, it may affect other input data in a negative way (this now depends on the definition of "bug", but at least the bugfixes after 3.92 are real bugs you want to have fixed). If I remember correctly, there are also fixes which result in a better portability of the generated MP3s (and these may affect the bitrate and may therefore result in a worser sounding MP3s, but even if the quality degrades, the resulting MP3 is an improvement because the bitstream is more correct). And I think this may be the reason for the higher bitrate for the fast preset.


I agree with you on the merits of a bug fix, but I think that it's more important to retain stable quality from release to release than to fix bugs and not show much concern for how that might have negatively affected quality.

You see, for people not practically affected by these bugs (which I would say would be quite a large people), they are going to wonder why quality has degraded.  You can get into quite an abstract and theoretical discussion on the merits of code development, but the end product which a user is exposed to is more important than all the bug fixes in the world.  If it doesn't perform as well (even if it functions more "correctly"), then I'd venture to say
it is worse.  I think most people would agree with this also.

Quote
Quote

Quote
Why I don't want Takehiro's code in 3.93:
At the moment we have code which is proven to be "stable" (about the fast preset issue later),


Proven by whom?  Who has done the extensive listening tests to prove that 3.93 has not regressed in quality even in areas not related to the fast presets?  I don't know of any such tests.  Please let me know if they exist.


I don't have a formal prove. But sometimes you can tell it by looking at the changes. I haven't looked at every change, but see above.


I still stand by my statement that unless code changes produce bit identical output, you cannot be absolutely certain of their improvements.  You need to have some sort of control, and that's what rigorous listening tests are for.

Quote
Quote

Quote
It doesn't hurts if we make a mature release yet, and another release with Takehiro's code shortly after that (I'm thinking about making the release 3.93 release as soon as possible and making a 3.94beta release after Takehiro's code is merged).


Yes but only if we are certain that this code is actually "mature".  Without proper listening tests, we cannot be sure of this.  If we are going to spend the time doing the listening tests, then why don't we test Takehiro's branch instead?  I know for a fact from just a few short tests I performed that his branch fixes some of the remaining major bugs in the --alt-presets.


Takehiro already answered, that the actual code is more mature than the code in his branch. And if we assume that the 3.92 code is mature, you only have to point out flaws in the changes. That's not that hard as it may sound, just take the file ChangeLog and read the commit messages. You just have to look at changes, where the commit message tells you the change is in a critical section but tells you nothing about listening tests.

E.g. we have the fast log changes. Theses changes increase the speed of lame by reducing the precission of some floating point calculations. Theses changes affect the output data, but they just result in minor rounding errors. And yes, some developers did listening tests with those changes.


Yes, but we have really no information about how those listening tests were performed.  That information is more important than the fact that listening tests were performed at all.

And about rounding issues, I've mentioned in the past that with the --alt-presets, I have heard a difference in quality between Intel Compiler builds and MSVC builds when one of the switches that controls rounding behavior in the Intel Compiler was used.  This resulted in more pre-echo on the fatboy sample.

So just because it's a "subtle change", doesn't mean it can't definitely have an audible impact on the sound.

Quote
Quote

Quote
I don't want to bitch on Windows here (even if I'm more of a Unix guy, I'm actually writting this from a W2k system), but I have the impression that "Windows-guys" think about new releases as of "Yeah! Features! Features!" and personally I don't like this.


I'm sorry, but you are mistaken here.  This isn't about "Windows users" (to coin a negative phrase),


It wasn't my intend to coind a negative phrase. It was just an observation that users of Windows are more forgiving to bugs. If there's a blue screen in Windows, most of the users sit there, watch how it reboots. Sometimes the say some bad words, but most of the time they just accept it. They don't seem to care. And if there's an update of a program or Windows itself, they don't ask how much bugs got fixed, they ask how many new features the new software has. They don't care how many security bugs the software has. Can you tell me how many published security holes -- which are unfixed -- still reside in your software? I'm able to do this for my software... at least for the Open Source one, I can't do it for my Windows software, because there are too much published holes. But at least I can make sure that those holes don't affect me (either by using programs on Windows, which don't have published holes (I don't use Windows much, so this isn't a problem for me), or by using my Unix software). There aren't many Windows users which know the actual security status of their system. Even most of the network administrators don't know it. And if there's some kind of new workm or virus, they bitch at the writters of those worms. I don't want to glorify worm or virus writters, I'm just talking about people which react in a wrong direction. Uhm... I'm getting of topic here, sorry.


Yes, way off topic.  Security holes in Windows and the average Windows user (which you seem to assume incorrectly that I am... I'll have you know that I also use Linux and BSD quite frequently on many of my machines, and quite often Linux is my main operating system) really has nothing to do with LAME at all.

Quote
I wanted only to make a distinction of two user groups. You can find both kinds of user groups on Windows and on Unix systems. But you can find one group more often on unix systems and the other group more often on Windows systems. As every generalization this one also doesn't work in every case. I apologize if I have insulted anyone, this wasn't intended.


I understand your point, but you are making the wrong point for the situation.  This isn't about users screaming for more features, it's about users asking for improved quality between releases, and at the very least stable quality.  Everyone likes bug fixes but they want assuredly stable quality as well.

You could actually use this as an analogy in a situation you might be more inclined to understand.  For example, if it were discovered that a particular kernel revision in your favorite Linux or BSD had a particularly bad bug, and a fix was found, but when implemented the fix also caused stability problems in many other areas because of other bugs, do you think that the developers would go ahead and release anyway?  I don't think so.  They'd fix the whole thing at once.

The same thing should go for LAME.  So you fixed some bugs which happened to break other things.  You should make absolutely certain then that the other things which you have broken are functioning correctly before you release again.  This shouldn't just be based on assumptions either... like "well it should be OK judging by how the code looks", etc.

Quote
Quote

People want to see tangible improvements from LAME and they want to make sure that successive releases do not regress in terms of quality.  They are more worried about this than portability bug fixes.


Feel free to come up with a formal and mostly automated setup to test for it. I'm not asking about a program which makes the decission "good" or "not good". Just come up with a set of samples, an automated procedure to generate MP3s out of those samples, compare them with the last official set of MP3s, and if they differ print out the files in question and a description about already found flaws in older versions of LAME, so the tester can make sure every one of those flaws doesn't exist in the new MP3 (we have already a framework for this in the CVS tree, you just have to provide samples, a description, and a set of lame command line switches for these samples!).


First of all, I have to ask why I have to do this.  Why can't the rest of the developers do this sort of thing?  Why don't they do this every time they make a change to the code which affects output?

Secondly, I'm skeptical about whether or not providing this information in this format is going to get things addressed.  For quite a long time, JohnV, myself, and many others have provided very explicit and detailed information about samples which still cause problems with LAME.  Until Takehiro's recent work, none of this stuff has been addressed at all.  How can I be certain that going through the trouble of doing all this is going to change anything?

And third, if there is actually a system in place to do this sort of testing and reporting, how come nobody has ever heard of it before?!

Quote
Quote

More on this...

Quote
I don't need features which aren't usable because of bugs (either because they aren't really tested or because the management decided to make a release). I don't want to make a "Features"-release, I want to make a solid-release.


And I want to see a truly improved release, not simply a "it works on more non-mainstream OS's but the quality might suffer across the board because it hasn't been properly tested" release.


The lame developers identified some deficits in the actual code (fast preset). And they feel comfortable with the rest of the code. Every developer makes listening tests before he commits changes which may affect the quality. We don't have a formal regression test suite, so we can't catch every possible flaw, but me make sure the quality is a s good as we are able to test it.


Then I think that we need to make such a test suite.  At the level of quality of the current alt-presets, and with the amount of room they have to improve before a higher degree of transparency can be acheived, it is very important to have some sort of stricter controls over whether things are actually improving or not.

Quote
So please don't spread the FUD further and come up with examples where the actual code fails. I commited no code which affects quality, so I don't feel attacked by your sentence, but I don't think those developers which change the low level MP3 code deserve such sentences. Feel free to have a look at the archives and at the commit logs to see how hard they worked in their free time.


LOL....

You mean come up with all the examples I have in the past?  Well all you have to do is dredge the email archives of most of the prominent LAME developers or read early threads on this board or r3mix.net.  Or read many of the comments I made to the mailing list int he past, etc, etc.

The fact that you aren't aware of which samples LAME fails on only shows that you haven't been paying attention in the first place.

And as for your comment about how developers feel attacked by me and how hard they have worked in their free time, well I don't feel threatened by that either.  I've worked closely with many of the developers concerned with quality in the past.  I have done very significant amounts of work to try and improve the general level of quality provided by LAME -- literally months of time performing listening tests and retuning, over, and over.  I even learned the important parts of the LAME source for affecting quality.. all with little to know programming experience beforehand.  I have spent vast amounts of my free time and money to raise awareness of quality in audio encoding online, with LAME in particular.  You speak to me as if I have no right to question the work of others because I haven't done anything myself.  Well, if that's what you truly believe, it's time to wake up Alexander.  It's pretty obvious that you're badly out of touch with the high quality encoding community and their views (or efforts to improve) of LAME.  This, I believe, is the root of the problem, because it's not just you.  The LAME development team as a collective (and again, I have very much respect for certain individuals on this team) are out of touch and unaware.  This is bad... it's certainly not how things are handled with AAC, Ogg Vorbis, or MPC.  It's no surprise that they continue to improve then, while LAME stagnates and possibly regresses.  And the worst part of it is that the work from the people truly commented to providing vast improvements (Naoki, Takehiro, Robert, and I believe in the past probably even Frank), are largely ignored.  Nspsytune for example has never been defaulted.... why not?  And now it looks like Takehiro's code may never even be added to the mainline.  Heh..

Quote
Quote

I'm not making a fuss about features, I'm making a fuss over the fact that 3.93 was about to be released with known bugs in the --alt-presets (which few of the core LAME developers seemed to


You are seeding FUD. I asked on lame-dev if there are some unresolved things to do before we can release 3.93. Gabriel answered he wants to do some updates to the html docs and perhaps wants to add an additional preset. And he said he is fine with a release over the weekend. I answered I don't want to rush the release and we should wait at least for a week (I know there are developers which don't have the time to read mails on lame-dev every day, so I wanted to give them some time to answer).


No, I'm trying to raise awareness of the problems with LAME in a hope that they will be addressed and that the developers will take many of these issues more seriously.

Now I'm being attacked for my efforts.  It's quite fitting really...

I remember similar things happening with my 3.90.2 release, and that's exactly why I unsubscribed from the LAME-dev list and stopped working on LAME for such a long period.


Quote
Quote

Quote
The code of 3.92 can't be that bad , it's in widespread use. So why not release a bugfixed version of 3.92 (namely: the actual code in the HEAD CVS branch as 3.93) and make a known good release even better.


Yes, but 3.93 isn't the same as 3.92.  There have been many small changes.  Are you sure that nothing except for the fast presets has been degraded in quality?  I'm not.


Feel free to prove it by providing examples where the actual code performs not as good as 3.92. If you decide to try to prove it, please drop me a note, I'm willing to delay the release until you find an example or until you give up.


See my above comments on this..


Quote
Quote

Quote
Think about 3.93 as a bugfix release, not of a release with new features (even if we have them). And remember, I'm fine with making a 3.94beta with every feature/change you can come up with at the same day.


Sure, but I'm not convinced that 3.93 is as "stable" or as "clean" as you seem to believe.  I don't want to see a release made which is going to degrade the --alt-presets which so many people rely on to provide them with very solid quality.


I have been told the fast preset has only an increased bitrate, not degraded quality in the resulting MP3. Is this wrong?


I don't know.  I was only made aware of this a short time ago, and I haven't had a chance to do rigorous testing.

Have you?

Quote
Quote

I would also in the future like to see that any "fixes" which are made to the code which break these presets (which should be seen as the "stable" and "proven" aspects of LAME quality) be reworked in a manner which either do not break the presets, or that the person who breaks the presets also makes every effort to unbreak them as well.  Otherwise we end up with this sort of situation...


I'm fine with this. I'm anoxious to look at the regression test suite you can come up with. If you need some asistance in setting up the framework from the CVS repository (have a look at the test directory) or if you need some features in the framework, feel free to drop me a note.


Given the nature of this discussion, I'm not sure I can see much point in spending the effort required to do this.  My testing and time spent on LAME in the past speaks for itself in regards to my willingness to help improve things, but I'm not going to spend that time wastefully either.  I believe this conversation has convinced me that further work on LAME in the current paradigm would be wasted -- the current system is broken and there appears to be little interest in improving it internally by those in control.  Rest assured that I do still have plans to work on improving the presets as they exist now, and in the manner in which I have proposed future changes as well, but I believe that this will be done outside of LAME and in a much more organized and controlled manner and in collaboration with individuals who clearly have more of a concern for the issues which I outlined.

I really have nothing else to say on this topic.  I do want to mention that I appreciate your coming here to discuss these issues even if a pleasant resolution was not reached.  Maybe you'll choose to stick around here, maybe not.  Good luck on your 3.93 release

Plans For --alt-presets, Etc, In Lame 3.93

Reply #53
I just want to say...i hear you...nothing more to say, you've said it all..

Quote
I even learned the important parts of the LAME source for affecting quality.. all with little to know programming experience beforehand. I have spent vast amounts of my free time and money to raise awareness of quality in audio encoding online, with LAME in particular. You speak to me as if I have no right to question the work of others because I haven't done anything myself. Well, if that's what you truly believe, it's time to wake up Alexander. It's pretty obvious that you're badly out of touch with the high quality encoding community and their views (or efforts to improve) of LAME. This, I believe, is the root of the problem, because it's not just you. The LAME development team as a collective (and again, I have very much respect for certain individuals on this team) are out of touch and unaware. This is bad... it's certainly not how things are handled with AAC, Ogg Vorbis, or MPC. It's no surprise that they continue to improve then, while LAME stagnates and possibly regresses. And the worst part of it is that the work from the people truly commented to providing vast improvements (Naoki, Takehiro, Robert, and I believe in the past probably even Frank), are largely ignored. Nspsytune for example has never been defaulted.... why not? And now it looks like Takehiro's code may never even be added to the mainline. Heh..

....

No, I'm trying to raise awareness of the problems with LAME in a hope that they will be addressed and that the developers will take many of these issues more seriously.

Now I'm being attacked for my efforts. It's quite fitting really...

I remember similar things happening with my 3.90.2 release, and that's exactly why I unsubscribed from the LAME-dev list and stopped working on LAME for such a long period.

....

I believe this conversation has convinced me that further work on LAME in the current paradigm would be wasted -- the current system is broken and there appears to be little interest in improving it internally by those in control. Rest assured that I do still have plans to work on improving the presets as they exist now, and in the manner in which I have proposed future changes as well, but I believe that this will be done outside of LAME and in a much more organized and controlled manner and in collaboration with individuals who clearly have more of a concern for the issues which I outlined.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #54
Dibrom:

Quote
Rest assured that I do still have plans to work on improving the presets as they exist now, and in the manner in which I have proposed future changes as well, but I believe that this will be done outside of LAME and in a much more organized and controlled manner and in collaboration with individuals who clearly have more of a concern for the issues which I outlined.


Does this mean that your plans to fork LAME may become reality after all?

And forgive me for the comment I made above.  I took Alexander's statement that the quality wouldn't degrade for granted and had no idea he was so lousily educated about the situation.

CU

Dominic

Plans For --alt-presets, Etc, In Lame 3.93

Reply #55
There is no spoon... but I hope there is a fork.
No, I am Jack's complete lack of surprise.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #56
Dibrom,

First off, please don't take any of this negatively. I respect your work on LAME, and I appreciate your bringing quality concerns into the forefront. But...

I understand that team playing is sometimes tough. I know it's even more so in the wild field of open source. One may perceive "contributing" as wasteful pain, while "forking" may appear as an easier way out. The question needs be asked, however, which avenue better serves the audio encoding community at large - HA and beyond. In my opinion, your 3.90.2 split didn't serve it well. And I don't see a full fork faring any better.

Your call, of course, mine is just an outsider's 2c...

Plans For --alt-presets, Etc, In Lame 3.93

Reply #57
Dxiv (and others), I also ask you to please not take this wrong:

I think Dibrom should consider forking Lame.  Having watched development for awhile... I see only a few really significant contributors remaining, Dibrom being one of the few.  I think those who (still) really care about Lame should go ahead & fork it, rather than submit to the overall *glacial* pace of development that seems to have taken over since last year.  If not, I think by the end of 2003 Lame will be at version 3.94 (with a 3.95 alpha in the works) and just a few things shuffled around in the code.  That is, if anyone still cares at all about Lame by then.

Just my opinion, it means nothing (and is subject to change) but thought I'd say something anyway.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #58
I have been reading this thread with much attention, and I feel sad about the outcome. This leads me to be unable to remain silent, even though I have clearly no authority whatsoever. I just wouldn't forgive myself if I don't do something about this. So here are my two (euro)cents.

Facts (in no particular order):
- We are ALL the good guys. We ALL want to improve LAME. Some in speed, some in quality, but every improvement is possitive, and leads to make LAME the be-all end-all MP3 encoder. And free. And OPEN SOURCE, important detail.

- Dibrom wants to work on Takehiro's branch. He wnats it badly. Not surprising if you look at the list of added features and their potential. Who wouldn't?

- Takehiro has made clear he doesn't believe his code to be ready for prime time yet. Woe for all of us, we have to wait.

- The main branch code has been changed in some way that has affected the "--alt-preset fast" performance in some way. There is clearly a need to solve this bug.

- The LAME development team has always had some internal communication means (mailing lists) that are to be used for coordination of the efforts, and keeping track of the changes.

- Nevertheless, HA forum has several LAME developers communicating through it, as well as getting feedback from the rest of (very knowledgeable) users. A useful source of information indeed.

From all the said above, I can infer the following:

- Alexander Leidinger has shown interest in finding a solution to the situation by coming around to HA. That shows possitive attitude. He has also shown willingness to postpone the release to clear out the "--alt-preset fast" bug. After all, he could have just discussed this inside the OFFICIAL LAME mailing lists, and that would have meant avoiding unpleasant confrontation...

- Since Takehiro doesn't think it's the right time to merge his branch into the main branch, it's clearly NOT going to happen.

- The bug in "--alt-preset fast" can be solved in two ways: merging Takehiro's branch and so ditching the problematic code with all the rest of the code that surrounds it (since we don't know the exact location), or the traditional way to solve bugs: finding it and fixing it. Since option A is discarded, and LAME's main branch should NOT have this bug, option B needs to be applied.

- Pinpointing the bug in the main branch needs listening tests. Many of them.

- We need to find out how this bug was detected. Are the traditional problematic samples able to show it? I have high hopes that they are. We probably don't need to look any further.

My personal suggestions for the future, considering all I have said above:

@ALeidinger:
HydrogenAudio is a very valuable resource for QA testers. Please use it to improve the situation with QA testing in LAME. Give these users a clearly useful goal, and you will get ABX tests for anything you need.
Also, please use HA to discuss any topics you wish. Please don't let this source of useful information be wasted.

@Dibrom:
LAME is open. You can work on any area you choose to. There is nothing stopping you from taking Takehiro's code and working on it. And releasing your own experimental versions. And with your work, I have no doubt that his branch will reach "prime time status" a lot faster. Please go ahead and do so. Regarding the problem with the "--alt-presets fast" bug, a way to solve it without deterring you from working on Takehiro's code as much as you wish can be found.
I can't help mentioning I believe that since you are so deeply involved with LAME development, rejoining the mailing lists would be a good idea, even if just in digest format, as Gabriel mentioned. HydrogenAudio is not meant to substitute them.

@all LAME developers:
Please don't lose your collaboration spirit. The work so far has been really impressive. And we all want to see it going on. Don't forget your goals are essentially the same: creating the best, free, open MP3 encoder. If the code gets branched, the community will still benefit from your work, because it will remain free and open, be it called LAME or anything else. But if you don't collaborate, your work will be slowed down, and will benefit less from each other's contribution. Any contribution is better than none.

Final words:
Whatever may happen, thanks all of you for your hard work, with total honesty. Whatever the end of this is, my ears and my music library owe you all a lot.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #59
My own opinion:

I am not a major contributor to Lame, but more a "peripheral" developper. I did not contributed major parts, but only some small ones. I do this since 3.01. It means that I spent a lot of time bringing some little bricks to construct Lame.
I perhaps (this is an hypothesys) do not focus engough on quality, that is true. My main goal is to do something I like, ie learning.

During those years of contribution to Lame, I learned a lot. I learned a lot because of the work I did, and also by looking at work done by other people.
My changes are small, yes. This is because I have a familly, a job, a life in the "real world" outside of computers.
For all of us, it is the same situation. Lame is not a business, it is a hobby. So yes, Lame is only slowly evolving. We can not do faster, but we are still doing it. Still only 3.92? So what? What is the current version number of the Linux kernel?

Perhaps it is not a fast development, but there is development. Perhaps it is not always evolving in the direction one or another one would like, but overall it is evolving, slowly bringing more satisfaction to more users.
The situation is the same for a lot of software. Everyday I am using software written by other, because they were kind enough to make efforts to create software that is working under other platforms that the one they are using.
For Lame, it is the same thing. We are making efforts so that more users can  benefit from it. Yes, some users are using some unhabitual platforms. But would you tell this user:
"No, I am not interested in supporting your platform because I am not using it, and it is only not even 1 percent of market share. You should get an x86 processor with a mainstream operating system instead of your current computer."
Do you really imagine telling this to this guy that is at the same time writting software on his platform and making efforts so that you will also be able to use his software? I would not.

I also think that Lame has not strong leadership defining direction. But I like this. Lame is driven by a consensus. In this consensus, everyone has to accept compromises. If the situation would have been different, it is very likely that there would have been less contributors (have you seen the incredibely huge list of contributors in the html docs?), and so Lame would have not reached its current status. It would be similar to Blade, nothing else.
Yes, several time I accepted decisions that I disaproved at first. But other people did the same in return, and so we are peacefully cohabiting.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #60
I just want to give an update on this situation.

I don't know what is going on with the mainline LAME or whether or not the developers are planning on releasing 3.93 or what.  However, I have been in contact with Takehiro and have decided that, at least for all immediate future purposes, I will continue to work on LAME with him directly.

I don't think I will fork lame per se, but I will probably make special releases out of his code every so often. These will be the only releases recommended for use via HA since they will also be the only ones tested properly.  Of course, any modified source code will be provided as well to be in accordance with the GPL/LGPL.

I've kind of come to the decision that LAME as it stands right now is just not suitable for for usage by end users.  It doesn't have enough quality control, and (as before) there is not enough emphasis placed on providing a solid, polished, and end result type product.  Development and improvements are made in a slapped together, haphazard manner and there is very poor communication, coordination, and overall organization within the development ranks.  If this situation changes, then I'll be happy to work within the traditional LAME framework again, but right now I don't see this happening.  There doesn't seem to be any internal desire to change the process, and I'm not going to try and spearhead this effort again.  I just don't have enough time to argue about it anymore.

Takehiro has informed me that his experimental branch will be ready for an initial release (once tested) very shortly.  Although he has many changes left to implement before he is "done" for good, he is only going to be adding (or finalizing rather) one more feature before we can go back and make sure everything is stabilized for an initial release.  I won't be posting any more builds until then, but I expect that it won't be too long from what he told me... maybe a week or so at most.

Once this point is reached, I'll package his branch into a release of some sort and post it here for in depth testing.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #61
@Gabriel:

The problem (at least mine) is not that LAME is developing slowly, it's that it's not developing in any sort of rational or organized direction, and that development is so chaotic or haphazard that there's even no guarantees that one version will clearly be better than the next.  There's no proper testing, etc.

You can't develop a high quality audio encoder properly like this.  Yes, you can say that LAME is high quality, but if you compare LAME (without the --alt-presets but instead with standard command lines) to any of the current state-of-the-art audio encoders, LAME is really not high quality at all....

If you look at the development process of any of the other popular high quality audio encoders people are using, the process is vastly different.. and it's for the better.

Quote
I also think that Lame has not strong leadership defining direction. But I like this.


This is a very fundamental problem.  If you and the rest of the developers actually prefer this approach, it's no surprise that we disagree so strongly.  It's also no surprise that the development process takes place the way it does now..

Quote
Lame is driven by a consensus.


Is it?  I thought that's what this was about.  If LAME is driven by consensus, then how come so many of the --alt-preset bugs had not been addressed by the developers?  How come many of the bugs which the --alt-presets addressed themselves were not addressed by the developers?

I don't think LAME is driven by consesus, it's driven by whatever grabs the fancy of the particular developer hacking on the code at that very instant, and it may not be related to other ongoing development, what the users are asking for, or anything else.

This isn't being driven by consesus, it's being driven by arbitrary whims uninfluenced by the desires of the majority...

Plans For --alt-presets, Etc, In Lame 3.93

Reply #62
Dibrom, I think they take this as a hobby if it’s too organized they may think it might get stressful & less fun so they would soon lose interest. Sure if there was an organized direction things would go better & faster but can it keep the developers interested? & who would lead this?.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #63
Quote
Dibrom, I think they take this as a hobby if it’s too organized they may think it might get stressful & less fun so they would soon lose interest. Sure if there was an organized direction things would go better & faster but can it keep the developers interested?


Perhaps the current developers would lose interest, but if things were better organized, there'd probably be other interested people to come and take the place of those that no longer care.

If you take any large scale open source project, you see that they only succeed when there is strong leadership and organization.  Most of the very large open source projects are also worked on by people who consider them to be hobbies (Linux, KDE, Gnome, etc), but (at least for the most part) you see much more coherence in those projects than in something like LAME.  Hell, you can even look at Vorbis for an example of much better organization in an open source project and one that is actually more directly comparable to LAME and it's goals.

Quote
& who would lead this?.


Good question.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #64
@ Dibrom:

Shut up.

Shutup shutup shutup.

(DAMN that felt good.)

The sky is blue.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #65
Quote
@ Dibrom:

Shut up.

Shutup shutup shutup.

(DAMN that felt good.)


Why?, because he wants to improve productivity?, you should be saying;

Speak up.

Speakup, speakup, speakup.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #66
Quote
@ Dibrom:

Shut up.

Shutup shutup shutup.

(DAMN that felt good.)


Hahaha good call.

(sorry Dibrom)

Plans For --alt-presets, Etc, In Lame 3.93

Reply #67
Dibrom, I'd just like to say that I think your points are valid and well thought-out.  I've come to respect your judgement over time and understand what you're trying to accomplish.  I'm surprised that people are telling you to shut up when you are one of the most rational posters on these forums.  Keep up the good work...

Plans For --alt-presets, Etc, In Lame 3.93

Reply #68
Well, of course KDE, Kernel, OpenOffice, Mozilla, and other big projects are more organized. Yes, Vorbis also.

But we can wonder why are they more organized? The answer is simple: there are people working full time on those ones. So obviously there is time for organization.

MusePack and Psytel AAC are more organized? Yes of course. This is because they are mainly developped by a single developper. So with only 1 main developper, this developper is obviously organized with himself.

It seems to me that the situation with Lame is quite different: it is not the toy of a single man, and no one is working full time on it.

We would be happy to have someone working full time on it in order to have more organisation, more audio testing (although it would not provide more portability testing), but unfortunately this is not the case.

If you want to work exclusively on Takehiro's branch, that is perfectly fine.

Btw I have a suggestion:
As Takehiro's branch can not be used for a release, and as we need to have a release in order to have Lame working on some platforms, why not doing the following:
Tag 3.93 as beeing release, but do not release it. During the same time, Dibrom would work on Takehiro's branch. In 2-3 weeks, when Takehiro's branch will be usable as a beta, we will merge it with the main, in order to have 3.94 beta.
And the final thing: the same day, we release both 3.93 stable and 3.94 beta.
This way well have both portability and quality improvments.

(you can notice that I am trying to do my best to accomodate everyone)

Plans For --alt-presets, Etc, In Lame 3.93

Reply #69
Ps for some posters: In this thread we are gently discussing. Please do not pollute this thread with unconstructive posts.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #70
Quote
I don't think I will fork lame per se, but I will probably make special releases out of his code every so often. These will be the only releases recommended for use via HA since they will also be the only ones tested properly. Of course, any modified source code will be provided as well to be in accordance with the GPL/LGPL.

Thanks Dibrom, this seems to be The Right Thing™ to do. I'm looking forward to your releases.

Quote
Dibrom, I'd just like to say that I think your points are valid and well thought-out. I've come to respect your judgement over time and understand what you're trying to accomplish. I'm surprised that people are telling you to shut up when you are one of the most rational posters on these forums. Keep up the good work...

I totally agree.
Over thinking, over analyzing separates the body from the mind.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #71
Quote
Ps for some posters: In this thread we are gently discussing. Please do not pollute this thread with unconstructive posts.

I think it would be trolling, just gets people mad & side tracked.

Plans For --alt-presets, Etc, In Lame 3.93

Reply #72
Quote
@ Dibrom:

Shut up.

Shutup shutup shutup.

(DAMN that felt good.)


OK sorry to mention this post again, but i have to since it got me 99.6% mad.

This is the lowest of the lowest things to do.
I wonder  what makes you angry, i suppose it's the fact that he's so right and that he spends much time answering what concerns him fully and extensively, thus making his thoughts and opinions as clear as possible.

Sorry, i'm not flaming or anything, i just want to make it known that now this, makes me SICK...

Plans For --alt-presets, Etc, In Lame 3.93

Reply #73
This is the mail I wrote to LAME-DEV@sf.net with some modification (correct spell miss and so on). I believe LAME-DEV is the best place to descuss on. This is just in case you do not join in.

----
I just made a new branch, "takehiro-stable-2002_10_15", forked from
my experimental branch. I think current status of this branch is
pretty stable and has better quality than the mainline (at least for
me), and all the patches in the mainline branch are applied.

Once I said "my branch is not ready for merging", on HA. But with all
the holidays in this weekend (in Japan, there are three consecutive
holidays:p), I cleaned up and checked my branch, to make it more
stable, rather than adding new functionality.

And my work result in this branch.

>>>>> "G" == Gabriel Bouvigne writes:

    G> However, Takehiro's branch is hanlding fast presets a little
    G> better than the main branch. So this would be extra work to fix
    G> fast presets in the main branch, and this would be a "waste" if
    G> we merge Takehiro's branch just after.

Yes, I agree.

    G> So my suggestions is:
    G> *merge Takehiro's branch now
    G> *focus on fixing current presets
    G> *focus on a release aroun nov, 15th

I am so lazy to read the whole of discussion on HA, but I propose
replace main branch with this branch. Yes, "REPLACE" it.

I wonder how many people attempt to join the merge process. Once I
mailed the 4 psymodel patches, one of which contained bug. No one
noticed it, and I desperated the LAME-dev.

Moreover, the way to "MERGE" is too heavy task, making many patches
from big diff is not easy and tend to make a bug.

So the "MERGE" is only wasting time. I prefer "REPLACE".

Any comments ?
-----
PS.
To Dibrom, JohnV: If you want to make "unofficial" LAME with preset-tuned version, I believe this branch(takehiro-stable-2002_10_15) will be the most suitable start point.
May the source be with you! // Takehiro TOMINAGA

Plans For --alt-presets, Etc, In Lame 3.93

Reply #74
i would be interested how the latest developments come out! Maybe dibrom or john33 could make an ICL /nasm build to play with