Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: alt-presets, presets, libmp3lame (Read 4452 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

alt-presets, presets, libmp3lame

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.

alt-presets, presets, libmp3lame

Reply #1 –
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.

alt-presets, presets, libmp3lame

Reply #2 –
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.

alt-presets, presets, libmp3lame

Reply #3 –
Quote
Originally posted by Gabriel
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.


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

Quote
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.


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.

Quote
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.


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.

alt-presets, presets, libmp3lame

Reply #4 –
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.

alt-presets, presets, libmp3lame

Reply #5 –
Quote
Originally posted by Gabriel
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.


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.

alt-presets, presets, libmp3lame

Reply #6 –
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.