Originally posted by Gabriel 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 know it .. call it BLAME (as in Better LAME or Beginners LAME) Originally posted by Dibrom 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.. This is partly a problem but also the beauty of LAME. Most "arbitrary" settings in LAME can be tuned from the outside. I seriously wonder if you would have become interested in tuning LAME if it didn't had all these switches? The downside is clear: it takes knowledge, testing and good hearing to use all that for the better. The real development and experimental switches should maybe be hidden in a "stable" or even an "beta" version. It would not be so hard to make a compile time setting like -D DEVELOPMENT_VERSION to be set in the Alpha versions and removed in the finals (just a lot of #ifdefs in the frontend must be added) I, for one, think at this point that I would prefer a version with optimal defaults (as you propose and have provided with the dm's) but with the possibility to overrule them if I want to. Some decisions when defining a preset are arbitrary, it may depend on the sample, the listener and the listening environment. I could for example do with lower lowpass values most of the time. For some music (at let's say 128kbs) you might need --ns-bass -8 , for other music -4 is ok. Just a thought, Ge Someone.