Currently, amarok handles volume via :
uint Engine::Base::m_volume
which is a number in 0..100.

before passing it to the engines, that value is tweaked thru the function Engine::Base::makeVolumeLogarithmic :

[code:1] // We\'re using a logarithmic function to make the volume ramp more natural.
return static_cast( 100 - 100.0 * std::log10( ( 100 - volume ) * 0.09 + 1.0 ) );[/code:1]

And engines then apply another, ad-hoc transformation to process that number.

I don\'t think at this point anyone could give a formula explaining how modifying m_volume affects the final, actual output sound levels out of his head, and that\'s a problem :
1/ for users, who can\'t have precise, calibrated control
2/ for developpers, because if a parameter doesn\'t have a clear precise real-world meaning, it becomes more prone to parameter specs mismatch, unless its meaning was precisely spec\'ed - and m_volume isn\'t.

as of now, I see 2 examples illustrating how the latter point hurts development :
- amarok_replaygain.py : do a search for \"calibration\". this hack took unnecessary effort from the author, and is very fragile. (as soon as someone comes up with a more \"natural ramp\"-ish magic formula, those calibration values will be off)
- the bug where activating EQ makes the sound much lower probably has some cause in a lack of documentation of the engine EQ API, but it would be a lot easier to track and fix the mismatch if amarok had a clear volume scale standard to start with. Actually, I\'d be surprised if the bug is just the engine\'s API EQ expects a gain (in some forms of decibel) somewhere, but is given an attenuation factor.


Imho, the volume setting would be best made a double, holding the gain in dB. Then it would be each engine\'s job to apply that gain, translating it as needed into its own volume system (to the best of my knowledge, in the final steps all engines apply \'volume\' changes by multiplying the output sample levels by an attenuation factor, which is related to the gain in decibels by the usual formula :
attenuation_factor = pow(10, gain/20)
gain is usually negative, so the result is usually <1, whence is an attenuation rather than amplification - amplification is to be avoided in the digital world)

the GUI side of things just needs to translate its 0..100 range to a proper gain range, like -50dB 0dB (=>increments of 0.5dB, barely audible). in other words, process the slide value into a gain via :
gain = (percents -100)/2

fixed decibel increments is the most natural way to handle volumes. In fact it\'s the way all audio appliances handle it (even when it doesnt explicitly labels in decibels, volume knobs are following the decibel logarithmic scale)

Audio guys will love seeing volume labeled in dB, since the meaning of their volume changes will be instantly clear to them.
Other users might not be familiar with decibels, but
1/ the slider still is visually obvious, whatever the label
2/ they won\'t take a long time to remember that \"0 dB\" is the loudest value, and then \"-10 dB\" is less loud, and decreasing values even less loud.

I downloaded amarok1.4 from svn yesterday, and modified a few lines of enginebase.cpp and gstengine.cpp (I avoided replacing uint parameters with double in order to minimize changes)
Then I monitored the output from my card with a VU-meter : it works. each increment on the slider actually translates into 0.5dB.

I\'m certain the other engines could be updated in the same way.

So, any chance of adopting decibels ?

update : I posted comments on the related bug/wish
http://bugs.kde.org/show_bug.cgi?id=118302

it has been closed with \"wont fixed\" but since the devs lacked knowledge on the subject I believe it should be reopened.

I attached a patch to the bug report, modifiying the xine and gst engines so they translate the volume percents into decibels, if anyone wants to try for himself..

SamSam wrote:

it has been closed with "wont fixed" but since the devs lacked knowledge on the subject

Harsh call. You\'d probably find that I know quite a substantial bit about logarithmics, gain, transfer functions and decibels, if you bothered to talk to me.

seb wrote:

SamSam wrote:

it has been closed with "wont fixed" but since the devs lacked knowledge on the subject

Harsh call. You\'d probably find that I know quite a substantial bit about logarithmics, gain, transfer functions and decibels, if you bothered to talk to me.

I didn\'t mean to be condescendant or anything, in your post (I\'m assuming you are Seb Ruiz) you seemed unaware that decibels were used in audio for something else than measuring actual, physical sound levels :

Seb Ruiz
dB calculation requires the value of outputted power

there you were speaking of what sometimes is refered to as dBSPL : the actual, absolute, Sound Pressure power.
I agree, it\'s what people usually think of when they see the word decibels.
But decibels are first a way to express a ratio, intrinsicly a relative value, and thus suited in any link of the audio chain as a way to express its (own) gain.

Your reply seemed unaware that this use of decibels was common, and very practical, in many audio apps/devices. I didn\'t mean anything else.

or maybe you were just unaware that the engines\'s volume setting effect on gain are known and can be quantified in order to set them according to a desired gain result.

Anyway, your reply didn\'t have all the facts, and as you implied in your final lines of the bug report that\'s ground for reopening :
"maybe somebody has a better argument for/against"
So, what do you think of the arguments I stated ?

Sorry again if my initial phrasing was blunt, "lacked knowledge" was merely the shortest expression I could come up with at the time, the harshness was unintended - english is not my natural language and at times I overlook nuances of phrasing.

-- Sam

That is okay, the internet is a poor medium for communication most of the time anyway!

My argument is, as simply and bluntly as can be put: The application should not require the user to understand, know, or care what decibels are to change the volume to a value which they care about.

seb wrote:

That is okay, the internet is a poor medium for communication most of the time anyway!

My argument is, as simply and bluntly as can be put: The application should not require the user to understand, know, or care what decibels are to change the volume to a value which they care about.

I agree with you users should not be required to care/know about decibels, I realize amarok is aimed at every human being capable of using a computer.

But anyone can use a volume slider, be it labeled in %, decibels, or chinese numerals ! (I mention it because for a few months my TV app, xdtv, was printing volume changes on the OSD in chinese characters. I couldn\'t even read a single digit, and there was no other visual cue. yet I managed pressing + or - till it was loud or quiet enough...)

amarok\'s volume slider is pretty good on its own as a visual cue.
Number labels don\'t matter much, I don\'t understand why you think adopting decibels would require the user to care about them.

A user can live with ignoring the quantitative meaning of decibel-related numbers just as easily as he currently ignores the meaning of the volume numbers now in use !

Or are you specifically concerned about presenting a scale which has negative numbers to the users ? maybe *that* could go against the least mathematically-enclined of the users..
but :
1. I\'m not sure that\'s really a problem. human beings are supposed to adapt, there\'s a middle ground between over-simplification and being elitist. I believe letting everyone see a volume scale that uses negative numbers is safe, and educational. I mean, what\'s the worst that could happen ? No one has ever been lethally injured due to exposition to negative numbers (that I know )
2. the U.I. can be made to translate gain decibels into a positive scale (- *if* it is decided we need to avoid negative numbers). IMO it\'s a subject for debate, not a reason to reject a decibels scale altogether.

in brief, I see things that way :
- most users don\'t care, and will use a decibel-scaled volume slider just as well
- audio savvy users care, and would much prefer decibels.

on the users side of things, it\'s already a win-win for decibels.

And the arguments I gave about how choosing a clear volume specification helps development are very real.
One more example of that : implementing natural crossfade steps become a trivial task when you can set a volume in decibels..

I really find decibels a clear win. Is there any chance I can convince you ? I\'d rather know before I write pages studying all the implications on the state of the world from amarok adopting decibels