[MPlayer-dev-eng] -lameopts: conflicting documentation and code?

[Corey Hickey]

D Richard Felker III wrote:
> On Thu, Feb 19, 2004 at 01:37:57AM -0300, Diego Biurrun wrote:
> 
>>Charles Wilcox writes:
>> > The man page and HTML documentation say that they q= value can be set from
>> > 0 to 9, the equivalent of the same option of Lame.  However, this is not
>> > the case of what happens.  mencoder.c:986 has a line that adds one onto
>> > the value specified before it is sent off to libmp3lame.  This is
>> > complicated by the fact that cfg-mencoder.h:25 says that the input is
>> > indeed in the 0 to 9 range.  Also, the code makes no effort to check to
>> > see if the resulting value is 10, which is an incorrect value to pass on.
>> > 
>> > Considering all the docs imply this option should match up to what LAME
>> > would normally take, could this possibly be a error in the code?  Taking a
>> > cursory glance at the lame code in frontend/parse.c:1626, it does not alter
>> > the value before it calls lame_set_VBR_q.
>> > 
>> > Sorry, I'm just learning how to use Mencoder, but I've used Lame
>> > extensively, and this inconsistency confuses me.  Is there a reason it it
>> > like this?  If so, there is no warning to those who'd assume that the VBR
>> > quality numbers mean the same thing.  (That, and it just doesn't make any
>> > sense to me.)  If this is a mistake... wow, I guess not many people
>> > specify -lameopts to have caught this.
>>
>>Sounds like you found a real bug, could you come up with a patch that
>>fixes it, please?
> 
> 
> IMO this is a difficult issue. I wanted to fix it a long time ago, but
> changing the behavior is not acceptible under mplayer policy afaik...
> 
> Rich
> 

I thought this sounded familiar:
http://www1.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-March/016742.html

For what it's worth, I'd vote for it being changed.

-Corey