It appears that a 3.93 release is fairly close now, but I think the following things need to happen before everyone decides that it is the appropriate time to do so:
1. Takehiro's code and fixes need to be merged, at least enabled on the --alt-presets. I plan on using his --substep code, and also he apparently made some significant fixes to pre-echo handling in the --alt-presets. These need to be in the next version.
2. I will use the --substep code in addition to other tweaks to create 2 more presets to provide lower bitrate alternatives to --alt-preset standard.
3. Some information in the --alt-preset help should be clarified.
4. Listening tests need to take place to verify that no samples have been degraded so far.
5. Tests of all original samples need to take place to pinpoint improvements and to find out where there are still problems.
6. With this data, maybe some more tuning can take place.
7. Retest remaining problem samples.
8. Shoot for a release.
I might have missed some stuff there, but I can't think of it atm.
I've just downloaded Takehiro's latest code and the current standard 3.93 from CVS, and plan to spend time this week and this weekend implementing these new presets and testing for quality. I'll probably be posting some builds here very soon (maybe tomorrow) and I hope that people can report their results to me. The new presets will be a bit experimental at first, so the more help testing, the better.
I'm not exactly sure how long this testing process will take, but I think it's important to have all of this stuff in place before another release is made.
Comments?
Seems that the only real progress would be coming from Takehiro or from Takehiro's branch. It would be useless and stupid to release 3.93 without taking advantage of Takehiro's development.
Otherwise 3.93 will be just another trivial release which probably just makes things worse by breaking some --alt-preset modes which are now widely used and recommended in the net.
I hope that Takehiro's sub-step noiseshaping and changed/tuned attackthreshold for --alt-presets etc. are incorporated.
Also I'd like to know if the following fixes are in the main branch or not (they should be):
1. psymodel debug: nspsymodel initilization fix
2. pre-echo detection code fix for ns/gpsycho(for not vbr case)
3. DC current estimation fix
4. nspsytune long/short switching fix,
5. noise shaping debug: infamous -Z problem.
6. bit allocation debug: bit allocation for short block of monoural fix.
Some of them are as far as I know, but are they all?
Imo 3.93 shouldn't be just another trivial release which actually breakes --alt-preset fast, when there's potential for so much more. I hope also other Lame developers than only Takehiro can see this too.....
Lame 3.93 should go into beta state, the tweaking and testing should be done properly and after that the 3.93 stable could be released.
did anyone contact mark taylor or another developer who is responsible for the release ? You mentioned very important points the developers should really think about!!
The problem with Lame development is that nobody really seems to be in charge..
I'm sure Gaby,Robert and Tak read this though, and I hope other developers like Alexander Leidinger and M. Taylor will be informed about this...
Actually I'm counting on the three developers I mentioned first, that they would do something about it, so that Lame 3.93, when it's released, wouldn't be another trivial release, like Lame 3.92 pretty much was...
We are ready to help by doing listening tests etc. I just downloaded Tak's branch latest compile.
As an end user, I'm all for the idea of holding back LAME 3.93's official release until it has been tested to the degree that Dibrom and JohnV have suggested.
It's good to know efforts are being made for 3.93 to be a useful upgrade rather than a rubber-stamped bug-fix, and shall be very grateful for a 'medium' preset for recording from D-Sat radio. Can I ask if the -Y switch will still serve as a lowpass filter in 3.93 ?
ß
Alexander is (unofficially) in charge of the release process, as Mark do not seem to have any more time for Lame.
I personnaly prefer releasing often (if it does not break anything) than waiting a huge time in order to have a lot of changes. This way, the release process is easier.
I understand that you would like some substancial improvments for a new release.
I have a question: do you think the current 3.93 released as beta would be a dowgrade from 3.92? If no, then it means that it could be released as beta (could be, I didn't mentionned should be).
The plan was to release 3.93, then after this release merging Takehiro's branch into main branch.
I understand your point, but you need to also understand that what could appears as a "trivial" release is not a bad point, specially when a program need to be able to run under a whole range of different operatin systems.
How about voting over it, to see what users want?
... I think Dibrom's and JohnV's suggestions are very right.
It will be a great senseless waste to release a new 3.93 version that doesn't include those VERY important additions/modifications.
I don't think any voting is needed.
Looks like quite a lot changes to me (compared to 3.90 -> 3.91 -> 3.92), so I'd go with 3.93BETA, see hwo it performs for say one or two month and than move over to 3.93.
dev0
I personnaly prefer releasing often (if it does not break anything) than waiting a huge time in order to have a lot of changes. This way, the release process is easier.
I don't really see the point in making a release just for the sake of having a new release in X amount of time. Releases should be dictated by the merit of their improvements otherwise it's just arbitrary and could easily cause
more problems than it fixes.
I have a question: do you think the current 3.93 released as beta would be a dowgrade from 3.92? If no, then it means that it could be released as beta (could be, I didn't mentionned should be).
The plan was to release 3.93, then after this release merging Takehiro's branch into main branch.
I don't know, but the fact that you apparently are not sure either (since you asked) should be reason enough
not to release now. The point is that changes were made which could have an effect on the quality of what are some of the most widely used settings -- settings which people count on to be as good as possible and to have been tested properly.
Making a release without proper testing would be very irresponsible IMO. LAME has traditionally suffered very poor QA, let's not continue the trend if possible.
I understand your point, but you need to also understand that what could appears as a "trivial" release is not a bad point, specially when a program need to be able to run under a whole range of different operatin systems.
It's a bad point if it is simply arbitrary, and it's doubly bad if it's arbitrary
and untested. As I said before, it's just irresponsible really.
I don't understand what you mean about "when a program need to be able to run under a whole range of different operating systems." Does 3.92 have some major problems preventing it from running on most major operating systems?
The only thing I see in the changelog so far are portability fixes for Tru64 Unix and SunOS 4.x. How many people are those fixes going to affect vs how many people poor quality testing could affect?
Oh, and one last thing, if Alexander is the release manager now, maybe you could ask him to come by here sometime. A lot of the most hardcore (and concerned and active) users of LAME frequent this board. It'd be helpful for him participate in some of their discussions I think
I would tell him myself, but I unsubscribed from the list some time ago...
Why don't take in consideration a new/better lowpass filter
in future versions of Lame?
Maybe Similar to the Cool Edit Pro's lowpass filter?
Gabriel:
Have you been testing the --alt-preset medium you have come up with for quality? If it's going to be in 3.93, and if 3.93 is going to be released without all of these other changes I mentioned, have you at least made sure that this preset will live up to expectations?
If not, you might want to consider putting a disclaimer on it that it hasn't been tested... after all, the help for the --alt-presets even says that they are the most tested and highest quality settings available for LAME. Including a largely haphazard and untested preset (if that is so, I don't know which tests you have done) will probably do more harm than good.
Btw, I'm going to try and upload a test version of Takehiro's branch with 2 more alt-presets today for people to test..
As an end user, just wanted to say thanks to all the developers.
I am REALLY looking forward to a 'lower bit rate' alt preset. While the -Y switch is cool (no quality reduction that I can hear), the file sizes are still too big (about 180 avg) for portability use. An optimized VBR setting to take that number down to the 140-150 range will be awesome!
Ok... here (http://static.hydrogenaudio.org/extra/LAME/dm-lame.zip)'s the binary, as promised:
The following new presets have been added:
--alt-preset dm-medium
--alt-preset portable
--alt-preset dm-radio
The dm parts are in there so they aren't confused with current presets. Naming is just temporary. The presets are in order of quality from highest with medium to lowest with radio. I haven't done any sort of extensive testing yet, only a little bit to make sure things were working at all.
What I need people to do is download this binary and test it. Bitrates for the various presets across many albums or something like that would be very helpful. Same thing goes for quality. While these presets probably wont be transparent, I'd still like to know about quality issues, especially if there's a really harsh artifact you're hearing.
What I'm trying to shoot for bitrate wise is:
180kbps
160kbps
140kbps
for the respective presets. This will probably take some more tuning, so that's why bitrate information would be great. Also, test --alt-preset standard against 3.90.2 or 3.92 if you could. That would be good as well. If there were samples you had where 3.92 had problems before, they might be fixed now.
The 180kbps preset should be higher quality than --r3mix without question. I'm shooting for the 160kbps one to be also, and maybe the 140kbps one as well. If you'd like to compare these presets that would be fine.
Oh, and there's no fast modes for any of the new presets right now. If I have time, I'll try to add these later, but no promises. I tried initially to do this but ran into some problems and didn't have time to figure out what the cause was.
Just a small update... the .dll is needed by this compile because I had to build it using cygwin. This also means the compile is painfully slow.. heh. I'm going to try and post an ICL compile tomorrow, along with the modified sources.
Also, there's a few things I forgot to do in my modifications which should be able to further reduce the bitrate on the lower presets without impacting quality too much...
Hi, I noticed that --r3mix is still in LAME (or at least in --longhelp). Have we thought about disabling it and popping up a message to use preset standard or preset medium instead. I remember this being suggested early this summer but people objected because r3mix produces smaller files than preset standard but now that there are more options maybe this will make that argument invalid and we can encourage people to step up to a higher quality MP3.
Just a thought, in the end it pretty much has no effect on me but hopefully helps others.
Hi, I noticed that --r3mix is still in LAME (or at least in --longhelp). Have we thought about disabling it and popping up a message to use preset standard or preset medium instead. I remember this being suggested early this summer but people objected because r3mix produces smaller files than preset standard but now that there are more options maybe this will make that argument invalid and we can encourage people to step up to a higher quality MP3.
Just a thought, in the end it pretty much has no effect on me but hopefully helps others.
I pretty much agree with this idea. I think once tuning of the new presets is pretty solid, --r3mix should be either removed or aliased to one of the similar bitrate --alt-presets.
tak3lame.exe attempts to communicate with something (which my firewall detects). Why does it do this?
ff123
tak3lame.exe attempts to communicate with something (which my firewall detects). Why does it do this?
ff123
Hrmm...
Are you sure about this? Do you know what it was trying to communicate with? To my knowledge, this shouldn't happen. Maybe it's something in the cygwin.dll which your firewall doesn't like?
tak3lame.exe attempts to communicate with something (which my firewall detects). Why does it do this?
ff123
Hrmm...
Are you sure about this? Do you know what it was trying to communicate with? To my knowledge, this shouldn't happen. Maybe it's something in the cygwin.dll which your firewall doesn't like?
I can't track it down to what it's trying to talk to, but I verified that it does try (at least according to Conseal, my firewall). I also just scanned my system for viruses and spyware (I'm clean).
ff123
ff123:
Very strange. I don't know what to say.. it must be something with cygwin. I can't imagine it would be something malicious though. I'll be providing a non-cygwin compile tomorrow hopefully though, so it shouldn't be an issue then.
tak3lame.exe seems to use qval=3 as standard. Should I use presets with -h?
I've encoded one CD (Halford - Resurrection) with the various presets so far and here's how the average bitrates go:
--alt-preset dm-medium: 163 kbps
--alt-preset dm portable: 162 kbps
--alt-preset dm-radio: 149 kbps
--alt-preset standard 3.90.2: 223 kbps
Resurrection is a Metal CD, from 2000. For a track by track summary of bitrates, you can look at this page (http://www.apehaus.com/files/halford.html).
Dibrom, I think that you should subscribe to lame-dev and lame-cvs lists, at least in digest mode.
About the release date:
I would like you to understand that it is better to release more often with small changes, than releasing only once a year with major changes. In the second way, the release process is often harder due to portability problems.
That is why I am suggesting a compromise:
Let's try to focus on a release date around november 15th. This probably means less changes that what you were thinking about, in order to have less new features, but solid new features.
Do you agree on this proposal?
About --preset r3mix:
It is there for compatibility. I'd like to alias it to another preset when we'll have a preset similar in bitrate.
about --preset medium:
I used it on several albums, and I like the results (according to the produced bitrate). Of course it is not fully tested, and I was planning to not include it into the doc.
Preset names:
I think that a "radio" preset should perhaps focus on lower bitrates. That is not a big issue, but how would we call a proset focussing on 80-100kbps?
Takehiro's branch: if we agree on the 1 month delay, I think that we should merge Takehiro's branch into main.
Ok... here (http://static.hydrogenaudio.org/extra/LAME/dm-lame.zip)'s the binary, as promised
Before starting the process the program freezes the computer for a few seconds and then outputs the following error message:
LAME: Can't find termcap entry for terminal "cygwin". After that the encoding starts as usual.
I encoded three files (classical music). Most notably, in all three cases there was nearly no difference in file size between aps and medium (both with tak3lame), less than 1kbit/s. Medium was even larger by a few bits! I suppose this is caused by the lack of strong HF in the samples.
The first sample I listened to revealed a flaw in portable and radio:
3.92 ap 170 - 169 kbit
tak3 ap portable - 163 kbit
tak3 ap radio - 150 kbit
3.92 ap 150 - 148 kbit
While 170 is nearly transparent to me (maybe noise problems and slight pre-echo) and 150 has only minor noise problems, the tak3 presets produce a disturbing "rumble" in the background. Medium seems to fix this.
The sample is available in this thread (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=1&t=2619), the problem is most noticable at sec 5-6, just before the tenor comes in.
Would it be also possible to test the "--preset medium" that is in the current 3.93 alphas for comparison?
For information, mail exchange between Alexander and me:
> Gabriel Bouvigne wrote:
> > I am discussing if we should release now or wait a little more with people
> > on the Hydrogenaudio forum.
> > I will give you a summary of things discussed soon.
>
> I will try to have a look at the forum today.
>
> > Basically Dibrom would like to wait a lot more in order to have new
> > features, and I am trying to reach a consensus focusing on a release date
> > around nov, 15th, with less features in order to comply with this date.
>
> I'm thinking about a release as soon as possible and about another
> (beta) release soon after 3.93. Takehiro has a lot of work in his branch
> and we may want to merge it (depending on what Takehiro thinks about it)
> and make a beta release... What do you think about this?
I was also initially thinking about a release as soon as possible.
But Dibrom and Takehiro have some valid points: The current fast presets are a little broken.
This point can be considered as a stopping factor. (Without it I would have no doubt about a release now)
We would need to fix it before releasing.
However, Takehiro's branch is hanlding fast presets a little better than the main branch. So this would be extra work to fix fast presets in the main branch, and this would be a "waste" if we merge Takehiro's branch just after.
So my suggestions is:
*merge Takehiro's branch now
*focus on fixing current presets
*focus on a release aroun nov, 15th (1 extra month due to the merge of branchs and the need for testing)
If there is enough time, perhaps introduce new presets, but this would not be a priority.
(I am cc'ing this mail to lame-dev and HA forum)
Regards,
----
Gabriel Bouvigne
www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org (http://gabriel.mp3-tech.org)
Hi,
this is my first post here, so please forgive me if I made some mistakes and it doesn't look as good as it could.
Why I want to make a new release:
1) we have some bugfixes in the code:
This is beneficial for every user.
2) we have some bugfixes in the configure script for unix users
This is beneficial for every user of gcc 3.x and for some users
with commercial unix derivates.
I don't expect much users with a commercial unix here in the forum, and I don't know the Windows:Linux ratio here, but both doesn't matter. We have some users which may benefit from a new release so we should make a new release.
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), and we have some fixes, which make the previus release a little bit better. Even if I have some trust in the work Takehiro does, his code isn't as tested as the actual code is. 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).
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 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.
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.
So here's my proposal:
1) fix the preset fast issue in the actual code
2) make a 3.93 release
3) merge Takehiro's code
4) make a 3.94beta release (if we are able to merge the code in one day I absolutely have no problem to go public with 3.94beta one day after the 3.93 release)
5) fix bugs which may show up in 3.94beta
6) add other presets / improve existing presets
7) make a 3.94 release (or another beta)
This way we satisfy both kinds of users, those which like to have rock solid software, and those which don't mind a bug or two in bleeding edge software.
Quoting Dibrom:
I don't really see the point in making a release just for the sake of having a new release in X amount of time. Releases should be dictated by the merit of their improvements otherwise it's just arbitrary and could easily cause more problems than it fixes.
Yes, I want to make an improvement over 3.92. 3.92 is stable, so an imroved version has to be stable too. Therefore I don't think we should release 3.93 with Takehiro's code (it's not as tested as the actual one).
Making a release without proper testing would be very irresponsible IMO. LAME has traditionally suffered very poor QA, let's not continue the trend if possible.
Yes, please let's not continue... the actual code has a lot of (life) testing, there are mostly bugfixes compared to 3.92, whereas Takehiro's code has a lot of changes which don't have such a large testing as the actual code has, the actual code has a very large user base.
I don't understand what you mean about "when a program need to be able to run under a whole range of different operating systems." Does 3.92 have some major problems preventing it from running on most major operating systems?
I don't like the word "major" in your sentence. There's more than Windows (or Linux). 3.92 has some problems on some systems which are fixed in 3.93.
The only thing I see in the changelog so far are portability fixes for Tru64 Unix and SunOS 4.x. How many people are those fixes going to affect vs how many people poor quality testing could affect?
There are some changes which aren't in the official ChangeLog on the website, those changes are only listed in the CVS log (or in the file ChangeLog in the LAME tree).
There are some code fixes, which result in a problem with the preset fast setting, but thats only problem. Every new (not as much tested as the "old" code) code is in a new feature (e.g. substep noise shaping) and needs to get explicitely activated (I don't think about bad quality in those settings as a problem). So we have a very large portion of the code with a lot of field testing (because it's the same code as in 3.92). If there are quality problems in the new code, don't use it.
Quoting Gabriel:
However, Takehiro's branch is hanlding fast presets a little better than the main branch. So this would be extra work to fix fast presets in the main branch, and this would be a "waste" if we merge Takehiro's branch just after.
I don't think so. As already said several times, the actual code has a lot of field testing, whereas Takehiro's code is only tested by a small amount of people. I think it will be less work to do to fix the actual fast preset than to do quality testing on Takehiro's code. Yes, we would have to also do the same work in Takehiro's code, but as I understand Diprom he want's to use some of the new features in the settings, so he has to look at every preset regardless of the status (buggy/not buggy) of the preset. BTW.: IMHO the actual presets should only get bugfixes, and shouldn't use new features for 3.93. We can make an all dancing, all singing 3.94beta with every improvement active developers come up with, but I like to have the 3.93 release to be known as a rock solid release (same quality, less bugs -- not counting bugfixes which affect quality in a positive way).
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.
Bye,
Alexander.
There are 2 kinds of QA with Lame: portability QA, and quality QA.
I think that now, the portability one is ok. If we need to release (as a stable release) now, I think that this is possible.
The quality of presets does not seems worse than in previous release, only bitrate is higher in some cases (although not as higher as it has been).
If you have any concern about the medium preset being included (although I do not plan to document it yet) in a release, I can disable it if you want, we'll put it back in 3.94.
If 3.93 needs to be a release, then of course I do not think we should merge Takehiro's branch before.
About releasing a 3.94beta resulting from merging of branchs soon after 3.93 release, I agree.
This way we will have something like:
3.93 Stable release
3.94 beta with Takehiro's branch
3.95 alpha for new tweaking, new presets, ...
ps: Dibrom, any comment?
Alexander:
I'm not an expert, but I'd agree with all of that. Release a "safe" 3.93 final (including the fixes for the fast presets), and then make the "all dancing, all singing 3.94beta with every improvement active developers come up with" for us guys to test.
tak3lame.exe seems to use qval=3 as standard. Should I use presets with -h?
No, Tak said that in this build -q3 is identical to -q2 in 3.92.
I'm posting this here because I'm not sure which of the two lame-dev mailing lists I should be using (sourceforge or minnie.tuhs.org). I'll repost if someone tells me the right one ...
I submitted some changes to the LAME configure script for Sun Ultrasparc + GCC 3.2 that resulted in a pretty large performance improvement (about 30%) on those systems. These changes went into 3.93.
Since then, there has been some pretty bad performance degradation, the Ultrasparc-optimized 3.93 is more than twice as slow on the average as optimized 3.92. This is using --alt-preset standard and cbr modes.
I'm not sure what happened, since the x86 users are seeing an improvement. Is there anything that can be done? I can provide an UltraSparc test system if necessary.
Thanks
--jth
uum, seems I am too much delayed to notice this thread.
What I can say is .... my branch contains too much experimental things and it changes everyday. Still more I have many pending patches. It's almost "before alpha" stage and will take very long to be "beta" stage.
It's not time to QA my branch. We LAME development team suffer from short of resources. Testing my branch "NOW" is only wasting resources. We should test the head branch.
I don't recomment to merge my branch into main, before releasing 3.93. Some of you say 3.93 will be triial, but 3.93 contains some of speed up(at least for me) and bug fix. It is worse releasing new version IMHO.
btw, for the people interested in my pending patches: This is it.
- impulse like signal detection for long/short block switching improvement.
- better temporal masking.
- more faster VBR.
- intensity stereo.
- mixed block support.
- make nspsy faster/"always" better than gpsycho and remove gpsycho.
- improve "fast" preset quality and remove "normal" preset.
- re-remapping -q option with safen the substep noise shaping.
- new and faster MDCT code.
- SSE/3DNow! FFT/quantization code
- default to use float instead of double
- integrate ssrc resampling code
There's no reason about the order.
If you have any concern about the medium preset being included (although I do not plan to document it yet) in a release, I can disable it if you want, we'll put it back in 3.94.
I don't care if you add your new preset or not. It's not critical code. Talk with Dibrom about this, he seems to have some kind of "fear" (sorry, I don't know how o describe it better in english) this pollutes his other high quality presets.
I'm posting this here because I'm not sure which of the two lame-dev mailing lists I should be using (sourceforge or minnie.tuhs.org). I'll repost if someone tells me the right one ...
Use sourceforge if it is only interesting for LAME (e.g. bugfixes, portability fixes) and the other one for diskussions about MP3 algorithms and the like.
I submitted some changes to the LAME configure script for Sun Ultrasparc + GCC 3.2 that resulted in a pretty large performance improvement (about 30%) on those systems. These changes went into 3.93.
Since then, there has been some pretty bad performance degradation, the Ultrasparc-optimized 3.93 is more than twice as slow on the average as optimized 3.92. This is using --alt-preset standard and cbr modes.
I'm not sure what happened, since the x86 users are seeing an improvement. Is there anything that can be done? I can provide an UltraSparc test system if necessary.
a) check out the latest source and have a look at the ChangeLog file. Don't look at changes in Takehiro's branch. Try to find a logmessage which looks like it is the reason for this (it may be something about loop unrolling, but it hasn't to be such a change which causes this). Backout this particular change and test it.
B) make a binary search. Checkout a version in the middle of 3.92 and the actual code (you can specify dates for a checkout/update). If it is fast: advance further in time (add the half of the timespan between the date of the actual source and the date you just tested); repeat. If it is slow, checkout an earlier version (analogical to what you did previously). This way you should be able to find the commit which resulted in this behavior. Talk with the developer of this commit how to improve the speed.
Bye,
Alexander.
Note: the settings in this board regarding the use of emoticons isn't sticky for a particular message. It was surprising for me. I thought I should be able to disable it, preview the post, and don't have to disable it again.
I was thinking more of a "concern" from Dibrom about this preset.
Is there any other thread I should look at (at the moment only 3.93 related please)?
Has anyone out there looked at py-lame? I like to make the first release (0.x) together with lame 3.93. If somebody has some suggestions he should speak up soon.
Bye,
Alexander.
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.
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.
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.
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's about people concerned about release quality. The LAME developers seem to be more concerned about portability bug fixes then quality improvements. That is what people here are worried about. I don't think anyone here considers Takehiro's improvements of the --alt-presets to be "new features" but to be "bug fixes" in terms of quality improvements.
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.
More on this...
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.
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 have cared about, and fewer still had even bothered to do any testing). This is very irresponsible. This is not how the process works for nearly every other encoder discussed on this board. Releases are verified (at least as much as possible) to show improvements before they are released into the wild. From what I can tell of LAME, there's almost zero quality testing and usually the only bugs which are caught in terms of quality are those which are absolutely show stoppers -- so obvious and horrible that it takes really no testing to notice.
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.
This way we satisfy both kinds of users, those which like to have rock solid software, and those which don't mind a bug or two in bleeding edge software.
Without proper testing, we won't be satisfying either.
Quoting Dibrom:
I don't really see the point in making a release just for the sake of having a new release in X amount of time. Releases should be dictated by the merit of their improvements otherwise it's just arbitrary and could easily cause more problems than it fixes.
Yes, I want to make an improvement over 3.92. 3.92 is stable, so an imroved version has to be stable too. Therefore I don't think we should release 3.93 with Takehiro's code (it's not as tested as the actual one).
As far as I'm concerned, they are both relatively untested. I say we start with Takehiro's branch then because I am at least certain that some major bugs in the alt-presets have been fixed in this branch. Let's start testing with the best.
I don't understand what you mean about "when a program need to be able to run under a whole range of different operating systems." Does 3.92 have some major problems preventing it from running on most major operating systems?
I don't like the word "major" in your sentence. There's more than Windows (or Linux). 3.92 has some problems on some systems which are fixed in 3.93.
You misinterpreted my intent. Unlike your statement earlier deriding Windows users, I have no problems with other OS's. What I was trying to illustrate is that more people will be affected by poor quality testing than will be affected by portability fixes to OS's which are certain to have few users.
The only thing I see in the changelog so far are portability fixes for Tru64 Unix and SunOS 4.x. How many people are those fixes going to affect vs how many people poor quality testing could affect?
There are some changes which aren't in the official ChangeLog on the website, those changes are only listed in the CVS log (or in the file ChangeLog in the LAME tree).
This is a problem. Like I was trying to say earlier, because of the general haphazardness of modifications to the LAME code, nobody is absolutely certain all that has been changed. Therefore, we cannot be certain that quality has not regressed without proper listening tests.
There are some code fixes, which result in a problem with the preset fast setting, but thats only problem.
And you are certain of this?
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.
If you can assure me somehow (I have no idea how) that 3.93 is not any worse than 3.92 except with the fast presets (and that these can be fixed), then go ahead with a release, and I'll work something out on my own for the newer stuff.
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...
ps: Dibrom, any comment?
If you can provide assurances that 3.93 is no worse than 3.92 (once the fast presets are fixed), then, as far as I'm concerned, go ahead and release whenever you like.
If you have any concern about the medium preset being included (although I do not plan to document it yet) in a release, I can disable it if you want, we'll put it back in 3.94.
I don't care if you add your new preset or not. It's not critical code. Talk with Dibrom about this, he seems to have some kind of "fear" (sorry, I don't know how o describe it better in english) this pollutes his other high quality presets.
You could call it a fear if you like. You could also call it a geniune concern for the users. You could call it "looking out for them" in terms of quality. People have grown to trust the alt-presets and the work which I and many others have put into them to provide solid quality.
I'm sorry that you don't seem to share that concern.
What I can say is .... my branch contains too much experimental things and it changes everyday. Still more I have many pending patches. It's almost "before alpha" stage and will take very long to be "beta" stage.
Well this appears to be the nail in the coffin then.
However, if this is the case, I would like for us to collaborate closely on these modifications so that there can be more rigorous quality control.. so that when you are "finished" (at least for the moment) with your improvements, that we will know where they stand in terms in stability in quality.
It's not time to QA my branch. We LAME development team suffer from short of resources. Testing my branch "NOW" is only wasting resources. We should test the head branch.
I'd disagree with that somewhat. I think it's always time for QA, otherwise you will never be certain where you are heading in terms of quality. Also, the head branch certainly does not fix some of the long standing bugs in the --alt-presets...
I don't recomment to merge my branch into main, before releasing 3.93. Some of you say 3.93 will be triial, but 3.93 contains some of speed up(at least for me) and bug fix. It is worse releasing new version IMHO.
OK. I still think that we should be focusing on these improvements though and that much attention should be paid to the changes you are making.
btw, for the people interested in my pending patches: This is it.
- impulse like signal detection for long/short block switching improvement.
- better temporal masking.
- more faster VBR.
- intensity stereo.
- mixed block support.
- make nspsy faster/"always" better than gpsycho and remove gpsycho.
- improve "fast" preset quality and remove "normal" preset.
- re-remapping -q option with safen the substep noise shaping.
- new and faster MDCT code.
- SSE/3DNow! FFT/quantization code
- default to use float instead of double
- integrate ssrc resampling code
I'm very interested in these changes. The only thing I'm uncertain about is the bit about removing the normal presets in favor of the fast presets. I'm not certain this will work very well. I'd like to see them left in place while still benefiting from all of these other improvements, at least until we are absolutely certain that the fast presets are unquestionably better in every regard.
Anyway, since it appears that Takehiro himself does not wish to merge his branch with the mainline, and he's probably the only one who can do it properly, then, as far as I'm concerned, you can go ahead and release 3.93 once the fast presets are fixed and once we are certain that there have been no regressions in quality anywhere else.
I'll continue to work on my own (once again unofficial) releases...
Quick results for only one tested song (I have not the time to do more with my slow PII)
Song : Radiohead - Paranoid Android 6:23 (ripped with EAC secure mode)
presets :
--aps :
3.90.2 : 202 kbps | av. reservoir 74 | Joint Stereo 33.2 ss/66.8 ms | Block 94.7 long/5.3 short
3.92 : 197 kbps | av. reservoir 75 | Joint Stereo 33.6 ss/66.4 ms | Block 94.7 long/5.3 short
3.93a2 (mitiok's 11/10) : 203 kbps | av. reservoir 448 | Joint Stereo 33.6 ss/66.4 ms | Block 94.7 long/5.3 short
3.93a2 (dibrom's compile) : 194 kbps | av. reservoir 74 | Joint Stereo 34.4 ss/65.6 ms | Block 97.2 long/2.8 short
--alt-preset dm-medium :
3.93a2 (dibrom's compile) : 166 kbps | av. reservoir 87 | Joint Stereo 34.4 ss/65.6 ms | Block 97.2 long/2.8 short
--preset medium doesn't appear in this test (sorry gabriel) since I never succeded to make this preset work with the latest alpha (I use razorlame)
I will give my results for the whole album later if I find the time
Thanks for the results Continuum and Manu.
Due to the way circumstances have unfolded though (and some thoughts I'm having on how best to handle this situation), I'm going to halt development on these new presets shortly.
I'm hoping that development will resume in a much more organized and significant manner. If things go as I plan, I'll give more information on this shortly.
If people want to continue testing, that would still be welcome, I'm just not going to be putting out any new compiles until a couple issues are taken care of first...
Thanks to all who have shown interest.
That's too bad!
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"
I mean, aps is transparent already in 3.92!!! What does 3.93 do for aps??? Encode it a slight bit faster? Who cares?
99.9% of MP3 users desire smaller file sizes with the the optimal quality for that given size. Otherwise we would all just listen to WAV files. Its all about making the file size as small as possible to get as many songs as possible on a given media. A VBR medium setting was a GREAT step in this direction.
It's too bad to see it delayed.
Doh!
Well, I just finished encoding another album with 3 of the new presets so I'll just post the bitrates:
James Gang - Yer Album (Remastered) | 11 tracks | Classic Rock
--alt-preset dm-medium: 177 kbps
--alt-preset portable: 175 kbps
--alt-preset dm-radio: 162 kbps
This album was originally released in 1969 (I believe) and the instruments are pretty heavily panned to the sides with very good stereo drums. It's very clean and one of the best mastered CDs I have.
I think these two clips from a song on the album might be useful for pre-echo testing. Clip1 is a pretty clean sounding drum solo with heavy stereo mixing and the other has an overdriven guitar and bass with the drums:
clip1 - flac (http://www.apehaus.com/files/lost_woman_clip1.flac) (2.2 MBs)
clip2 - flac (http://www.apehaus.com/files/lost_woman_clip2.flac) (1.2 MBs)
After some listening all the presets sound very good to me, I haven't noticed any harsh artifacts. Though I think heard some flanging type artifacts in the Halford CD with the dm-radio setting.
I agree very much with Dibrom and I wish that in a new release there were real quality improvements. I really appreciate he's very active in guiding attention to the "quality integrity" of alt-presets for the future versions.
I want to submit my humble contribution:
Last week I've discovered a sample (le_monde.flac) that fails with LAME 3.90.2
Download le_monde.flac (http://members.xoom.virgilio.it/fofobella/le_monde.flac)
MD5(le_monde.flac) = 1739177e0e82cfbf0a397bf21b905fd1
------------------------------------------------------
-- Original vs 3.90.2 encoded --
Settings: --aps
ABX: 16 out of 16, pval < 0.001
Settings: --ape
ABX: 15 out of 16, pval < 0.001
Settings: --ape -Z
ABX: 15 out of 16, pval < 0.001
Settings: --api
ABX: I think i can't ABX
------------------------------------------------------
This sample, taken from my favorite italian band,has a bad pre-echo expecially at 2.2 - 3.4 seconds. I was thinking that there wasn't any possibility for future quality improvements in the meantime and i was very disappointed about the suspended development of --nspsytune2, but now i'm appreciating Takehiro's new work and the intention of adopting his new tunings to the future presets.
I was wondering if Takehiro's new alpha would do better with the above sample, so i downloaded "takehiro-lame.exe" and i started encoding, so here are my results:
--------------------------------------------------------------------------
-- Original vs takehiro-lame.exe encoded --
Settings: --aps
ABX: 29 out of 45, pval 0.036
Comment: I need more tries to reach a good pval
Settings: --ape
ABX: 20 out of 25, pval 0.002
Comment: I need more tries to reach a good pval.
Worse than --aps ?!!
--------------------------------------------------------------------------
The results show a more difficult to abx sample.
-----------------------------------------------------------------
-- takehiro-lame.exe encoded vs 3.90.2 encoded --
Settings: --aps
ABX: 16 out of 16, pval < 0.001
Comments: easy, takehiro's one is better.
-----------------------------------------------------------------
I'm happy because i clearly noticed a higher quality, there are really "significant fixes to pre-echo handling". The sample is still not "perfect" and i think (and hope) that it could be useful for future tunings in this direction.
Just my 2 EURO cents
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?
Now for the bugfixes and for the VBR changes:
The VBR changes are from Robert, and Takehiro had some problems with them. Robert and Takehiro talked about the changes and fixed the problems. 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.
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 followed the lame-cvs list (every commit results in a mail to this list and the mail contains the files which got changed and the commit message for these files). For some of the commits I talked with the commiter about the change (mostly with Takehiro). The only problems I see at the moment is the preset fast issue.
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.
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.
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.
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.
it's about people concerned about release quality. The LAME developers seem to be more concerned about portability bug fixes then quality improvements. That is what people here are worried about. I don't think anyone here considers Takehiro's improvements of the --alt-presets to be "new features" but to be "bug fixes" in terms of quality improvements.
Technically it's new code which isn't widely tested. Therefore it doesn't fit in our intended release. But we don't have to talk about it here, Takehiro has already spoken his last words on this issue.
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!).
More on this...
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.
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.
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).
have cared about, and fewer still had even bothered to do any testing). This is very irresponsible.
See above (testing framework; how the developers test).
This is not how the process works for nearly every other encoder discussed on this board. Releases are verified (at least as much as possible) to show improvements before they are released into the wild. From what I can tell of LAME, there's almost zero quality testing and usually the only bugs which are caught in terms of quality are those which are absolutely show stoppers -- so obvious and horrible that it takes really no testing to notice.
Everyone here is invited to browse the archive of lame-dev and the ChangeLog file and decide if this is the truth. I don't comment further as I already have on this.
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.
The only thing I see in the changelog so far are portability fixes for Tru64 Unix and SunOS 4.x. How many people are those fixes going to affect vs how many people poor quality testing could affect?
There are some changes which aren't in the official ChangeLog on the website, those changes are only listed in the CVS log (or in the file ChangeLog in the LAME tree).
This is a problem. Like I was trying to say earlier, because of the general haphazardness of modifications to the LAME code, nobody is absolutely certain all that has been changed.
Again: browse the ChangeLog file and the lame-dev archives.
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 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.
Bye,
Alexander.
You could call it a fear if you like. You could also call it a geniune concern for the users. You could call it "looking out for them" in terms of quality. People have grown to trust the alt-presets and the work which I and many others have put into them to provide solid quality.
I'm sorry that you don't seem to share that concern.
I have enough trust in Gabriel to be not concerned if he want's to add a new preset. And he said he
may add a new preset, so the he hasn't made a final decission on it (at least not at the time he told it to me).
Bye,
Alexander.
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?
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).
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.
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
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.
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
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.
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.
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.
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.
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.
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?!
More on this...
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.
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..
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.
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..
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?
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
I just want to say...i hear you...nothing more to say, you've said it all..
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.
Dibrom:
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
There is no spoon... but I hope there is a fork.
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...
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.
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.
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.
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.
@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.
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..
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...
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?.
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.
& who would lead this?.
Good question.
@ Dibrom:
Shut up.
Shutup shutup shutup.
(DAMN that felt good.)
@ 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.
@ Dibrom:
Shut up.
Shutup shutup shutup.
(DAMN that felt good.)
Hahaha good call.
(sorry Dibrom)
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...
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)
Ps for some posters: In this thread we are gently discussing. Please do not pollute this thread with unconstructive posts.
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.
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.
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.
@ 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...
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.
i would be interested how the latest developments come out! Maybe dibrom or john33 could make an ICL /nasm build to play with
count down stopped
@takehiro:
Thank you!
This is some very good news. I just hope the rest of the developers will agree to replace the main branch instead of a lengthy, troublesome, and error prone merge.
I'll do some tests with this build when I'm done with classes later today. I'm sure JohnV will probably check it also. We'll make sure to get our feedback to you so that some last minute tuning can take place if necessary.
I'll also try and provide an ICL compile (with sources) later tonight with the extra presets added...
Once things are tested by more people and found to be pretty stable, I think we should hold a larger public listening test of some sort. Maybe ff123 would be interested in helping to set this up?
One more thing...
I will probably subscribe to the Lame-dev list again so that I can make sure I'm up to date on Takehiro's progress, but I think that only keeping the discussion on the list (I noticed a few people on the list have mentioned that they would prefer this) has the effect of isolating the developers from the users here on HA.
I believe this has been one of the roots of this whole problem so far...
Obviously, I can't get all of the users here to participate in discussions on the mailing list. It's much easier for the developers to continue to make an effort to participate in discussion on boards like these as well, at least if they want to keep up to date with listening tests, quality bugs, etc..
Personally, i'm eager to check it out. Gonna wait for the ICL compile. This is great news.
the above are ICL compiles of Takehiro's branch, but I'll take 'em off soon.
the above are ICL compiles of Takehiro's branch, but I'll take 'em off soon.
If you are concerned about web space and/or bandwidth usage, I can host them in N different servers.
I mirrored them here (zipped instead of gzipped):
http://static.hydrogenaudio.org/extra/LAME...ble-lame.p1.zip (http://static.hydrogenaudio.org/extra/LAME/robert/takehiro-stable-lame.p1.zip)
http://static.hydrogenaudio.org/extra/LAME...ble-lame.p3.zip (http://static.hydrogenaudio.org/extra/LAME/robert/takehiro-stable-lame.p3.zip)
@robert:
Did you make patches for takehiro's build so that it compiles on win32? I noticed you mentioned some issues on the mailing list (which is also why I had to use cygwin before)... but since these are native win32 compiles, you must have fixed those problems.
Can you upload the source or something so that I can add the new presets for testing?
There are only a few small patches you'll have to do.
in main.h comment out #include <sys/parm.h>
in machine.h add #define FLOAT_MAX like above
in lame.c expand the #ifdef to comment out ->pinfo
There are only a few small patches you'll have to do.
in main.h comment out #include <sys/parm.h>
in machine.h add #define FLOAT_MAX like above
in lame.c expand the #ifdef to comment out ->pinfo
OK thanks.
I didn't spend much time looking at the problems before since I was in a hurry, good to see they're only minor issues.
I'm a bit confused.
"LAME version MMX <alpha 2, Oct 14 2002.."
I thought it's supposed to be from Oct 15. Or maybe i didn't quite get it right..
Just a note.. the current version crashes when -Y is used with the fast presets.
Also, it seems that the fast presets might be much closer in quality to the normal ones now that there is impulse detection code... Hrmm.. needs more testing though
I thought it's supposed to be from Oct 15. Or maybe i didn't quite get it right..
It's still Oct 14 in this part of the World.
OH! ..
Dibrom: Could you be so kind as to give us just a short list of the critical samples we could use for testing - like, for example, some of the samples you used for tuning the alt-presets originally? (I'll try to do some testing since I have enough time ATM, I can't promise you that it will help you a lot though, since my headphones are a little broken... anyway, I'll try.)
Volcano:
Yes, I'll try to upload most of the original samples I tested with a little bit later (I don't have them with me atm..).
Oh, btw... --r3mix completely screwed up sounding in Takehiro's release. I haven't tested the mainline 3.93 so I don't know if it's the same there also, but at any rate, --r3mix should either be removed, disabled, or aliased to one of the other presets for sure with this build.
Just try it on a sample like castanets or velvet for example..
Oh, btw... --r3mix completely screwed up sounding in Takehiro's release. I haven't tested the mainline 3.93 so I don't know if it's the same there also, but at any rate, --r3mix should either be removed, disabled, or aliased to one of the other presets for sure with this build.
Just try it on a sample like castanets or velvet for example..
I like the idea of aliasing to --alt-preset standard. That way, people who visit R3mix.net and get stuck on the idea of using --r3mix won't actually be doing themselves any 'damage'...
I don't know if you care about who gets credit for what at this point, Dibrom (I probably wouldn't). It looks like --r3mix isn't going away soon, so imho better to have it sound good than trashing sound quality with the latest release. Unless Roel decides to chime in & say something...
Oh, btw... --r3mix completely screwed up sounding in Takehiro's release. I haven't tested the mainline 3.93 so I don't know if it's the same there also, but at any rate, --r3mix should either be removed, disabled, or aliased to one of the other presets for sure with this build.
Just try it on a sample like castanets or velvet for example..
I like the idea of aliasing to --alt-preset standard. That way, people who visit R3mix.net and get stuck on the idea of using --r3mix won't actually be doing themselves any 'damage'...
I don't know if you care about who gets credit for what at this point, Dibrom (I probably wouldn't). It looks like --r3mix isn't going away soon, so imho better to have it sound good than trashing sound quality with the latest release. Unless Roel decides to chime in & say something...
I don't really care about credit, no. But I think that if it is aliased to one of the other presets, there should be a warning message displayed that --r3mix is outdated and that another preset is actually being used. This will let users know to switch over to the standard presets over time instead of continuing to use --r3mix until one day it gets removed completely..
ha, just make lame quit without any encoding... "fatal error: unrecognized commandline switch"
kidding
If --r3mix is aliased to --aps, which I think it should, there should be some info message written to the console that says r3mix is deprecated and LAME is automatically replacing it with alt-preset standard. You don't want to secretly make the change because people will hear the improved aps version and think "wow, r3mix sounds nice".
Once things are tested by more people and found to be pretty stable, I think we should hold a larger public listening test of some sort. Maybe ff123 would be interested in helping to set this up?
Possibly. I haven't been active lately (ask JohnV how I've been slacking), but these things go in phases for me.
ff123
What a speed improvement! I'm using the lame.p3.exe compile available above and it's about 50-60% faster than LAME 3.92 MMX.
are the new presets already in ? I can't get them to work!
Hi
I'm not a developer but a kind of a long-time observer. I've been reading lame-dev and this forum for about a year (since when dm-presets where the bleeding edge). Some will say it's too short, others it's enough but it doesn't matter. I read the whole thread and have to admit that I agree with Alexander. He responded very rationally to JohnV's and Dibroms's post and presented some valid arguments. (altho i had seen a discussion about 3.93 and aps on lame-dev a few days earlier). But I felt disturbed when I read Dibrom's response. It was very emotional, definitely not based on reason or logic in thinking out the problem. To me, it seems that when quality and psychoacoustic compression is involved, Dibrom presents very rational arguments. But here, when lame-dev was mentioned, he irrationally discarded a lot of valid points. This was something I just had to write about.
Dibrom, you wanted to wait with the release until you were absolutely sure nothing was broken. Alexander came here to pinpoint what had been changed, what can cause problems. He told you, Dibrom, "go ahead, test, code, do everything you want and the release will be delayed until you are done". You, Dibrom, responded in a very impolite manner, laughing at the other developers' efforts, depreciating their merits. I don't understand, what else did you expect Alexander to say? And all this without being subscribed to lame-dev nor lame-cvs, where the developers discuss how the changes to the code affect the resulting bitstream. Without access to these lists your critique, especially the 'lousiness' part, seems irrational to me. Don't turn people against you. You also keep saying that the developers are personally attacking you. They don't.
I think that only keeping the discussion on the [lame-dev] list (I noticed a few people on the list have mentioned that they would prefer this) has the effect of isolating the developers from the users here on HA.
Sorry, but that really upset me. This is the mainstream LAME discussion list:
lame-dev: http://www.geocrawler.com/lists/3/SourceForge/7323/0/ (http://www.geocrawler.com/lists/3/SourceForge/7323/0/)
This is the mainstream code change list:
lame-cvs: http://lists.sourceforge.net/lists/listinfo/lame-cvs (http://lists.sourceforge.net/lists/listinfo/lame-cvs)
If, for example, you conduct listening tests and don't report them to lame-dev, than you're creating an isolated community here. Imagine every developer created his own forum. We would have a giant mess then. HA has its role in the community to inform the users about audio-related matters but is not (shoudn't be) meant to replace lame-dev. And sourceforge.com, which hosts lame-dev, is a well-known neutral site for open projects.
This is teamwork. You have done a great work. The others have done a great work too. But the attitude is doing more harm than good.
Obviously, I can't get all of the users here to participate in discussions on the mailing list. It's much easier for the developers to continue to make an effort to participate in discussion on boards like these as well, at least if they want to keep up to date with listening tests, quality bugs, etc..
see above....
Okay, there are more ppl at this forum than at lame-dev who want to participate in listening tests and are good testers. But cooperation is needed. That applies to the both sides.
I will probably subscribe to the Lame-dev list again
Thank you. I felt relieved. My respect for you had depreciated because of your responses in this thread, but now it is going up.
Best regards,
Joey
Ps for some posters: In this thread we are gently discussing. Please do not pollute this thread with unconstructive posts.
Maybe it would be best to have a separate thread for user discussion? Sounds like a good idea to me.
Hi
I'm not a developer but a kind of a long-time observer. I've been reading lame-dev and this forum for about a year (since when dm-presets where the bleeding edge). Some will say it's too short, others it's enough but it doesn't matter. I read the whole thread and have to admit that I agree with Alexander. He responded very rationally to JohnV's and Dibroms's post and presented some valid arguments.
He may have responded rationally, but he responded rationally to the wrong points. He mistook us all for windows users begging for new features. Since his argument seemed to be based on that single assumption, the whole thing was pretty much flawed.
But I felt disturbed when I read Dibrom's response. It was very emotional, definitely not based on reason or logic in thinking out the problem. To me, it seems that when quality and psychoacoustic compression is involved, Dibrom presents very rational arguments. But here, when lame-dev was mentioned, he irrationally discarded a lot of valid points. This was something I just had to write about.
I beg your pardon, but I responded with facts and valid points. You can say my argument was irrational, but without pointing out and debating what was irrational about it, your statement means nothing.
Dibrom, you wanted to wait with the release until you were absolutely sure nothing was broken. Alexander came here to pinpoint what had been changed, what can cause problems.
Correction, he came here to point out what
to the best of his knowledge could cause problems. Since he had not performed any rigorous listening tests he could not be sure there were not other issues. He mentioned only slight changes in rounding precision and I responded with a case where that had caused problems. He said the code was stable and I pointed out that the fast presets were broken, so obviously it wasn't stable. Since it was not stable in one place, and there were some significant code changes (relatively), and it had not been put through rigorous listening tests, it stands to reason that there are more possibilities where it fails as well that have not been detected yet.
He told you, Dibrom, "go ahead, test, code, do everything you want and the release will be delayed until you are done". You, Dibrom, responded in a very impolite manner, laughing at the other developers' efforts, depreciating their merits.
Correction again, I laughed at him saying that I was spreading FUD. Perhaps you missed that part in his argument where he abandoned his so-called reason to accuse me of spreading misinformation to further some sort of agenda.
I believe that there is nothing wrong with me laughing off such flawed accusations.
I don't understand, what else did you expect Alexander to say? And all this without being subscribed to lame-dev nor lame-cvs, where the developers discuss how the changes to the code affect the resulting bitstream. Without access to these lists your critique, especially the 'lousiness' part, seems irrational to me.
You are aware of the fact that I can read the lists through archives, right? And you are aware of the fact that I was on the list in the past, right? And you are aware that I have worked closely with many of the key developers in the past and have many times tried to point out flaws in both the encoder and development process, right?
My statement of "lousiness" as you put it, is based on the very extensive efforts I have made in the past to both improve LAME and to get the LAME development process improved.
A quick example: Around the time I was finalizing the --alt-presets, I suggested that GPSYCHO be finally disregarded and nspsytune be defaulted because it was clear that nspsytune was better in most arounds than GPSYCHO, especially when the fixes the alt-presets presented were used. There was much debate on the list (Alexander being one of the prime opponents) and in the end, nothing was done. The key developers said that nspsytune would eventually be merged with GPSYCHO and that the problem would take care of itself. That was..... how long ago? 8 months or so? Longer? I don't even remember.... and guess what? Nothing has changed...
The same thing went for the --alt-presets replacing the normal presets.... guess how long that took? I made quite an effort to get the --alt-presets to replace the normal presets once and for all... and after I no longer cared to fight about it, the developers
finally decided to merge (not replace... so the old and outdated and poor quality presets still exist) the --alt-presets with the normal ones.
Another example would be that right after 3.90 was released, I discovered a critical bug in the fast presets at the last minute. I tried to get the developers to release a bug fix but they wouldn't do it. So I released 3.90.2. I was flamed for it. And guess what? Shortly after I released my 3.90.2 they finally decided that they wanted to release a bug fix after all. Imagine that...
It would not be a lie to say that every effort I have made to improve LAME (aside from the alt-presets... which I just provided code for and nothing else...) has met with resistance and in some cases hostility. Many times alternatives have been offered by the developers, but all too often the suggestions they themselves made were not followed through with... The only times there have been exceptions to this rule is when I worked with a
concerned developer directly (Naoki, Robert, Takehiro..) and disregarded the entire lame-dev process....
Believe me, I know very well how the LAME development process works. I don't need to be lectured or chastised by you because I "just don't understand" how it works or something.
Don't turn people against you. You also keep saying that the developers are personally attacking you. They don't.
Did you miss the part where Alexander accused me of "seeding FUD", as he put it? Whether or not that's a personal attack, it's definitely an attack of some sort and given the fact that my argument was full of valid points (while Alexander mostly ranted about Windows users and misinterpreted the fact that we were concerned with quality to mean we just wanted more features), I think it's also one not made in good spirit.
The only people that will be turning against me here are the people that don't open their eyes and truly analyze both arguments but instead make their decision about who is right based on emotion and personal preference. I dare say that you are guilty of that which you accuse me..
I think that only keeping the discussion on the [lame-dev] list (I noticed a few people on the list have mentioned that they would prefer this) has the effect of isolating the developers from the users here on HA.
Sorry, but that really upset me. This is the mainstream LAME discussion list:
lame-dev: http://www.geocrawler.com/lists/3/SourceForge/7323/0/ (http://www.geocrawler.com/lists/3/SourceForge/7323/0/)
This is the mainstream code change list:
lame-cvs: http://lists.sourceforge.net/lists/listinfo/lame-cvs (http://lists.sourceforge.net/lists/listinfo/lame-cvs)
If, for example, you conduct listening tests and don't report them to lame-dev, than you're creating an isolated community here. Imagine every developer created his own forum. We would have a giant mess then. HA has its role in the community to inform the users about audio-related matters but is not (shoudn't be) meant to replace lame-dev. And sourceforge.com, which hosts lame-dev, is a well-known neutral site for open projects.
I explained my stance on this already. There are many people here who have much to offer to LAME (even developers that aren't "official LAME developers") who are not going to subscribe to the list. This has nothing to do with me either. Therefore, since HA has been so active in it's desires to improve LAME (even if many of the developers have not paid attention to this in the past), it makes sense for them to pay attention to the discussions here.
And as for my "responsibility" to the lame-dev, please. Read my above statements. I've already done my part in reporting quality bugs to the list or to the developers. I've reported results from listening tests and have made suggestions on how to improve LAME. They've all been either ignored, or on occassion I have even been flamed for my own efforts. Why should I continue to bother with lame-dev then?
This is teamwork. You have done a great work. The others have done a great work too. But the attitude is doing more harm than good.
I agree. The prevailing attitude of development is doing more harm than good and is also preventing true progress.
Okay, there are more ppl at this forum than at lame-dev who want to participate in listening tests and are good testers. But cooperation is needed. That applies to the both sides.
And what happens when "cooperation" becomes one sided (i.e. suggestions fall on deaf ears...)? When there is no real organization or direction, but when someone tries to create a direction there is a hostile reaction? What then?
I'm sorry if you will view this message negatively (I imagine that you might..), but many of the things you have stated about me, my intentions or experiences, etc, here are just flat out wrong.
Anyway, I will be closing this thread now. Discussion of 3.93 can continue in a different thread. If anyone has something further to say along these lines, feel free to private message me.