Yes, please don't change the current set of options. Rename "lame" if
you do something that drastic. :-)
Instead, perhaps we could migrate to a new set of options that is easier
for novices to understand at the command line. Then we could slowly
deprecate the options we have now. This could be more useful and less
"geeky" for everybody in the long run. It could also turn out to be
more versatile for the developers.
I doubt users care about the internal machinery of lame, i.e. whether
the developers are counting backward or forward from some internal
state. My guess is that most users care about lame's MP3 output and how
to get that output in an understandable fashion as easily as possible.
Since only three "highq" or "quality" settings are really available now,
why not do something like this:
--qual low equivalent to highq=9
--qual normal " " " 5
--qual high " " " 2
The option could be lengthed to "--qualty" if necessary. When new
internal numerical settings are made available then new modes, like
"very high", could be added. This would better preserve the intent of
the command over time than the present system.
When using variable bit rates, I think users (well, at least myself) are
concerned with "centering" VBR around the constant bitrates that are
well known to them. For example, now I have to use the following:
-V3 -b160 -B320
when it might seem more obvious to do this:
--vbr 192 --min 160 -max 320
As a "vi" user I certainly appreciate the brevity of the former, but as
a human perhaps the later is preferable. :-)
Anyway, I welcome your comments.
On Tue, Feb 01, 2000 at 04:34:33PM -0500, Jeremy Hall wrote:
> I disagree. From a functional standpoint, changing an option to cause it
> to do the exact opposite of what it once did is confusing at best, and
> disrupts expected behavior. People upgrading from one release to another
> will find that their "great" sound mp3s will now be horrid, and their
> horrid ones will sound great. A drop-in replacement for lame will do
> different things.
>
> I have no problems with adding new options, but changing existing options
> is a bit rough.
>
> In the new year, Greg Maxwell wrote:
> > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> > > but then you're in conflict with VBR.
> >
> > VBR should be changed. It makes more sence for big numbers to denote
> > bigger bitrate in VBR.
--
Don Melton
mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
