At first , a constatation:

Forcing Lame to have some correct defaults settings for every parameter was quite hard, basically because many parameters interfer with each others.
The way it's done with alt abr is quite easy.


So here is what I think:
I 'd like to extend the dm_parameters struct, in order to also control missing parameters, like number of channels or resampling.

Those parameters are importants for lower bitrates. By adding some parameters, it would then be possible to have correct presets from 8 to 320kbps, in an easy to handle way.

Then, once this will be done, I'd like to map the std-presets to some alt-values.
Then promote the alt-presets to presets.

Once this will be done, we could start strongly advising users to use only presets (as in example in Lame manuals) instead of custom command-lines.

This way we'll preserve all the switches for "experimenters", and Lame will have the simplicity needed for the user for the whole range of bitrates.


Then, the last thing would be to create presets.h and presets.cpp, and to move the presets code from the frontend to inside libmp3lame. This way even with the lib or the dll, simplicity and quality will be easy to obtain.

Now, I'd like comments about all this.

It's about time, I think. But more can be done, such as:

Mapping --abr to --alt-preset
Mapping the CBR -b to --alt-preset cbr, possibly adding a --cbr alias
--vbr alias, mapping --vbr 0 to extreme, --vbr 1 to standard.

No, I don't want to map -b x, --abr x or -V x to alt presets, otherwise we wouldn't be able to use them anymore. (we still need them).

But I want to advertise and advise the use of presets against other command-line switches.

I think all of this seems fine. I strongly agree that a more "official" move in this direction is sorely needed.



The only thing I question here is whether it really makes sense to add "standard/extreme/insane" along side the other presets, especially if there is some redundancy there (mapping the alts to the normal ones). I think this may end up in more confusion than is necessary. Perhaps it'd be better to just replace the old presets (in name as well) with the alt presets.



Again, sounds good to me I definitely also support the idea of seperating the presets from the frontend to allow for easier synchronization between the commandline and .dll interfaces.

Well, I'm not sure neither if we should keep to old presets names or no.

Perhaps they could be kept but not documented, or perhaps they could be removed, I'm not sure.

Otherwise it's nice to see that we mainly agree.

Well, you have to think about how are you going to stop people from using the simple default -b, --abr, -V... and convincing them to use the presets instead.

Your barriers are of course the help and the manual, where -b --abr and -V are the first things the user sees. Then of course you have the existing frontends like EAC and RazorLame all providing the -b option to edit.

At this point, I think it'd be nice to have the presets named in the most simple way possible, kind of like MPC does it.

--alt-preset standard becomes --standard
--alt-preset extreme becomes --extreme
--alt-preset insane becomes --insane
--alt-preset <val> becomes --abr <val>
--alt-preset cbr <val> becomes --cbr <val>

By default, if no switch is specified, it would use --standard.

It just seems to me that at this point the "alt presets" are no longer really "alternatives" and more of the mainstream (or should be).

Just IMHO.