Unfortunately I will not be making these presets. I am no longer working on LAME or with the LAME developers. Sorry. This is pretty much due to the endless conflict between the way LAME development currently works and my own ideology on the matter. I'd go more into detail, but I don't think there's much point in that.
I believe that JohnV may try to resume some of my work on presets, but you'll have to ask him.
Well, I don't think I want to "resume" Dibrom's work. Instead I'd want to revive the community testing for the future Lame versions, now that Dibrom has dropped supporting alt-presets.
Some of my ideas in no specific order:
1. I hope that 3.94 will make "non-forked" presets (using external presets) closer to a-p standard,extreme and insane quality levels possible.
2. I'd want the community to keep testing and giving recommendations for the future Lame presets if alt-preset is dropped. Lame 3.94 brings new quality improvements which need to be checked in the form of new switch testing.
3. This would definitely need the help of the "old gang": HansHeijden,Wombat,ff123,volcano etc.. I'd want that there could be somekind of "community recommendation" also in the future versions of Lame and more active testing. Testing should be done in normal ABX/DBT style and clear reports with original clips should be provided. Everything (every switch) should be justified. "wild style" switch suggestions would not be tolerated. Everything should be done in very systematic way.
4. Lame should ideally provide very high quality with simple switch sets. I'd hope that Takehiro would get some valuable hints, how to tweak the psymodel, when 3.90.2 APS/APX/API and 3.94 and later with best possible external switches are directly compared. I hope that in some point in the future no complicated forking is needed in order to gain APS/APX/API -quality and even beyond.
5. It should be checked especially for 3.94 and beyond if better external switches can be found than the switches in external preset A-Ps (non-APS/APX/API).
6. Imo it's important to keep supporting and testing Lame also in the future.
7. The recommended Lame version and presets should not change until it has been proven that something is better. However, now that Dibrom has dropped the support, it's important imo to keep up somekind of continuity for the future versions of Lame. In best case, this would lead to simple switch set which provides better results than APS/APX/API hopefully some beautiful day in the future. Until then, the official recommendation should remain the same. But at the same time for the sake of continuity, testing should be revived for 3.94 and beyond. Many people will always use the latest version, because they automatically expect quality improvements. Unless something is done, future Lame versions could infact go very much backwards in quality.
There.. I'd like to know what people think about this..
Sorry, don't have any useful things to add in this second, just want to mention that i'm kind of shocked about the news regarding Dibrom and his work on the presets in the future. At least i can understand his point, so many things regarding communication in the LAME projects didn't work as it should have.
Hopefully many people on this board will at least try to give some support with listeneing test, sounds like a nightmare to me that there could be a future version of LAME (let's say 4.0) with inferior quality. But as it seems to me right now it could happen easily! :'(
2. I'd want the community to keep testing and giving recommendations for the future Lame presets if alt-preset is dropped. Lame 3.94 brings new quality improvements which need to be checked in the form of new switch testing.
3. This would definitely need the help of the "old gang": HansHeijden,Wombat,ff123,volcano etc.. I'd want that there could be somekind of "community recommendation" also in the future versions of Lame and more active testing. Testing should be done in normal ABX/DBT style and clear reports with original clips should be provided. Everything (every switch) should be justified. "wild style" switch suggestions would not be tolerated. Everything should be done in very systematic way.
...
There.. I'd like to know what people think about this..
I'd be willing to host samples as well as pitch in with listening opinions. There's a page around somewhere with the current list of problem samples for aps, isn't there? These and other samples used for regression testing would be useful as a reference.
It's going to take a pretty strong-willed individual to push through this type of agenda, though. I think you'd be a perfect guy to lead, JohnV.
ff123
I'd just like to offer my sincere thanks to Dibrom for all of the time and hard work that he has put into making the --alt-presets a reality. Even if he has stopped development on them, the current --alt-presets with LAME 3.92 are good enough for me. It all sounds great on my SlimX!
Good luck on this, JohnV.
I have just a small bit of advice though: Before you get too far into planning for how you are going to approach this situation, I'd suggest having a very detailed discussion with the LAME developers about what exactly they are willing to do and what they aren't. It'd be wasteful to put a lot of effort into something only later to find out that the other people involved do not show the same motivation or share the same goals and interests as you. Also, don't assume that other people are going to follow your lead or go along with your plans just because they might be based on a good idea.
I think this is partially why my own approach didn't work out in the end.
While its sad development on the presets is stopped (well, by Dibrom anyway), I personally never thought mp3 would sound as good as lame 3.9x ended up sounding - especially after horrible early experiences with Xing and Fhg - so three cheers for everyone who made it possible to get this far And good luck to you, JohnV
Hmm.. I'd hope that people would not follow "my" lead, but there would be some core-group, which would give recommendations..
Here's a clear example why some of the current --alt-presets as such don't provide the best possible quality and what can be expected in the future from Lame.
Original awe32_20sec.flac (http://static.hydrogenaudio.org/extra/samples/3.93-Test_Samples/awe32_20sec.flac)
Current recommened Lame 3.90.2 --alt-preset cbr 128
awe32_3902-AP128cbr.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/awe32_3902-AP128cbr.mp3)
Lame 3.94a2 --alt-preset cbr 128
awe32_394a2-AP128cbr.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/awe32_394a2-AP128cbr.mp3)
Lame 3.94a2 with simple -b128 -q0 --nspsytune (no tweaking, but gives a lot better quality than above)
awe32_394a2-128cbr.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/awe32_394a2-128cbr.mp3)
You can clearly notice, that the 3.94a2 --alt-preset cbr 128 is not optimal anymore at all and 3.90.2 also gives bad quality. I gained very much better results with very simple commandline in 3.94a2 which I didnt even try to tweak at all. This is why new tweaking is needed.
Btw. Mitiok does not provide the 3.94a2, but only 3.94a1 for some reason. 3.94a1 seems to lack important tweaks by Takehiro.
Lame3.94a2 is available here: http://static.hydrogenaudio.org/extra/LAME...-394-alpha2.zip (http://static.hydrogenaudio.org/extra/LAME/lame-394-alpha2.zip)
This example alone imo shows why testing and tweaking should continue.
Hmm.. I'd hope that people would not follow "my" lead, but there would be some core-group, which would give recommendations..
IMO, it will take a strong leader with a good ear and at least a passing knowledge of how the code works to make sure that particular tweaks are tested out thoroughly. Otherwise, it will be hit and miss.
BTW, I think 3.90.2 sound clearly the worst on the sample clip you provided.
ff123
You can clearly notice, that the 3.94a2 --alt-preset cbr 128 is not optimal anymore at all and 3.90.2 also gives bad quality. I gained very much better results with very simple commandline in 3.94a2 which I didnt even try to tweak at all. This is why new tweaking is needed.
Of course. Let's not forget though that the cbr and abr modes of the --alt-presets never made use of code level tweaks. They are simply switch aliases (and also have not been tuned even close to that the VBR presets have been). It's no surprise that you can get better quality in some cases then by a different set of switches. VBR is a totally different story though, and I'm much more skeptical about getting better quality than the --alt-preset VBR modes via simple command line switches without very extensive help and motivation from one of the core LAME developers.
Edit: And btw, I haven't listened to the samples you provided.. so I'm not meaning to say I'm agreeing or disagreeing with you on that part. I only agree that higher quality is possible in some cases than the --alt-preset cbr and abr modes by using other command line options.
IMO, it will take a strong leader with a good ear and at least a passing knowledge of how the code works to make sure that particular tweaks are tested out thoroughly. Otherwise, it will be hit and miss.
I'd have to agree with this statement from ff123. I don't think a "consensus" approach is really going to work (it doesn't work in LAME development for this purpose at least). The reason that there were never --alt-presets in the past is because there was no leader to spearhead the effort and to try and get the quality tuning process consolidated and moving towards a specific goal. There are many people who are capable of working on something like what you are proposing here, but without a solid direction, like ff123 said, it'll be largely hit and miss. I don't think there are enough single highly motivated people (towards this goal) for it just "happen" coincidentally through everyone somehow sharing the same thoughts.
IMO, organization and structure are the key. The
problem is getting people to agree with your ideas and to all work together towards the same goals.
those are some interesting samples, JohnV. I agree with your opinion that the untweaked 3.94a2 is superior.
3.90.2 - lots of distortion and flange on bass
3.94a2 --ap cbr 128 - less distortion, but chirps and watery sounds make this one the worst of the bunch.
3.94a2 untweaked - less distortion than both, small amount of chirping, seemingly only in the right channel..
Just for the heck of it I also tried 3.92 -ap 128 (abr) and MPC 1.14 --standard
3.92 - very close to 3.90.2 cbr surprisingly! In fact I believe slightly worse (more flange).
MPC 1.14 - transparent to my ears.. just notable for the fact that its 356 kbps! (probably someone pointed that out already)
BTW, I think 3.90.2 sound clearly the worst on the sample clip you provided.
Well, actually 3.94a2 --alt-preset cbr 128 sounds also very bad, because it has the same problem, which caused the 3.93 quality issue.. So the above awe32 example is not valid... Problem is broken quantization type (-q3 by default in A-P 128 in 3.94a2. Also notice that there were re-ordering of q-types. Lame 3.93 with -q2 uses the same q-type as 3.94a2 -q3, which are broken). So could be that --alt-preset cbr 128 would be the best switch when -q3 is fixed, but who knows..
Anyway, in Fatboy this is even more clear than in awe32:
Current recommened Lame 3.90.2 --alt-preset cbr 128
fatboy3902-AP128cbr.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/fatboy3902-AP128cbr.mp3)
Lame 3.94a2 --alt-preset cbr 128 (quantization type -q3 broken, actually should ignore this sample)
fatboy394a2-AP128cbr.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/fatboy394a2-AP128cbr.mp3)
Lame 3.94a2 --alt-preset cbr 128 -q0
fatboy394a2-AP128cbr-q0.mp3 (http://static.hydrogenaudio.org/extra/LAME/mp3examples/fatboy394a2-AP128cbr-q0.mp3)
Here I provided only alt-preset cbr 128 samples, except the last example uses correctly working q-type (-q0). This shows how much better nspsytune pre-echo handling becomes in 3.94..
Heh.. at the same time I figured why Lame 3.93 sounded so bad.. its -q2 at least with cbr nspsytune is broken. Could be that Tak has already figured this out though.
These are really sad news, since I really hoped for a preset for portables by Dibrom...
Anyway, thanks for all the time and work you (and others) invested in the alt-presets, it's impressing hwat you did and how it succeeded.
The suggestions made by JohnV seem pretty sensible to me and I'll try to help whereever I can.
dev0
Ditto... I think it's sad news too. Given the amazing prevalence of the MP3 format on portable devices of all sorts (and non-portable devices too) this isn't good news. Of course, the existing --alt-presets still work, but better tuning for lower bitrates is really needed in Lame, IMHO... not to mention, tuning for 48KHz. Hopefully someone will take the baton and run with it.
MP3 has a bad enough reputation among "audiophiles" as it is (especially the typical 128k CBR file), let's hope it doesn't get even worse now if the --alt-presets are broken in future Lame versions. It could even invalidate all of Dibrom's previous work and turn it into nothing but wasted time & energy -- by the time v4.0 of Lame is out, who will be using v3.90.2 except a small core contingent here on HydrogenAudio?
Here I provided only alt-preset cbr 128 samples, except the last example uses correctly working q-type (-q0). This shows how much better nspsytune pre-echo handling becomes in 3.94..
Heh.. at the same time I figured why Lame 3.93 sounded so bad.. its -q2 at least with cbr nspsytune is broken. Could be that Tak has already figured this out though.
So if you use the VBR alt-presets with 3.94a2, you should use -q0 (overriding the default -q3)?
So if you use the VBR alt-presets with 3.94a2, you should use -q0 (overriding the default -q3)?
I don't think APS should be used with 3.94a2 at all until somebody has verified it..
So if you use the VBR alt-presets with 3.94a2, you should use -q0 (overriding the default -q3)?
I don't think APS should be used with 3.94a2 at all until somebody has verified it..
I've been using it for some time - seems like it has the most advanced code of any compiled version. I don't remember hearing any nasties with APS using 3.94a2 but I haven't subjected it to any encoder-killing clips.
There is a major performance difference between -q0 and -q3, the latter is approximately 3x faster.
The question that comes up in my mind is:
Did did the fix that Gabriel made on 3.91 (so that 3.91.1 came out) go into 3.94a2 ?
3.93.1 right now has 'returned' to 3.92 quality, as it seems.
The question that comes up in my mind is:
Did did the fix that Gabriel made on 3.91 (so that 3.91.1 came out) go into 3.94a2 ?
3.93.1 right now has 'returned' to 3.92 quality, as it seems.
I have actually no idea what's the 3.93.1 version that Gaby provided for testing and what kind of modification he did to it, or is it just compiled from earlier source. It shows me 3.94a1..
There is a major performance difference between -q0 and -q3, the latter is approximately 3x faster.
Well.. I'd guess that the -q3 issue does not necessary affect vbr.. I also tested 3.94a2 with some nspsytune lines and -q3 seemed quite fine. I haven't tested extensively so I'm not gonna guarantee anything...
btw. if you have used 3.94a2 with APS, what kind of bitrates it creates generally compared to 3.90.2 or 3.92?
I'd really like a kind of community effort for listening tests.
It's obvious that developpers can not have time to do every listening test (just speaking about time, not ability).
A community testing has a lot more time, because it's splitted between more people.
Listening test for every change are very time consuming, and I think that only a community is able to achieve this.
About lower bitrates presets: I think that I might do them, mainly because I'm interested in them. Also I have the hearing ability to do them, while I don't have this ability for high bitrates vbr presets.
Right now, the lower bitrate preset using vbr is medium. I received only few reports about it (but no negative reports).
The 3.93.1 version I provided in another thread for testing is a fixed 3.93, not an earlier version.
Hello,
i have to admit i don´t have that much time at the moment for Lame.
But it gave me so much fun i will sure test further if i can.
JohnV as a coordinator makes sense and is very promising i believe.
On saturday i will go through aps testing with the newer versions.
cu
Wombat
I tested how close Lame 3.90.2 (http://static.hydrogenaudio.org/extra/LAME/lame3.90.2-ICL.zip) --alt-preset standard I can get with quick external switch tweaking using Lame 3.94a2 (http://static.hydrogenaudio.org/extra/LAME/lame-394-alpha2.zip). (Mitiok does not host alpha2)
Anyway, this was the best I could do with external presets and 3.94a2 in short amount of time. It's not better than 3.90.2 APS in extreme pre-echo samples, but it's quite close, and it handles some of the APS problem clips better:
lame394a2 --nspsytune -V2 -mj --nsmsfix 1.1 -q3 -b112 --lowpass 19 --athtype 4 --ns-sfb21 2 -X0 -Z
Some explanation:
--nsmsfix 1.1: because of the serioustrouble ringing, cant be higher..
--athtype 4: same as base APS
--ns-sfb21 2: lower resolution (increase masking) for over 16khz freqs in order to combat bloat (because of the infamous no scf21 issue)
-X0: noise measurement type selected based on quick testing over -X1
-Z: switch for noiseshaping type1. Because of this some of the APS problem samples sound better.
-b112: lower min bitrate than in APS, because of ns-type 1 and -V2.
-q3: seems to work with vbr at least here.. although broken in cbr. Lots faster than -q0/-q1 and -q0 seems broken also.
There is a major performance difference between -q0 and -q3, the latter is approximately 3x faster.
Well.. I'd guess that the -q3 issue does not necessary affect vbr.. I also tested 3.94a2 with some nspsytune lines and -q3 seemed quite fine. I haven't tested extensively so I'm not gonna guarantee anything...
btw. if you have used 3.94a2 with APS, what kind of bitrates it creates generally compared to 3.90.2 or 3.92?
3.94a2 APS seems to have somewhat higher bitrates than 3.90.2 or 3.92 but it isn't enough to cause alarm. EncSpot reveals that 3.94a2 employs more short blocks than the previous versions, in some cases much more. I have several files where short blocks make up 15-20% of all blocks.
Is there any chance the situation will change to a more harmonious one, and is there any chance some developers can agree on an effort to get Dibrom back?
From the outside looking in it appears to me as if the entire preset effort is starting to unravel: Dibrom leaves because of a certain measure of disorganization, after which not even a Semi-organized effort is launched to keep him in the process, the implication being that either nobody gives a damn, or as a group they're so disorganized that nothing much matters except each person's 4.95638% of the project.
How wrong am I? Nex
I think that Dibrom deserves some good holidays, after all he has done. Let's not try to push him too hard for coming back for the time being.
Yeah, this really is bad news...
I must say that according to all i've read in this forum about how LAME development is handled, and how quality doesn't matter to those who make calls, is really frustrating, and can certainly understand why Dibrom's fed up with all that... It's just too plain frustrating.
Well, what i can offer is my listening, since i don't have coding talents. Whenever "important scale" testing will be needed i'll be glad to help.
I tested how close Lame 3.90.2 (http://static.hydrogenaudio.org/extra/LAME/lame3.90.2-ICL.zip) --alt-preset standard I can get with quick external switch tweaking using Lame 3.94a2 (http://static.hydrogenaudio.org/extra/LAME/lame-394-alpha2.zip). (Mitiok does not host alpha2)
Pls use 3.94alpha4.
alpha2/3 contains fatal bug which may make "invalid" mp3 file.
alpha2 contains stupid bug in block type switching (I made a typo 1.0 from 0.1).
So I think you should test with at least alpha3, especially if you want to check the pre-echo related problem.
-X0: noise measurement type selected based on quick testing over -X1
I have not tested much, but it seems -X0 is needed for short blocks and -X1 is needed for long blocks (in ABR/CBR mode). I wonder why this is happen.... Maybe because of short block psymodel mess.
In the old-vbr mode, -X0 and -X1 makes difference only when the 320kbps is not enough. In the such case, the block type is a short type almost always.
So the -X0 for vbr preset will be Ok I think.
alpha2 contains stupid bug in block type switching (I made a typo 1.0 from 0.1).
So I think you should test with at least alpha3, especially if you want to check the pre-echo related problem.
I'd hope mitiok would start providing latest alphas instead of giving the alpha1 as "dailylame".
I'd hope somebody would clear the situation what's going on in Lame CVS. Is your alpha4 the one which is gonna become 3.94. Hopefully, but I'm just wondering because Mitiok provides dailylame 3.94 alpha1..
I can explain the situation:
The main branch, after 3.93 as been flagged as 3.94. So if you retrieve main branch, you'll have something that is said to be 3.94 alpha1. But as you know about the 3.93 problem, we will have 3.93.1. That is what is in the current main branch but still flagged as 3.94alpha1.
The "real" 3.94 is in Takehiro's branch. I'll try to post a compile of this thing this evening.
(note: perhaps this is an indication that we should have a branch policy)
Which branch of Takehiro is the real 3.94 and does this branch include to bugfix from 3.93.1?
-Jeff
I have encoded some samples with 394a2 and have some "unqualified"
meaning so far. What ever they did, lame has become more punchy.
I mean where some might say this is softened and an abx war starts.
Seems to be the new block switching.
I used JohnV´s command line that is the consequent way to go with only
switches. Nothing to add. Now lets find samples that don´t work with a4
Wombat
So I gather that the forthcoming 3.94alpha4 compile will represent the most advanced/tweaked LAME code to date?
Where could I get 3.94alpha4 ?
It is very sad news that Dibrom has left LAME and he deserves all of our appreciation.
He seemed to be the only one who was not too 'close' to the technical details to remember the real value of MP3 - outstanding, easily transferrable audio quality in a SMALL sized file. Since the majority of people who use MP3s use them on portable devices (if you are at home, just listen to a CD or WAVE file, why mess with MP3???? What value doe sit provide when the file size is not a constraint), a small sized file that provide soutstanding quality is most desired. it seems the other programmers place no emphasis on the file size part of the equation, only on the quality size.
Again, last time I checked WAV and APE files provided PERFECT quality. Why not just use those???
Maybe some day someone will develop a 'portable' setting. until then, we have APS -Y if you have a digital jukebox and aps CBR 128 if you have a flash player.
Dibrom, thanks. we will miss your work.
Wav and ape eats too much space.
3.94a2 APS seems to have somewhat higher bitrates than 3.90.2 or 3.92 but it isn't enough to cause alarm. EncSpot reveals that 3.94a2 employs more short blocks than the previous versions, in some cases much more. I have several files where short blocks make up 15-20% of all blocks.
I really noticed the 3.94a2's short block handling on Paul Simon's "Me And Julio Down By The School Yard" with nearly 32% shortblocks, compared to 3.92's 16%. I guess that's from:
takehiro: alpha2 contains stupid bug in block type switching (I made a typo 1.0 from 0.1).
I was wondering if there was a LAME switch that can be used to adjust the robustness/sensitivity of the blockswitching or if that's something that might be useful later on to use with some highly tuned VBR command line such as what JohnV is going for?
Could someone please compile a binary of LAME 3.94 alpha4? I tried looking through http://static.hydrogenaudio.org/extra/LAME/ (http://static.hydrogenaudio.org/extra/LAME/) but I couldn't find it there. I'm guessing this is the best version to use if I want to stick with bitrates in the range of 112-160 kbps (and MP3 is a must)?
Could someone please compile a binary of LAME 3.94 alpha4? I tried looking through http://static.hydrogenaudio.org/extra/LAME/ (http://static.hydrogenaudio.org/extra/LAME/) but I couldn't find it there. I'm guessing this is the best version to use if I want to stick with bitrates in the range of 112-160 kbps (and MP3 is a must)?
I would happily do so, but I have no idea where to obtain the source from!! I presume it's not in the standard CVS. Is it in Takehiro's CVS branch?
I can explain the situation:
The main branch, after 3.93 as been flagged as 3.94. So if you retrieve main branch, you'll have something that is said to be 3.94 alpha1. But as you know about the 3.93 problem, we will have 3.93.1. That is what is in the current main branch but still flagged as 3.94alpha1.
The "real" 3.94 is in Takehiro's branch. I'll try to post a compile of this thing this evening.
...
I guess you're right John33 (according to what Gabriel wrote).
It seems to me it's still more than just a "little" early to start using 3.94alpha4 for anything other than testing...
Some of the comments here seem to indicate other purposes.
And also:
@ChS: if you encoded your file with alpha2, it might be useful to try to repeat the encode with alpha4 and see the % of short-blocks.
Unfortunately, getting an alpha4 binary doesn't seem to be easy...
I think this is partially why my own approach didn't work out in the end.
I think this is true. Politics is neccesary in this endeavor.
And the sad fact is this:
Sound quality isn't really the priority with the LAME developers or they would have embraced Dib's efforts.
I am wondering how are some of you able to know what are priorities of the few Lame developpers....
Some of you are assuming that is is not sound quality. Well, so tell me how Lame managed to produced not-so-bad mp3 files. It should be worst than Xing or Blade if quality is not a priority, shouldn't it?
You just have to realize that what most of you want is just a new front-end, nothing else. That is not a big deal, you can easily make it and link with libmp3lame.
Until the end of Lame 3.x, the default front-end will keep compatibility with older versions. Only with V4 it could change. In the meantime, it seems reasonable to do a new front-end if you need it.
You can download a copy of Takehiro's 3.94 alpha 4 here. (http://homepage.ntlworld.com/jfe1205/lame3.94a4.zip)
I am wondering how are some of you able to know what are priorities of the few Lame developpers....
Some of you are assuming that is is not sound quality. Well, so tell me how Lame managed to produced not-so-bad mp3 files. It should be worst than Xing or Blade if quality is not a priority, shouldn't it?
You just have to realize that what most of you want is just a new front-end, nothing else. That is not a big deal, you can easily make it and link with libmp3lame.
Until the end of Lame 3.x, the default front-end will keep compatibility with older versions. Only with V4 it could change. In the meantime, it seems reasonable to do a new front-end if you need it.
I'll tell you how. The BEST thing that EVER happened to Lame sound quality was the alt presets. How was Dibrom treated by you guys? Were his efforts applauded or even appreciated? Did you guys invite him to join the developement team?
Who wants "not-so-bad mp3 files" anyway? NOT ME. I want the BEST. If you guys really want the best TOO, if sound quality is INDEED the priority, Dibrom would BE a Lame developer instead of just an outcast. An encoder which isn't fine tuned is WORTHLESS as far as I'm concerned.
This has NOTHING to do with frontends. I can write whatever frontend people want. John Edwards can write an even better one. It's not about frontends, it's about sound quality PERIOD.
And also:
@ChS: if you encoded your file with alpha2, it might be useful to try to repeat the encode with alpha4 and see the % of short-blocks.
Checked it out with john33's alpha4 compile and the short block % was exactly the same as alpha2 at almost 32% (31.5% to be exact, which alpha2 was). To make it clear, that's with --preset standard.
Checked it out with john33's alpha4 compile and the short block % was exactly the same as alpha2 at almost 32% (31.5% to be exact, which alpha2 was). To make it clear, that's with --preset standard.
There's lots of short block tunings and possibility in general to much better transient handling with 3.94. So obviously Dibrom should compensate this in --preset standard..
Did you guys invite him (Dibrom) to join the developement team?
yes, Dibrom has every possibility as a LAME developer, since long ago. He just doesn't make use of it.
You just have to realize that what most of you want is just a new front-end, nothing else. That is not a big deal, you can easily make it and link with libmp3lame.
No.
What I want is fundamental improvements to the psymodel. I want consolidation and clarity in the code. I want stability, and I want quality assurance.
Most of all, I want a fundamentally different approach towards project development and management.
None of this is related to a frontend.
Did you guys invite him (Dibrom) to join the developement team?
yes, Dibrom has every possibility as a LAME developer, since long ago. He just doesn't make use of it.
Yes, I have the status of a LAME developer, but only as a singular entity. What I
don't have is sway with the rest of the developers. I've made no secret of the fact that the alt-presets have hit a ceiling and cannot get better without help from one of the other developers -- one of the developers who knows the psymodel well. Recently, this has become possible since Takehiro has started to show some interest. However, the problem now is that I can't convince the rest of the developers to adopt a new approach or to change many of the things in LAME that I think need to be changed. So, yes, I have the "title" of a LAME developer, but for practical purposes (at least for me) it is meaningless.
If you needed help, why didn't you ask for help? You know e-mail adresses of LAME devs, there are mailing lists...
If you needed help, why didn't you ask for help? You know e-mail adresses of LAME devs, there are mailing lists...
I
really hope this is a joke.
First you say I haven't made use of my development status. Then you imply that I didn't ask anyone. I can't tell you how wrong you are on both of those accounts.
I've discussed
many,
many issues in the past with Robert, Takehiro, Naoki and others. I've discussed many of my ideas on the mailing list before in the past also. Just about any remotely active LAME developer should be familiar with at least some of the stuff I've mentioned. Of those 3 specific developers I've mentioned above, I have explicitly asked for help more times than I can count (sometimes I got help, but more often than not, the problems I reported were ignored or put off for quite some time).
Just to give you an example... many of the problems Takehiro has fixed in 3.94 are problems that I've reported over a year ago and asked some of the developers if they could help fix for me. A year later we are just now seeing
some (not all) of those issues being addressed.
Please, if you're going to make statements about my involvement with LAME (presumably to cast doubt on my actions), I suggest you do a little more research first.
Your last mail on lame-dev is from december last year, isn't it? I can't remember your last post on mp3encoder.
Your last mail on lame-dev is from december last year, isn't it?
Sure.
What does that mean? Does it mean that I haven't been in contact with the LAME developers who work on the psymodel since then? No.
Just because I haven't posted to the lame-dev with every single issue that has come up doesn't mean that I haven't been discussing them with the only people who were in the position to do anything about it.
Oh, and the reason I stopped posting on the LAME dev is because it didn't seem to do any good regarding the issues I had brought up (there was constant disagreement, etc). Furthermore, I was flamed for the 3.90.2 release which I felt was critical. I decided it wasn't worth the hassle arguing with Alexander, JD, and mitiok, (who took the time to bitch at me over an issue as trivial as an "unofficial" release, rather than working on fixing the psymodel, making LAME easier to use, or doing anything else constructive) and that instead I'd rather contact Robert, Naoki, and (sometimes) Takehiro directly -- I'd rather be doing work than arguing with people who didn't seem to comprehend the importance of the basic issues at hand (and still don't I gather). In the end, that didn't really make all that much difference either though.
As a total outsider who's seen situations like this many times before, a suggestion: perhaps it's time for a split. rather than just one person leaving the dev group.
Time to form an alliance of a few people to branch-off instead of just losing *one* valuable resource and all the good ideas that come with. Poll some devs. If they're all too laid-back or busy with life to care, okay. But if even just a couple of them agree to a new effort, along with some possible new blood hell, anything could happen.
Keep the ideas alive - where there's a will and all that.
Otherwise, such a waste! And we the users all lose. These splendid presets, Dibrom's under-rated but universally-appreciated interfaces with John Q, us, and his grasp of what people want and can use. Not mere sophistry but a get down and do it attitude.
Rule by either committee or chaos doesn't work in the long run, so I urge Dibrom to push, and others in the dev community to ally themselves with his views *if* they agree, rather than just laying there feeling important. Nex
It seems that I've been misunderstood (or that I mis-explained). I pointed that some users here only want a new front-end, because some always go back to the argument that alt-presets are not defaulted, and that there is still this too long list of available switches available. This particular point means that what those users want is a different front-end (perhaps linked with 3.91 libmp3lame).
It seems that I've been misunderstood (or that I mis-explained). I pointed that some users here only want a new front-end, because some always go back to the argument that alt-presets are not defaulted, and that there is still this too long list of available switches available. This particular point means that what those users want is a different front-end (perhaps linked with 3.91 libmp3lame).
I think this is missing the point. The fact that the --alt-presets are not defaulted is only a smaller part of a much larger problem. Focusing on that issue alone is, as I said, missing the point. People here don't so much want a new frontend as they want a new attitude from the development team which would naturally lead to this course of action on it's own. At least that's how I feel, and I gather that's how most of the other people you were referring to do as well.
My previous response directly to this matter that you raised should make at least my stance clear.
So why are there people claiming that your work on alt-presets is totally ignored? Other than the fact it's not defaulted, I do not understand what they would want. The alt-presets are not alternative anymore, they are pushed by the documentation, and the former presets are gone...
Perhaps those people are only a minority and I mainly remember those posts because some where including harsh comments. (yes, it seems that unfortunately I remember more easily harsh comments)
So why are there people claiming that your work on alt-presets is totally ignored? Other than the fact it's not defaulted, I do not understand what they would want. The alt-presets are not alternative anymore, they are pushed by the documentation, and the former presets are gone...
I don't think it'd be unfair to say that the effort behind the presets was mostly ignored by the developers (if you feel otherwise, can you show this somehow?). After I initially created the presets, I didn't really get any help improving the remaining issues until a year later. There seemed to be little interest overall into furthering this type of development. Also, the alt-presets where just one part of an initiative which was a larger part of my "work".
That work was largely ignored and sometimes actively denied. As for the rest, you'll need to be more specific I'm afraid.
Btw, as to "what they would want", once again, I think they would want the presets and what they represent to be continued in spirit by more people on the LAME development team. Once again, this goes back to the same thing I've been saying over and over and over (read my previous post to this again).
I think the fact that you are asking this also points again to the fundamental misunderstanding of the problem which I have already mentioned elsewhere. The real problem seems to be that the LAME developers don't think that there actually
is a problem.... or they misinterpret it as something else (frontend, or windows users clamoring for more features, etc), missing the point. Wasn't 3.93 evidence enough that something is wrong?
Perhaps those people are only a minority and I mainly remember those posts because some where including harsh comments. (yes, it seems that unfortunately I remember more easily harsh comments)
Maybe so, but you need to be specific if you want a meaningful response. Most of the examples I've given have been backed up with events that have transpired, etc.
People here don't so much want a new frontend as they want a new attitude from the development team which would naturally lead to this course of action on it's own.
I don't know about the others but I've given up on the development team, and just want the new frontend...
Gabriel,
So why are there people claiming that your work on alt-presets is totally ignored?
If a new version comes out that trashes the output of --alt-presets, I would call that total ignorance.
I would rather call this lack of testing.
This is, to my mind, due to two reasons:
*lack of time/ressources
*some people not willing to test because they only wanted to test something really new
I would rather call this lack of testing.
This is, to my mind, due to two reasons:
*lack of time/ressources
*some people not willing to test because they only wanted to test something really new
I would call this either lack of planning or lack of interest in having it being tested.
This is obvious from the fact that there was no 3.93beta.
There was nothing to test.
And please, no excuses about "it's always been in CVS for anyone to check out, compile and test". You know this is not the way things work
I would rather call this lack of testing.
This is, to my mind, due to two reasons:
*lack of time/ressources
*some people not willing to test because they only wanted to test something really new
And IIRC it was you who voted for more frequent releases of LAME versions with minor changes. This won't make the situation easier then. In consequence, add lack of time/resources to that. Would not be a valid point anymore if you changed your opinion here to release really stable versions instead (what may take its time).
So why are there people claiming that your work on alt-presets is totally ignored? Other than the fact it's not defaulted, I do not understand what they would want. The alt-presets are not alternative anymore, they are pushed by the documentation, and the former presets are gone...
Perhaps those people are only a minority and I mainly remember those posts because some where including harsh comments. (yes, it seems that unfortunately I remember more easily harsh comments)
I apologize if my comments came off as harsh. However, there really isn't a nice way to say it. Lame developement lacks focus. Unless acheiving and maintaining superior sound quality gets MADE the top priority, ANY OTHER developement efforts such as new/different platforms are UTTERLY POINTLESS. What good is a *nix version that makes inferior sounding files? Why not just port Blade?
As for the way Dibrom's efforts and suggestions were received, I got the distinct impression that the Lame developers wished he would just GO AWAY. Unfortunaltely for end users, it seems they got their wish.
Imo it does no good to rant here how wrong and awful everything is. I think the points have been made and everybody can read the comments from several threads. Imo it would be now more important to concentrate on what concrete people can do in order to make the situation better.
If some people are not willing to do anything, more ranting doesn't help the situation one bit, instead only make it worse, like I start to see is happening considering Takehiro's comments in the lame-dev mailing list...
No Ogg hardware support yet. Definitely no MPC hardware support. Hard drives not cheap enough to encode 1000 CD's in lossless format.
And now it would seem that the MP3 format is as good as it's ever going to get.
Hmmmm....
Conclusion, this sucks.
Thank you LAME developers for giving us a better choice than Xing. And thank you Dibrom for all of your effort.
Too bad it's all coming to an end.
If some people are not willing to do anything, more ranting doesn't help the situation one bit, instead only make it worse, like I start to see is happening considering Takehiro's comments in the lame-dev mailing list...
I agree, it's beginning to get heavy.
Lame devs this way... Lame devs that way... Why not rather see how to program Lame ? Is the source code difficult to understand ? Are there some docs about the physics needed to understand how it works ?
This way, anyone wanting to improve it and having the time to, can start studying the code. That's why it is "open", after all.
If some people are not willing to do anything, more ranting doesn't help the situation one bit, instead only make it worse, like I start to see is happening considering Takehiro's comments in the lame-dev mailing list...
I agree, it's beginning to get heavy.
Lame devs this way... Lame devs that way... Why not rather see how to program Lame ? Is the source code difficult to understand ? Are there some docs about the physics needed to understand how it works ?
This way, anyone wanting to improve it and having the time to, can start studying the code. That's why it is "open", after all.
I can't really speak for anyone else, but the reason I have made such an issue over all of this is
because I don't understand the psymodel well enough to do it myself. I did as much as I could on my own without really bugging the lame-devs. As I've already said many times, beyond that, the alt-presets need to be focused on by someone who really understands the way the LAME psymodel works. Takehiro was one of these people (Naoki was another, but he's no longer around for some other reason). Unfortunately, for the alt-presets to really live up to their reputation, it takes a certain developmental style and attitude from people, and I don't think I've seen the LAME dev's willing to give this traditionally (I cite the year long wait and the bad 3.93 release as examples).
If people think I'm saying all of this just because I'm pissed off about something and just want to arbitrarily rant about stuff, well they are missing the point and it looks like further efforts to try and change the situation through debate and by increasing awareness will be futile. Oh well...
If people think I'm saying all of this just because I'm pissed off about something and just want to arbitrarily rant about stuff, well they are missing the point and it looks like further efforts to try and change the situation through debate and by increasing awareness will be futile. Oh well...
I'm just saying that it's enough ranting now.. I don't think this kind of approach if continued, helps anymore. The points have been made. Continuing raising the awareness like this does no good anymore, since it would be just repeating the same old things..
Changing the situation needs a different approach now imo..
Open letter to the lame developers (if they read):
This forum (the people runnig it and the people reading it) is the place where your elite work on the lame encoder can be verified regarding quality.
USE it !
It won't do your work any harm if you came here from time to time and say 'Hey, there's a new candidate out for testing at [some URL]. We give you [a time period] to test it thoroughly.'
We would all appreciate this a lot and there are surely enough enthusiasts around to do the testing. If you really don't like this place (Quote: 'HA is rude'), set up your own (I could do this for you....).
This goes out as a plead to not let the good course lame has taken be deviated.
First, deep thanks for the work that has been done so far.
Second, it's valuable to have places where the bleeding edge can be tested. But in a way that's just the tip of the iceberg. Don't lose sight of the importance of having tools that (also) work for a wide audience, (the rest of the iceberg). The presets, especially aps, have made all the difference there.
Also please don't lose sight of the reality of the world out there - people who are still using the 2 year old Blade encoder that comes bundled with mkwACT, or the jukebox they installed a year ago. Or sharing lots of mp3s they created with those encoders. They are churning out a lot a bad mp3s. The presets are what finally is making a dent in that.
I agree, it's beginning to get heavy.
Lame devs this way... Lame devs that way... Why not rather see how to program Lame ? Is the source code difficult to understand ? Are there some docs about the physics needed to understand how it works ?
This way, anyone wanting to improve it and having the time to, can start studying the code. That's why it is "open", after all.
Amen!
*coughs* Now, where can I find docs like these aimed at a geek who's willing to learn, but not a sound engineer yet?
*runs off to download some dev tools and take a look at Lame*
Edit:
Is all the documentation needed available at the Lame site?
And what's a recommended free compiler for Win32?
And what's a recommended free compiler for Win32?
MinGW32 available at http://www.mingw.org (http://www.mingw.org)
I'm very sorry for Dibrom. Many many ppl use the --alt-presets for their encodings, a shame to hear that they aren't really accepted by the lame devs.
Although I switched over to the MPC camp recently , I would like to see lame become a lot easier to use (like oggenc), with only a few quality modes for VBR, and getting rid of the bazillion of psymodels and god-knows-what other switches there are.
Just my 2c
Oh and of course thanks to all who work (or worked) on open source projects like LAME. I have the pleasure to work on one myself right now (eMule), and god knows it's not always a rewarding job
Friends- As an "amateur" user of LAME and the alt-presets, I'm very grateful for all that all of you have done to build and easy to use, effective encoder, share it with us as freeware. I'm also very grateful to be able to learn from all of your invested time and passion and have well-thought out alt-presets. For all of your struggle and conflict, you've produced great benefits for many around the world, and we thank you!
A thought on future directions: Perhaps there are several major subjects of interest that our highly skilled developers and contributors could "cluster" around according to their interests to continue evolving the functionality and presets. It's extraordinary how much you've accomplished in the loosely affilated network to date. Perhaps an approach of using "magnet" projects, perhaps 2-4, around which you could connect more closely, would be helpful. I work in a religiousministry organization with a far-flung worldwide network, and we have found that clustering teams around specific projects and tasks has been very helpful.
Wherever you as a community go with this, thanks again for your gifts to us end-users. And peace to your house in this holiday season.