Skip to main content
Topic: LAME presets (Read 18974 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME presets

Reply #50
Hi folks!

I would NOT vote dm-standard as the "standard" preset. Standard would probably be what the average user would try first, and I don't think confronting Joe Average with slow encoding speeds and huge files would give a good impression of LAME ("huge" files in comparison to CBR 160 or 128, which Joe Average probably would have been using until he bumps into the new LAME presets).

If all these presets were to be VBR, I would definitely vote r3mix as the standard preset (even if Roel wouldn't like it much ). Quality is very good (and SURELY good enough for Joe Average, if not too good), encoding speed is also damn good, and the file size - for a tolerant Joe Average - is acceptable on "normal" music. But as soon as Joe Average encodes sophisticated music (or if Joe Average is intolerant in the first place), he will get upset about the big files.

So, if not all presets have to be VBR, I would suggest some ABR160-like setting as the standard preset. A well tuned 160ABR mode provides good enough quality for just casual listening through PC speakers anyway, and for Joe Average, it provides good enough quality in any case.
Only... if the standard preset was to be ABR160, where would --r3mix go? It's not good enough for "extreme" IMO (that should be dm-standard), it should be something inbetween standard and xtreme, maybe a preset labelled "better" or something...

The setting below standard (for portable MP3 players for example, as has been suggested many times, or just for those ingorant low bitrate peasants) should be ff123's / Hans' ABR134 command line (I don't understand why, but it really is SO MUCH better than the equivalent CBR128 line, which still is quite good in most cases).

Dibrom's presets should be easy to accomodate - dm-standard would be "extreme", dm-xtreme would be... ummm... don't know, and dm-insane would be "insane".

CBR presets should not be included, surely. That would completely destroy the sense of our mission to stop everybody from using it

Remember, all this is just my opinion. (I don't understand AT ALL why a "standard" setting would have to be transparent, BTW)

CU

Dominic

LAME presets

Reply #51
Word Volcano.

I just think that -standard should target the 192kbs range since it is some sort of a standard bitrate. Also the MTRH speed is important here.

Good to see more opinions on this. After all, WE ARE NOT affected by these decicions. We are very able to make our independent decicions on presets/settings we wish to use. This decicion mainly effects the 1st impression that the John Doe gets when he tries LAME.

LAME presets

Reply #52
I thought maybe some bitrate settings might help. Joe average understands this concept.

A 128, and 160 setting, and THEN jump into dm standard or --r3mix around 192?.

You seem to see alot more higher bitrate files for trade but still the majority is 128 or 160.

LAME presets

Reply #53
Quote
Originally posted by Volcano
I would NOT vote dm-standard as the "standard" preset. Standard would probably be what the average user would try first, and I don't think confronting Joe Average with slow encoding speeds and huge files would give a good impression of LAME ("huge" files in comparison to CBR 160 or 128, which Joe Average probably would have been using until he bumps into the new LAME presets).


First of all, this is exactly why I don't think it is the time to be making decisions about all of this.  The new dm-standard actually uses vbr-mtrh now (yes I've moved it over to that) AND file sizes are going to be smaller, in addition to providing improved quality.  I'm just not finished with all of this yet.  Think "smaller, faster, better"

Quote
If all these presets were to be VBR, I would definitely vote r3mix as the standard preset (even if Roel wouldn't like it much ). Quality is very good (and SURELY good enough for Joe Average, if not too good), encoding speed is also damn good, and the file size - for a tolerant Joe Average - is acceptable on "normal" music. But as soon as Joe Average encodes sophisticated music (or if Joe Average is intolerant in the first place), he will get upset about the big files.


There are many reasons why I think --r3mix is not appropriate for a standard setting.

1.  It has not been shown to be clearly better than 192kbps cbr.
2.  It is not transparent to a large majority of people (let alone the audiophiles).
3.  The maintainer of this switch is unwilling to listen to other people's thoughts and concerns.
4.  Many of the compromises in quality that --r3mix makes are unacceptable in my opinion.  Instead of actually trying to *fix* the problems you just see things like weakening hf accuracy, raising the ath curve, and using weak noise measuring to get lower bitrates.

Quote
So, if not all presets have to be VBR, I would suggest some ABR160-like setting as the standard preset. A well tuned 160ABR mode provides good enough quality for just casual listening through PC speakers anyway, and for Joe Average, it provides good enough quality in any case.


I don't really think this would fly personally.  There are 2 camps of people that comprise the majority of mp3 listeners.  The 128kbps camp, and the 192kbps camp.  160kbps abr appeals to neither of them.

Quote
Only... if the standard preset was to be ABR160, where would --r3mix go? It's not good enough for "extreme" IMO (that should be dm-standard), it should be something inbetween standard and xtreme, maybe a preset labelled "better" or something...


Well as I was stating above.. the new dm-standard will hopefully eliminate many of the remaining weaknesses (slow speed, larger file sizes).  That would basically make --r3mix unnecessary in this situation I think, since the new xtreme or insane would replace probably what you currently think standard would be best suited for.  Besides all of that, --r3mix apparently doesn't want a part of this anyway.

Quote
Dibrom's presets should be easy to accomodate - dm-standard would be "extreme", dm-xtreme would be... ummm... don't know, and dm-insane would be "insane".


It'd be best to just not really guess where they would work at since it is all about to change.

Quote
CBR presets should not be included, surely. That would completely destroy the sense of our mission to stop everybody from using it


I'm not so sure about this.  I'm not advocating CBR, but the idea is to provide quality.. not just some technique which is more often used.  As an example, --r3mix has not been proven to be superior to 192kbps even at a higher bitrate, yet on many occasions it will dip significantly lower in bitrate.  Sometimes nearing 112kbps.  I think in that situation it'd be pretty apparent which file would sound better, especially considering the weak ath curve and noise meaasuring.

Quote
Remember, all this is just my opinion. (I don't understand AT ALL why a "standard" setting would have to be transparent, BTW)


It should be transparent to the "majority", not necessarily to the audiophiles.  The reason is because most of the common users are not going to want to spend the time to find the setting which really provides high quality results (which IMO --r3mix does not) so the standard setting should do this within reason.

LAME presets

Reply #54
Quote
First of all, this is exactly why I don't think it is the time to be making decisions about all of this. The new dm-standard actually uses vbr-mtrh now (yes I've moved it over to that) AND file sizes are going to be smaller, in addition to providing improved quality. I'm just not finished with all of this yet. Think "smaller, faster, better"


Well, if you are able to achieve this, then this is a problem solved. I was only concerned about the bitrate, based on the current --dm standard. If you are implementing MTRH and squeezing the size and it shows good quality, then it should definitely be used.

And there seems to be concensus after all that the -standard should target the 192 range and utilize MTRH speed. I never proposed anything else than just this.

Could you BTW release some pre-alpha compiles of your modifications? I am sure people would like to experiment with them and provide you with feedback on their performance?

LAME presets

Reply #55
Quote
Originally posted by cd-rw.org
And there seems to be concensus after all that the -standard should target the 192 range and utilize MTRH speed. I never proposed anything else than just this.


I'm not "targeting" any specific range.  I'm just trying to get vbr to provide higher quality and basically be more "flexible" in its scalability depending on the difficulty of what it is encoding.

Quote
Could you BTW release some pre-alpha compiles of your modifications? I am sure people would like to experiment with them and provide you with feedback on their performance?


Sorry, but no.  I've only just now switched over to mtrh, and the code I'm working on changes daily, and usually even hourly.  It would be pointless for me to put something out now which would be obsolete in a few minutes.  I'm still very much in the major tuning stages and I won't be releasing something until I know that it works the way I am intending it to in at least the majority of situations.  I do still think that I'm relatively close to being able to release something, but I can't give any firm date.

LAME presets

Reply #56
Hi all,

My idea for 3 sub-groups would be something like this:
--preset-portable-LQ (96 abr?)
--preset-portable-standard (105 abr?)
--preset-portable-HQ  (120 abr?)
--preset-casual-LQ  (134 abr?)
--preset-casual-standard  (164 abr?)
--preset-casual-HQ  (176 abr?)
--preset-hifi-LQ (r3mix?)
--preset-hifi-standard (dm-standard?)
--preset-hifi-HQ (variation on dm-standard?)
--preset-hifi-extreme (dm-extreme?)
--preset-hifi-insane (dm-insane?)
-----------------------------------------

This would satisfy the different users who would opt for LAME and everyone can clearly identify thier user level.  The recommendation in LAME instructions should be for users to attempt to encode with --preset-hifi-standard first and decide if they are comfortable with the bitrate.  If the file is too large, then select a user preset which fits your level of interest.  This is a wonderful preset solution I think. 

I also think the instructions should stress that all presets have very high quality within the user level indicated compared to other mp3 encoders.  IMO, the level of quality that approaches "CD-Quality" is dm-standard.  At least from what the AQ-test indicates.  The second round of AQ-tests may show otherwise due to Dibrom's alternate compile.  May improve quality, may hurt it.

I'd encourage Roel to attempt to adjust his --r3mix preset in the hope to improve quality.  Perhaps try --nsmsfix & Dibrom's upcoming short-block improvement?  Couldn't hurt. 

mp3

LAME presets

Reply #57
What the hell, maybe I'll take a whack at it...

I think mp3fan may be on to something - perhaps presets should be categorized by what you want to do with them. i.e., if you want to put MP3 on your portable device, share it with friends, or archive it for your stereo / headphones. Something resembling this perhaps:

Code: [Select]
voice             (40 CBR -mm)

stream            (56 CBR)

portable          (128 CBR)

portable-HQ       (134 ABR)

share             (164 ABR)

share-HQ          (--r3mix)

archive           (-dm-preset standard)

archive-HQ        (-dm-preset extreme)

archive-madness   (-dm-preset insane)

LAME presets

Reply #58
Greetings all.

The discussions about optimum settings and presets have made me think, and I've posted some of my thoughts at the r3mix forum. However, with Dibrom's latest developments, my comments seem even more pertinent, so I'd like to suggest them here.

I have a strong desire for the default lame behaviour at any bitrate to give the best possible quality. All the long recommended command lines are very useful, but when a user requests that lame encodes a file at 128kbps CBR, surely it should use the appropriate "best" settings by default? This must happen in a way which doesn't prevent more experienced users from tweaking and testing, and doesn't change the meaning of too many existing switches - but I'll come to that in a moment.

Also, Dibrom has proposed a way to interpolate between recommended command lines that seems very sensible. The suggested help.txt file seems to suggest that the dm-preset series will represent almost the best quality possible at any given time. This is in addition to Dibrom's tuned VBR presets.

So, if we agree that Dibrom's ideas for various presets give the best possible quality (with the acknowledgement that much of work upon the CBR and ABR presets/settings has been done by others), I think it is unhelpful to give these presets the nomenculature --dm-preset <whatever>, which is only described using lame --longhelp or lame --dm-preset help. Rather, I think that the presets offering the best quality which lame can acheive should take the command line form...

lame -cbr 128
lame -abr 192
etc etc

...where the user specifies the mode and the desired bitrate, and lame picks the most appropriate (highest quality) settings.

I'm not suggesting this to deny Dibrom his moment of fame, but to ensure that the best settings are used by the widest possible group of people. It's also the accepted path of development within lame - while settings or modules are experimental, the command line switches hint at the name of the author, to differentiate between the new and the existing. When a setting or module is accepted as best practice, it is anonymously incorporated into lame as default behaviour. I think it's time the recommended command lines (which are a long way away from current default behaviour!) are made the default via these new simple presets.

lame -mode <bitrate>
where mode= cbr, abr, or vbr.
cbr = bitrate specified exactly, quality varies
abr = bitrate specified approximately, quality varies slightly
vbr = equivalent quality specified exactly, bitrate varies

So that lame -vbr 192 gives you a VBR file with a quality similar to a 192kbps CBR file. OR a VBR setting which averages (overall!) approx 192kbps. This last point (the choice of meaning for the VBR presets) is debatable. See my post here:
http://66.96.216.160/cgi-bin/YaBB.pl?board...&num=1003648843
for more discussion.

Finally, I've talked repeatedly about "changing default behaviour" without "changing existing commands". This is possible because I think lame -h should say "use lame -mode <bitrate>" or whatever by default, so people use this by default. The existing commands remain unchanged, except that plain "lame" = "lame -cbr 128" not "lame -h -b128".


There are some disadvantages to this idea, but it has the following advantages:

1. You don't need to remember the name of a preset when encoding something out of the ordinary. On this form, I guess most people stick to dm-preset standard or xtreme or variants thereof, so don't worry or even think about the other settings. So why have to scratch your head to rember an obscure preset name when you need a 128kbps mp3 for mp3.com? Just pick the quality and/or bitrate you require, and specify as (in this case) -cbr 128 - and know that lame will do the best it can.

2. It doesn't break current lame behaviour. You can still use all existing command lines, but beginners will be encouraged to start from these presets. Best of all, these presets don't "look" like presets, so if lame -h says "use this setting" people will - you don't need a website to tell people!

3. It offers an easy bridge from CBR to ABR to VBR. By making the command lines look similar, people will be more tempted to use VBR. It also allows us to specify VBR quality is a semi meaningful way, without all the arguments about what is standard, xtreme etc, though I'd suggest named equivalents for some VBR values (see my other post).

Thoughts? comments? flames? Rather than just posting "it's a crap idea" please say why.

Cheers,
David.
P.S. of course people are free to develop and tune their own presets - but I'd suggest that any new better presets should replace default behaviour of the type lame -mode <bitrate> as soon as it's demonstrated to be superior. That's the point in a nutshell - these presets should be the default command line, and they should offer the best possible quality at any stage in development. It's little good tuning VBR new and nspsytune if everyone still uses VBR old and gpsycho!

LAME presets

Reply #59
Hi David,

I actually agree with you on almost all of this.  There has been some discussion on the dev list about this too... here is my stance on the matter.

I very much think that LAME should be pushed in the direction of providing the highest quality possible at given bitrates.  I think this should be made easy.  I totally agree that long draw out command lines can be somewhat unproductive, especially when people don't really bother to test what they pick often times.

LAME should just "work" when you want to encode at a given bitrate.  It should provide you with nearly the best quality possible and you shouldn't even have to think about it.  The entire interface should be consistent.. etc.

However... currently there is still a lot in LAME that needs to be changed before this happens.  On the dev list I have been proposing that the --dm-presets could totally replace the default presets sometime.  At this point things could be renamed, the "dm" dropped, etc.  I really don't care about all of that.

The problem is that this just isn't going to happen like that.  We all (mostly the developers actually) need to decide upon the best route and then go in that direction.  It needs to be an organized and continued effort.. not a fragmented and loosely organized one like much of the development in LAME (no offense to anyone).

I'm absolutely willing to work with people to arrive at that goal, but the one thing I don't think would be a good idea is just to shove the --dm-presets into the current --presets and then just have all these unorganized and inconsistent presets to where nobody would know which would be the appropriate one to use?  Would you use "studio", "cd", "dm-preset standard"??  Which one?  Etc..

So I agree with you on pretty much all of this, but it is going to take more time.  I think that even now there can be more added to the --dm-presets (though not just thoughtlessly).  Very low bitrate presets (<80kbps) could be added for example.  Once all of that is in place though, I think it would be good to just replace the default set of presets entirely..

LAME presets

Reply #60
I definitely agree, those existing --preset switches should be kicked out. Most people would never use them, and they don't provide sufficient quality anyway (I guess?).

While we're at it, my suggestion to clean up LAME: Make sure all the changes also go into the DLL. Just about all newbies will use the LAME DLL, and the implementation of the DLL into most CD rippers is simply a mess.

<ot>

Hey I just had an idea, not even one of my usual silly ones . To make sure LAME is properly implemented in all those CD rippers, why not create something like a "LAME approved" or "LAME compatible" certificate or something? That would mean that

    And no more. That would make any "LAME compatibility certified" ripper absolutely idiot-proof. There should also be a notice that if you want more advanced options, you should use the external encoder (with a link to the online LAME documentation that will exist in a "proper" form one of these days).

    External encoder, another good point. For the external encoder, there should just be a blank field in which you enter the options - if you have the bitrate slider in addition to that, it's confusing.

    I think that would mean great progress in our mission to make LAME more popular and user-friendly. What do you guys think of it?

    </ot>

    CU

    Dominic

    PS: I know the CD ripper programmers won't like the idea of re-coding the entire LAME config menu, but oh well, once it's done, they can be proud of a "LAME approved" CD ripper

LAME presets

Reply #61
Yes,

I think it's time for an overhaul in LAME in regards to "usage".  Simplification is a must.  My idea for user levels makes the most sense as far as I'm concerned.  I haven't read many ideas in this thread that make useful sense to all levels of users except my idea.  Presets aimed specifically at quality levels and user levels.  That's as basic as it gets. 

Sure, you can include something for CBR presets like:  "--preset-CBR 128" and that preset should by default give the user the best commandline tested for each future compile.  For now "--preset-CBR 128" can default to ff123's commandline. 

I simply cannot see the point in calling anything "standard" unless you specify what level of user you're talking about.  "standrard" to some people means "basic" or "average", certainly not words synonomous with "high quality" or "AQ".  Labeling Dibrom's "stardard" VBR preset as "standard" without specifying a user level is irresponsible and confusing.

If anyone has an idea better than clearly identifying "user level" and then "quality level" afterwards, then post it.  So far, I'm only reading posts that argue what "standard" should mean and that is clearly going to confuse people, not symplify the issue.  A "user level" will clearly identify what quality level you're targeting before clarifying anything as "standard".

Understand guys?  If there are going to be universal "LAME-certified" presets, then please keep it simple, but clear enough for all users to understand your intent.  My idea addresses any confusion about quality settings in a direct, easy, and common sense way using generic terms for each preset so that even a dummy can get it right.  Put that in your compile for furture "LAME-certified" programs and you can always change the command line to the newest "winner" with each compile without confusing any users.  Each version will be static on it's presets, but can always be upgradable yet still compatible with "LAME-certified" programs.

mp3

LAME presets

Reply #62
I think 2Bedecided hit the spot - never thought about it that way really. That's a whole lot better idea than a big bunch of lo-fis, portables, casuals, hi-fis...

On the other hand: If we have this Joe Average, the Xing 128 user from Nashville, then if he would use LAME for some reason, he would just go for some of the LAME 128kbps modes. So this approach doesn't really push people to the "right" direction.

LAME presets

Reply #63
I didn't include the word "preset" in the syntax I suggested because I don't want newbies to know they're using presets! Let them just think that the Lame default behaviour is great, and they don't need to tweak it.

This prevents the next obvious question "what command line is this preset using" which is always followed by "Hmm, I'll just add --noshort --nores because it'll make it sound better". ;-)


"If we have this Joe Average, the Xing 128 user from Nashville" then I don't care what he does, because if he's from Nashville then he won't be encoding anything I want to listen to! ;-)

(any more gross over generalisations?)

Cheers,
David.
http://www.David.Robinson.org/

LAME presets

Reply #64
Quote
Originally posted by 2Bdecided
I didn't include the word "preset" in the syntax I suggested because I don't want newbies to know they're using presets! Let them just think that the Lame default behaviour is great, and they don't need to tweak it.


I totally agree with this.  In encoders like MPC you have presets, but you don't actually really think of them as "presets" because they are just presented as default behavior.  In LAME they are not.

I've actually just been spending a lot of time thinking about this lately, and I think I'm going to try to totally rewrite the frontend to LAME to work in this manner.  I'm not sure whether or not anything like this will be accepted by default into the official LAME project (because it would break compatibility with frontends like razorlame), but if not I can always distribute my own version with much more simplified and highly tuned default settings.  I'd also redo the help and remove access to the experimental options.. instead they would just be used when appropriate.

I'm basically talking about doing things like the way newer --dm-presets behave, but without separating them into presets.  Instead you would just type like -vbr normal, -vbr high, -cbr 192, -abr 180, etc.. and it would just "do the right thing".  There would still be certain options but they would be much more simplified, again sort of how the --dm-preset behave.  For example you could specify -vbr normal -fast, or -cbr 192 -hq, etc.  Of course LAME does do some of this already, but much of the use of these switches is deprecated IMO.  So by taking this approach, there would be no more having to think about all of these long and confusing command lines and no more having to worry about people using options which will degrade quality.

LAME presets

Reply #65
Wouldn't it be beneficial to commit most of these changes to lame directly? Disabling switches is clearly a no-no for the main version of lame, but improving the manual would help everyone, and the "presets that don't look like presets" don't clash with what's there already, will they?

I realise you can't just do what you like to lame (i.e. disabling experiment siwtches wouldn't help everyone!), so it would still be useful for you to distribute your own compile. However, I think it would be good to improve the general distribution of lame as much as possible - especially for the up-comming stable version.

Cheers,
David.

LAME presets

Reply #66
Quote
Originally posted by 2Bdecided
Wouldn't it be beneficial to commit most of these changes to lame directly? Disabling switches is clearly a no-no for the main version of lame, but improving the manual would help everyone, and the "presets that don't look like presets" don't clash with what's there already, will they?


Changes that radical to the frontend have probably 0% chance of making it into LAME.  There's been discussion of this and similar issues lately on the dev list and I don't think it's going to happen.  Rather than argue and waste time, I'll just do it myself.  If someone wants to use it then, that's OK.

Quote
I realise you can't just do what you like to lame (i.e. disabling experiment siwtches wouldn't help everyone!), so it would still be useful for you to distribute your own compile. However, I think it would be good to improve the general distribution of lame as much as possible - especially for the up-comming stable version.


To be honest I don't feel like arguing many of these issues with the developers.  Theres been too much arguing about all of these kinds of things lately and not much ever results from it.  There is some opposition from some of the more core developers about how presets should be handled and how LAME should function in general in regards to what I think is trying to be achieved here.  It makes more sense to me to just "get it done" in my own way at least so there is something and then if people want to use it later, that's fine.  I've been trying to point out many of the issues that I think need to be addressed in LAME in general and especially before the coming stable but there doesn't appear to be much support for some of these ideas really.. on the dev list that is.  That's just my interpretation of the situation though..

LAME presets

Reply #67
Quote
Originally posted by Dibrom

Changes that radical to the frontend have probably 0% chance of making it into LAME.  There's been discussion of this and similar issues lately on the dev list and I don't think it's going to happen.  Rather than argue and waste time, I'll just do it myself.  If someone wants to use it then, that's OK.


@#$%! dibrom, do you want to split lame? if all think that it's better to make something in such way why you can't agree with others? many people make lame, not only you.

our dispute is not time wasting, it's the only way how many people could do one business. nobody of us i think have all skills and have time to do this alone, so we must do this together and in piece

it is possibly to make some changes in lame after some discussion, just make such discussion and explain your point of view. this is the only way to make lame better.

you start to look like roel %( he also didn't want to see another people

what is bad 8(

LAME presets

Reply #68
But at times I have sympathy with Roel and/or Dibrom's way of doing things. Whilst it can be seen as being "pig headed" to just do your own thing, sometimes the discussion just goes no where. In that case, there is nothing wrong with saying "I created this for myself - I will release it so that others can use it if they want to. If you don't want to use it, then don't - but please don't hassle me to change it or destroy it because it's how I want it, and I don't have the time (and I never intended) to please everyone"

Sometimes it gets very tiresome to argue your point with everyone. However, sometimes it is necesary and useful. I guess it depends how much time you have, how easy it is to get others to accept your ideas, and how keen you are to see your ideas put into practice.


FWIW I haven't seen any discussion of presets and default behaviour on the mp3 encoder mailing list - is the dev list elsewhere?

Cheers,
David.

LAME presets

Reply #69
Quote
Originally posted by mitiok
@#$%! dibrom, do you want to split lame?


If that's what it takes, then yes.

Quote
if all think that it's better to make something in such way why you can't agree with others? many people make lame, not only you.


The problem is not all people agree.  Much of the online community in these forums are wanting something, they want simplicity, they want quality... and the default LAME behavior is not providing this satisfactorily.  I was attempting to help out with this but much of what I think is necessary most of the developers are not interested in.  For that manner, many of the developers who are making decisions about where LAME should be going in the future do not even participate here and even worse many of them don't really even know what happens here.  A perfect example is some of the comments Alexander recently made.  And now he is working on a non-linear psymodel and he has not done listening tests (at least when he originally posted about it)... I've worked with it a bit and reported my results here on this board but I have not heard anything.  Will this be yet another case where experimental work is added to LAME and then just kind of abandoned?  I'm sorry but it seems to me that when the developers are not working with the users to get this stuff tuned correctly, then it is time to do something.

Now, this is not to say that some people aren't doing great work on this project... they are, and the ones that are improving things are also the ones that are participating this most in these communities.  But the problem now is that the lack of organization and direction in the LAME project is having a negative impact on the community.  Stable releases take too long, options which should be defaulted aren't.  Many of the developers don't even understand the behavior of some of the code they work in regards to what it does to the sound quality in the end result!  I think this is becoming a problem.

When you no longer really work on tuning your project yourself and you ignore those who are doing this and are desperately trying to get you to pay attention... then what's the point anymore?

Quote
our dispute is not time wasting, it's the only way how many people could do one business. nobody of us i think have all skills and have time to do this alone, so we must do this together and in piece


I think you are missing the point.  I've offered to do much of this (overhaul the frontend, make things "just work the right way" in regards to quality, etc).. but there is enough opposition to where I'm losing interest in attempting to "cooperate".

Quote
it is possibly to make some changes in lame after some discussion, just make such discussion and explain your point of view. this is the only way to make lame better.


In the recent discussion I explained my point of view on the presets and related matters about 5 or 6 different ways in long messages.  Then after all of that I see short responses like "well I still think we need to do it this way".. after I've said what I can say and people respond in that manner, how else am I supposed to convince them?  Sorry, but I can't wait forever.. I have other interests that I'd like to get to sooner or later, and if it looks like LAME is becoming a dead end as far as progress (at least in functionality and usability, technically LAME is still improving somewhat, but that isn't the issue here) then I might as well move on.

Quote
you start to look like roel %( he also didn't want to see another people


This is bullshit.  Sorry, but I'm not Roel and I don't like being compared to him either.  I'm trying to work on something here which would only have a positive impact.  How is increased quality and ease of use going to make things worse?  I'm not talking about forcing everyone to use a particular thing or changing the behavior of how their files are written.. I'm talking about consolidation, simplification, and enhancement (as far as quality goes).  These things may not interest you, but according to the people in this thread and what many people apparently want judging by how many use my seperate presets... this is what they want as well.

If there is one thing that bothers me more than anything else, it is when people hold back progress for what I see as little reason.  I think that is the case here, and I feel that was the case on the r3mix.net forum as well (discussions about increasing quality led to flamewars because people thought things were "good enough" and didn't need to be changed, etc.).

Anyway, what I decide to work on is my own business.  If I want to extend LAME I can do just that.  After all, its GPL and it's open source.  I'm sorry but this response, especially the comparison to Roel, really pisses me off.

You'll probably dislike me immensly after reading all of this.. but I'm in this because I'm interested in pushing quality audio encoding further.. I'm interested in progress and the future.  LAME has a lot of issues that need to be worked on.. but if people in control of the project refuse to show interest or are going to oppose that process, I might as well go elsewhere and do it on my own.

In closing, I'd like to ask you something Mitiok.  Since nspsytune and many of these experimental settings were largely ignored by the developers until recent times and none of them were defaulted at all... would you have preferred that it stayed that way and that you would never have gotten the increased quality you likely are now?  Or would you like to see the same progress there adopted more internally into the LAME project?

I know what I'd prefer.. and I think I know what many of the people on this board and even r3mix.net would prefer..

Note:  Again I'd like to emphasize that the statements here do NOT apply to all of the developers.. there has been some very good work from some people, but that does not change the fact that there are still some issues here which are becoming problems, and I think need to be changed.  I'm talking in a more general sense about the way things should be progressing but they aren't.. and if someone is willing to do the lion's share of this, but people are opposing that...

Also, I understand that many people do not have the time it takes to improve LAME to the degree that is sometimes being discussed.. but other people are offering to do this instead.. so its not really a matter of that.

LAME presets

Reply #70
Quote
Originally posted by Dibrom

The problem is not all people agree.  Much of the online community in these forums are wanting something, they want simplicity, they want quality... and the default LAME behavior is not providing this satisfactorily.  I was attempting to help out with this but much of what I think is necessary most of the developers are not interested in.  For that manner, many of the developers who are making decisions about where LAME should be going in the future do not even participate here and even worse many of them don't really even know what happens here.


lame is open source project. the main power of open projects is feedback from the users.

there is a chain developers-->users-->developers

as i understand the main goal of such forums are:
1) help for newbies
2) accomulation of users meanings and sending it back to developers

as i already told you, that would be nice if everyone could do some (may be very small) work for lame, it wold make lame better.

not developers must  participate here, but you must send feedback to developers.

some of developers already told you that they don't have time and ask you to send links to them

developers can't quick make lame better if your make instead right chain such chain: developers-->users-->dibrom

you kill feedback

Quote
I think you are missing the point.  I've offered to do much of this (overhaul the frontend, make things "just work the right way" in regards to quality, etc).. but there is enough opposition to where I'm losing interest in attempting to "cooperate".


lame already has a structure of presets, i f you want to make it better - great! thanks! but at this time as i see you make a bit another thing...

Quote
Sorry, but I can't wait forever.. I have other interests that I'd like to get to sooner or later, and if it looks like LAME is becoming a dead end as far as progress (at least in functionality and usability, technically LAME is still improving somewhat, but that isn't the issue here) then I might as well move on.


open projects can't live without feedback. that's funny that you think that lame is improving somewhat, as i see you don't want to improve lame at all: you make some sets of keys (thanks!) and now say us goodbye.....

well...... goodbye....... it's a pitty......will you merged you version in the future? may i ask you to do this? please.....


Quote
This is bullshit.


ah..... you say that my words are bullshit..... very nice 8(

Quote
Anyway, what I decide to work on is my own business.  If I want to extend LAME I can do just that.  After all, its GPL and it's open source.


yes, you can do it. but if you don't want to work inside lame project, your work will not help lame. so please if you stiill want to cut your work out of lame, could your merge interesting things back in the future?

btw don't forget that you must open your sourcecode.

Quote
I'm sorry but this response, especially the comparison to Roel, really pisses me off.


i may repeat this

Quote
You'll probably dislike me immensly after reading all of this.. but I'm in this because I'm interested in pushing quality audio encoding further.. I'm interested in progress and the future.  LAME has a lot of issues that need to be worked on.. but if people in control of the project refuse to show interest or are going to oppose that process, I might as well go elsewhere and do it on my own.


give me url of your sourcecode and binaries, i'll make a link this may be will help developers of lame project in their work......

Quote
In closing, I'd like to ask you something Mitiok.  Since nspsytune and many of these experimental settings were largely ignored by the developers until recent times and none of them were defaulted at all... would you have preferred that it stayed that way and that you would never have gotten the increased quality you likely are now?  Or would you like to see the same progress there adopted more internally into the LAME project?


nspsytune is buggy. it produces great quality, but it's buggy. it would really great you you fix it and set it as default.

Quote
but people are opposing that...


you start to talk for the people..... nice..... roel made community that like --r3mix, you made community that like --dm-preset........

well..... it's a pitty.... lame didn't become faster after gogo's release, lame will not imrove his quality if you will not put your ego into @$$ and will not go on compromise and split your work

LAME presets

Reply #71
Quote
Originally posted by mitiok

not developers must  participate here, but you must send feedback to developers.

some of developers already told you that they don't have time and ask you to send links to them


I've sent feedback to developers before.  Sometimes stuff gets addressed, many times it does not.  Simply posting on the dev list every time I have some sort of thought about LAME isn't going to change things.  If they developers are interested in improving LAME they need to participate where the discussions about improvement are taking place.  That is if they really want to do this.  When you develop a program it is your responsibility to make sure that you are "doing the right thing" for your users.  Otherwise you shouldn't attempt to promote the idea that you are working for the good of others.

Quote
developers can't quick make lame better if your make instead right chain such chain: developers-->users-->dibrom

you kill feedback


Mitiok... what the hell are you talking about?  Care to enlighten me on how I "kill feedback"?  Lol.. I've probably reported more bugs to the developers in relation to quality than anyone else around here in the past few months.  I'd sure as hell like to know how that equates to me "killing feedback"..

Quote
lame already has a structure of presets, i f you want to make it better - great! thanks! but at this time as i see you make a bit another thing...


I offered to make it better.  I am making the --dm-presets to replace the --presets which will "make them better".  This is how I'm doing it.  Others are not interested.

For that matter.. what kind of response do you think I'd get if I just started radically changing the behavior of all of the default presets?  I'll tell you.. there'd be even more of an uproar then there is now.  I'd have to consult everyone about every little tiny change I'd like to make.  No thanks.

Quote
open projects can't live without feedback. that's funny that you think that lame is improving somewhat, as i see you don't want to improve lame at all: you make some sets of keys (thanks!) and now say us goodbye.....


Heh that's a good one.  Why am I having this conversation here?  Because I am interested in improving LAME.  Can you think of any other reason why I might spend so much time working on all of this stuff?

Quote
well...... goodbye....... it's a pitty......will you merged you version in the future? may i ask you to do this? please.....


Sure.  All you have to do is get the developers to agree to these changes that people are wanting.  But that isn't going to happen, not at the fundamental level that is being discussed here.

Quote

ah..... you say that my words are bullshit..... very nice 8(


You left out the part where you compared me to Roel -- ">>you start to look like roel %( he also didn't want to see another people".  Of course I said that was bullshit.

Quote
yes, you can do it. but if you don't want to work inside lame project, your work will not help lame. so please if you stiill want to cut your work out of lame, could your merge interesting things back in the future?


That's right.  It won't help LAME, but it will sure as hell help the community.  Which do you think I care more about?  An implementation of a program, or the people who use that program?

Quote
btw don't forget that you must open your sourcecode.


I'm a little saddened that you would actually think there was a possibility that I wouldn't do that.  Heh..

Quote
i may repeat this


k.. but note that if you continue to compare me to Roel, I'll continue to say that's bullshit.  All you'll end up doing is pissing me off and causing me to dislike you.  That's your choice.

Quote
give me url of your sourcecode and binaries, i'll make a link this may be will help developers of lame project in their work......


I'm not done yet, but rest assured any changes I make will be open to the public.

Quote
nspsytune is buggy. it produces great quality, but it's buggy. it would really great you you fix it and set it as default.


If nspsytune is buggy, then GPSYCHO is completely unstable.  Nspsytune routinely offers higher quality than GPSYCHO when used correctly (which is all that needs to be handled internally).  I'm not really sure what you mean by "fixing" nspsytune.  You can't really "fix" it, you just improve it.  It should be defaulted and improved upon.  It's already better than GPSYCHO in almost all situations.

Quote
you start to talk for the people..... nice..... roel made community that like --r3mix, you made community that like --dm-preset........


You are quoting my words out of context.  The "people" in question who are opposing these things are not the people in the community.  They are the developers.  I've worked for the benefit of the community when creating the --dm-presets, and once again this current effort is for the community.  These are the "people" who I'm helping.  Look around Mitiok.. look around this board and r3mix.net.  Look at what people are asking for.. simplified presets, higher quality, improved default behavior.  All you are looking at it from is the developers point of view.  I'm looking at it from the communities side, but trying to implement that on the developmental side.  Project Mayhem has nothing implicitly to do with --dm-preset, it has to do with striving for high quality audio in whatever form.  It is not centered around a preset or my name.

Quote
well..... it's a pitty.... lame didn't become faster after gogo's release, lame will not imrove his quality if you will not put your ego into @$$ and will not go on compromise and split your work


Mitiok.. you don't get it.  This isn't an issue of ego.. this is an issue of progress and trying to improve things.

I think I'll add a little example here.  Though admittedly I don't know the whole story.. I have become aware of some interesting happenings in the LAME project not all that long ago.  The Frank Klemm which is now working on MPC and doing such an excellent job was also once a part of the LAME project.  He too wanted to improve many things, and in fact he actually did just that.  As in that case there was opposition to much of what he was doing apparently, and eventually he was no longer a part of the project.  Now when I look at what he is doing with mppenc and mppdec I can hardly believe how he could have been doing something "bad" to LAME.  I don't understand how the project could let someone like this go.

I'm beginning to maybe understand though because I see a similar thing here.  There is a push for higher quality and there are people willing to work with the developers to tune the codec in that direction, but there is much opposition.

Please don't give me shit about my decision to try and improve LAME in the areas I think needs to be improved Mitiok.  At least I'd be working on something and there would be people getting some use out of it.  I have offered to do all of this within the context of the current LAME project but if people are not interested, what else should I do?  Just shut up and do nothing?  Or should I give up altogether and just forget about LAME..

Anyway, what I am mostly talking about here is a change in the frontend of LAME.. a change in the default behavior.  I don't know enough about LAME to make radical changes to the psymodel or anything like that, and I'm not actually sure I'd want to spend the amount of time it would take to learn all of that.  The things I'm looking at maybe modifying here are unlikely to make it back into LAME because these are things the developers do not want to change.

LAME presets

Reply #72
@Dibrom: Maybe I haven't read the last bit of this thread thoroughly enough, but... when are you going to release your own compiles?

@mitiok: You emphasized several times yourself that LAME is an open source project - so why shouldn't Dibrom make these modifications and offer his own thing? I don't see the problem!

CU

Dominic

LAME presets

Reply #73
My 2 cents about all this discussion: (mainly addressed to Dibrom)

First, don't take all this on the personal level.

Lame is composed of two parts: a library and a front-ent (some in fact).
It seems to me that you're not happy with the most common frontend (lame.exe). You're right into the fact that this frontend is full of options that could be useless or quality damaging. You're also right when you say that some default options ar not the best. You want to change this.
Well, I think a lot of people would also like to change this. But the main problem is that we can't change everything. There are a huge number of users using previous versions, and it would cause a lot of troubles to remove some options.
But lame.exe is just a frontend to the lame library (like lame.dll is).

You want to change the front-end, but it doesn't seems that you want to change the library.
So why not creating a NEW front-end?
A more user-friendly one, a more easier one, a one with better default settings.

You could use the current lame front-end (lame.exe) and change it to create "easylame.exe" (or whatever you want).
This way you wouldn't have the annoyance of keeping compatibility of this interface with the current one.
I think it wouldn't be that hard. You could start with the current frontend and heavily change it. (just one thing please: find a name for this one, not just lame.exe)

I really think it could be a nice thing, and I'm quite sure a lot of people would approve. This way it would also be easier to introduce all your drastic changes into the lame frontend. It could also be put into the Lame cvs, we just have to create a new directory into front-ends.

LAME presets

Reply #74
Quote
Originally posted by Gabriel
First, don't take all this on the personal level.


I agree.  This discussion was not meant to be personal, and I hope that nobody takes my statements about the project personally.  I just don't like being compared to other people in a negative manner simply because someone is dissatisified with what I am interested in doing.

Quote
Well, I think a lot of people would also like to change this. But the main problem is that we can't change everything. There are a huge number of users using previous versions, and it would cause a lot of troubles to remove some options.


Yes, I do actually understand this to a degree.  I think that part of the problem with now removing options and having it cause compatibility issues though is due to having such a loose project (organizationally), slow releases, and way way too many options in the first place.  I guess there isn't much that can be done at this point though..

I hope that in the future, extreme care is used when adding new options, especially experimental ones for this very scenario..

Quote
But lame.exe is just a frontend to the lame library (like lame.dll is).

You want to change the front-end, but it doesn't seems that you want to change the library.


Yes, mostly the frontend.  I do think that certain things should be cleaned up in the library itself too though, but thats another matter...

Quote
So why not creating a NEW front-end?
A more user-friendly one, a more easier one, a one with better default settings.


This is what I'm looking at working on.

Quote
You could use the current lame front-end (lame.exe) and change it to create "easylame.exe" (or whatever you want).
This way you wouldn't have the annoyance of keeping compatibility of this interface with the current one.
I think it wouldn't be that hard. You could start with the current frontend and heavily change it. (just one thing please: find a name for this one, not just lame.exe)

I really think it could be a nice thing, and I'm quite sure a lot of people would approve. This way it would also be easier to introduce all your drastic changes into the lame frontend. It could also be put into the Lame cvs, we just have to create a new directory into front-ends.


I guess the question is how much to associate such a new frontend with the existing LAME project.  It's all an interesting thought.. guess we'll just have to see what happens.

 
SimplePortal 1.0.0 RC1 © 2008-2018