[MPlayer-dev-eng] What is odml good for??

The Wanderer inverseparadox at comcast.net
Sun Jan 23 09:26:16 CET 2005

The Wanderer wrote:

> Reimar Döffinger wrote:

[about my objsctions to the 'volume' audio filter]
>> So the main problem is the crackling? Maybe you should enable
>> soft-clipping then? No idea, but the software volume control seems
>> to work fine with me. Well, you can use pre6 to test, it still has
>> the aops ;-)
> That and my philosophical differences with you about where the
> default "unchanged volume" should be, but that wouldn't interfere
> with my own ability to use the plugin.
> I seem to remember having tried various different combinations and
> not succeeded in getting anything acceptable... but the details
> escape me, so I suppose I'll have to try it again when I'm up to
> concentrating that much on something non-frivolous.

I've finally gotten around to doing some tests, and in current CVS the
functionality of the audio filter is almost completely satisfactory I
don't know what's different, but I no longer notice any distortion) in
all but one way: the maximum volume which can be achieved with a given
softvol-max setting - and hence initial position of the volume bar - is
far too low.

With the audio plugin, the default "unmodified" volume is at
approximately 9/23 of the bar, and raising it to 100% produces at least
a doubling in the volume - about what you'd expect. With the audio
filter, when softvol-max is set to 255 (so that the default "max volume"
is at approximately the same point), raising the volume bar to its
maximum produces what as a subjective estimate I'd gauge to be about
130% of its initial level. In order for the maximum volume (and, by
association, volume increase) obtained with the filter to be comparable
to what I get with the plugin, I need to set softvol-max to somewhere
between 800 and 1000, which results in the initial volume-bar position
of approximately 3/23 - down by a factor of three from its former

(The "volume" numbers below are subjective estimates. If anyone knows of
a handy way to measure them more objectively, I'd be glad to hear it.)

With the plugin:
volume at max / unmodified volume ~= 2.5
max position / initial position ~= 23/9 = 2.555555...

With the filter, approximating the same initial position:
volume at max / unmodified volume ~= 1.3
max position / initial position ~= 23/9 = 2.555555...

With the filter, approximating the same maximum volume:
volume at max / unmodified volume ~= 2.5
max position / initial position ~= 23/3 = 7.666666...

This hardly seems either sensible or intuitive to me; it would seem to
make sense that the two numbers should match. With the volume plugin,
they do (did). With the volume filter, they don't. I'm not sure if this
is a large enough change to call it "not equivalent functionality", but
it's certainly enough for me to find aggravating. (Somewhat inflammatory
paragraph snipped (but archived) on the grounds that it isn't worth the
possible repercussions.)

I'd like to be able to keep the volume bar's initial position at about
the same place it was with the audio filter - but it is much more
important to be able to raise the volume by a sufficient amount. The
trade-off in irritation (viz. the annoyingly low initial volume-bar
position) and convenience (at least half again as many keypresses to get
to maximum volume) seems minor, but - in part, perhaps, because of the
degree to which I have been invested in this argument - is, as I said,
aggravating enough that I'd seriously question whether or not the result
is actually worth it.

       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.

More information about the MPlayer-dev-eng mailing list