[MPlayer-dev-eng] Re: bogus overloaded quality var for mp3lame encoding

[Michal Seliga]

> Message: 2
> From: Felix Buenemann <atmosfear at users.sourceforge.net>
> Organization: MPlayer Project <http://mplayerhq.hu/>
> To: mplayer-dev-eng at mplayerhq.hu
> Subject: Re: [MPlayer-dev-eng] bogus overloaded quality var for mp3lame encoding
> Date: Wed, 1 May 2002 09:32:50 +0200
> Reply-To: mplayer-dev-eng at mplayerhq.hu
> 
> On Wednesday 01 May 2002 06:22, D Richard Felker III wrote:
> > Overall, this whole situation seems to be entirely broken. These two
> > settings, "VBR quality" and "algorithmic quality", have nothing to do
> > with one another, and need to be configurable independently, so "q"
> > should not control both of them. I'd like to ask permission to fix
> > this, since changes may affect compatibility with old command line
> > syntax.
> >
> > I doubt many people have used CBR so far (especially since it doesn't
> > work with WMP or whatever), so it would probably be acceptable to just
> > make "q" control VBR quality, and mode the LAME algorithm quality
> > setting to another option. But if this isn't ok, how about the
> > following setup:
> IMHO win + cbr has been fixed recently.
  heh, why use cbr if we can use vbr? encoding is faster but size/quality fights against cbr....
> 
> >
> > Have two new separate variables, VBR quality and the other quality,
> > both initially -1. Export them as options so they can be configured by
> > the user. But, if they're still -1 when it gets to time to initialize
> > LAME, initialize them in the old (brain damaged) way based on "q".
> > Make sense?
> no, that'd be silly. Make a new parameter for the algorithmic quality and 
> leave q for vbr quality control.
> 
> -- 

lame has option -q xx for quality and -V xx for bitrate control (-V 0 produces mp3's with bigger average bitrate, -V 4 is default, -V 9 sounds very bad).
Maybe it would be easier to leave -q option as it works now and add -V option to -lameopts?