[MPlayer-users] [BUGREPORT] Crash when REAL used with any -aop options
The Wanderer
inverseparadox at comcast.net
Mon Oct 25 22:00:55 CEST 2004
D Richard Felker III wrote:
> On Mon, Oct 25, 2004 at 02:19:10AM -0400, The Wanderer wrote:
>
>> D Richard Felker III wrote:
>>
>>> On Sun, Oct 24, 2004 at 03:23:34PM -0400, The Wanderer wrote:
>>>
>>>> soft-clipping parameter doesn't seem to be documented either).
>>>> Either of these could be adjusted to with a little effort, but
>>>> I do think I find the percentage interface more intuitive.)
>>>
>>> but no audiophile would find it intuitive... in fact adjusting
>>> volume in percentage makes no sense because the rate at which the
>>> volume changes will depend on the current volume level. +- 1 dB
>>> is always the same change no matter where you start, +- 1% (of
>>> original volume) is not.
>>
>> That makes sense, yes, and I knew that there are perfectly good
>> reasons for using decibels rather than percentages (although if
>> memory serves, which it may not, the decibel notation allows for
>> less fine-grained control... because -af volume=20 gives me volume
>> comparable to if not higher than -aop list=volume:volume=200,
>> although admittedly it's
>
> 20 dB = 10^(20/10) = 100x intensity
> 200% volume = 2x intensity
Yes, I know that, now that I'm awake enough to think straight. My point,
or my most recent one anyway, was that because it is AFAIK not possible
to specify fractions of a decibel it seems as if the smallest units in
which one can adjust the volume are larger with a decibel interface than
with a percentage interface - which is a somewhat awkward paraphrase of
what I said, that decibels allow for less fine-grained control.
Having said that, I've just tested a few non-integer decibel values with
-af volume, and MPlayer didn't choke on them. Whether or not the
non-integral part made any difference to the output volume, however, I
couldn't tell - although, changing direction in midstream again here, a
quick look at the source reveals that the apparent decibel variable in
af_volume.c is in fact stored as a float.
> btw af_volume's dB->intensity conversion is hopelessly broken right
> now so it's coming out all wrong :(
Yes, I noticed that just now, since -af volume=3 - which I understand
from a little general reading should equal a doubling - produces sound
*much* quieter than does -aop list=volume:volume=200. It takes -af
volume=16 to produce something of approximately the same volume as the
other, and even then a brief 'glance' seems to indicate that the quality
is scratchier (though again that could be due to my speakers).
--
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-users
mailing list