Version: (using Devel) Installed from: Compiled sources amarok uses a percent value to represent the volume, which has very little meaning. it would be nice, if it would use a dB scale, which is commonly used for describing audio levels for the last about 100 years of audio engineering.
https://bugs.kde.org/show_bug.cgi?id=118302 was the same feature request for amarok 1.4
*** Bug 195558 has been marked as a duplicate of this bug. ***
Created attachment 34341 [details] Patch this patch changes the volume slider to use decibel values from -60 to 0 instead of the percent scale.
Created attachment 34342 [details] Patch cleanup of the VolumeSlider interface
Could some developer have a look at this patch, please?
*** This bug has been confirmed by popular vote. ***
added [patch] to the title and sent to bugs list
It looks nice and technical and scientific (and I personally like it), but this isn't exactly popular among music players. The main problem I see is that the volume scale becomes logarithmic instead of linear, which is uncommon (although everyone knows that it is more natural to human ear and stuff). Also, it could probably bring minor incompatibility somewhere. For the scripts, for example, if they depend on percented volume control. So we'll need to discuss, if this really needs implemented. Seems so, by the look of the votes count. The patches themselves look fine and available for review at http://gitorious.org/~hades/amarok/hades-review/commits/decibels
Probably, some kind of compromise can be consolidated. I say about something like: - use persents in API - to avoid noted incompatibility, - every percent is equal to 0.5db or 1.0db, - in UI show db or % in accordance with (newly introduced) settings' option Edward, Tim, Others, what do you think?
> - use persents in API - to avoid noted incompatibility, percent could be mapped in three different ways: - amplitude factor - phonon's percent scale - mapping to db value because this is quite ambiguous, i would try to deprecate the api. it definitely shouldn't be changed, since that would cause scripts to behave differently than expected, if the mapping would change. i would prefer having a well-defined api and a deprecated one than a single ambiguous one, but well, it is not my project, so i won't have to maintain the code ;) > - in UI show db or % in accordance with (newly introduced) settings' option having a slider from -40db to 0db, a user can _see_ at 50% of the slider, he is at -20db ... if he is not familiar with the db scale, he can use his ears (hear the volume) and eyes (see the slider), no need to use his brain (understand the db scale) i would just use a well-defined db scale and remove the percent, but since i seem to be considered as a troll here, i guess my opinion doesn't count
Tim, why "troll"? Then we are all trolls here :-) In sum, I agree with you absolutely - the only db scale is the best way to my taste.
> Tim, why "troll"? Then we are all trolls here :-) In sum, I agree with you > absolutely - the only db scale is the best way to my taste. when i submitted the patches, people were complaining that db is too complicated for users to understand, that 50% should be half as loud as 100%. since back then most of the amarok devs taking part in that discussion were opposed to logarithmic mapping, db scaling or both, and i was called a troll, i stopped using amarok.
Tim, agree, I also guess developers significantly exaggerate users' foolishness. Repeating my argument from 1.x-related bug https://bugs.kde.org/show_bug.cgi?id=118302 , even AV-receiver's manufacturers use db scale.
I don't know what is db exactly, but scaling is too fast near 0% and too slow near 100% (I use mouse wheel on tray icon).
Is there any progress in this too long standing (starting from 1.4.x) bug resolving?
(In reply to comment #15) > Is there any progress in this too long standing (starting from 1.4.x) bug > resolving? This is not a bug but a feature request. Also, all developers have spoken against this repeatedly, so not much of a change to get this integrated.
Myriam, thanks for the information! It would be very interesting to know arguments against log-scaling. The thing is, all these facts about psychoacoustics are knowm during decades, as well as are in use by almost all manufacturer also during decades!! - starting from log-scaled volume regulator (resitor) in first tube radio receivers ;-) Indeed, I think, it isn't queer thing when programmers are such far from one of acpects of the app under development, so, please, believe me, reality is as decribed above :-) And, please, note, I don't say about dB as UI element. I now say about correspondence between one volume step (be it percent, one wheel click, one LIRC "click" or any othe way to change a volume) and volume changing. Probably some kind of compromise can be achieved, cann't it? I mean a using, say, percents for UI (as is), but internally one percent corresponds, say, 0.5dB (with -inf dB for 0%).
andrew, you won't be able to hear any reasonable arguments against log-scaling. but you can re-read the thread on the amarok mailinglist last year, when i wrote the patch. i haven't read that much ignorance for a long time. i don't mind if developers are not aware of all aspects of their application, but they should at least try to understand the issue. but instead people called me a troll :(
Tim, I still hope, some evolution is possible, and some compromise will be realized and achieved (as far as disregarding of obvious defect is a shame). At least from my perspective, other A2 aspects have evident progress. //-- Probably the main error in understanding the problem is treating it as FE rather a bug. OK, I can add this analogy. Say, let's take a text processor. It is possible to edit, print, copy/paste and all other ops, but in every word each next letter has less font size. Of course, for our eyes it is more appropriate to have the same font size. Exactly the same is for hearing - every volume level step is expected be equal to any other one. But hearing laws are more fundamental - hearing abilities are formed (with that log scaled sensitivity) millions yeas ago (in parallel with human itself), while reading is few thousands year old :-)
> I don't know what is db exactly, but scaling is too fast near 0% and too > slow near 100% (I use mouse wheel on tray icon). Yup, that's exactly the problem with the current volume scale : it is linear, and that makes no sense for audio as you just very clearly observed. Logarithmic scales (which is implied by 'decibels') is the obvious solution, used on all audio hardware since the dawn of ages by billions of users - even though they might not be aware of it, logarithmic scale is what they're using on all volume knobs. It would be a simple fix to apply the suggested patch, both satisfying lambda users and expert users (using replaygain or the likes), but Amarok developers stick to a linear scale, apparently afraid that a logarithmic scale would not be "user-friendly" while the opposite is obviously true. Personnally, like Tim Blechman I eventually just switched to another music player.
BTW, an illustration of linear vs logarithmic volume steps : applying a volume setting to audio data actually means multiplying the sample values by some ratio. Several volume adjustments can be made independantly by several steps in the audio chain without any issue - just like you can multiply a value by various coefficients. With 10 steps in a linear scale, the set of possible ratios is : 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 With a decibels scale (10 steps of -2dB each) , this set would be : 1.000 0.794 0.631 0.501 0.398 0.316 0.251 0.200 0.158 0.126 0.100 (it decreases faster at first, but slower when reaching low values) This sequence is called 'geometric' (while the previous is 'arithmetic'), and is obtained by multiplying repeatedly by one constant (here 10^(-2/20) - corresponding to -2dB). Basically, each added step cuts the sound by a fixed amount (about 20% for 2 dB). So the impression on the ears of decreasing volume by one step is always the same. It never ever reaches exactly zero, but that's not a problem - or the UI can simply add one step past this sequence for the 'zero' value. The requested feature really means just that, changing the set of ratios used by the volume interface. No big deal at all but it seems this request faced lots of misunderstandings by the devs.
One reason mentionned for rejecting change to a dB scale was : "all other music players use a linear scale" (phrasing is mine). It does seem to be the case, but : 1. Foobar explicitly uses dB on the volume slider, winamp provides an option to use a logarithmic scale 2. The fact so many developpers chose the same solution doesnt mean it's the right one - just that they either copied each other, or maybe all skipped classes about exp/log functions, and decibels, when they were young. Audio hardware engineers definitely did attend those classes, and there's simply _none_ that uses linear scale volume. 3. Users of those other music players do complain about the linear scale too. They might not always report it to the devs, but you can read some comments here and there, like http://de.reddit.com/r/programming/comments/b5air/almost_every_piece_of_software_scales_images/c0l1d2r 4. The users don't care about the labelling on the volume scale, be it "xxx%", "-xxx", "-xxxdB"... they just care about its effects being natural and usable.
Might be it is worth to try using a lower log base as a compromise between linear and log scales? However i find one more thing related to this rather annoying. Its is impossible to set up more than 100% of sound in Amarok (and in most other players, except VLC). E.g I would like to listen to the music, but don't want other sounds to disturb me too much. I have to either go through all apps and reduce sound, leaving Amarok at 100%, but thats not comfortable. Another solution would be to reduce master sound level -50% and setup Amarok to play at ~150% level. In the end Amarok would be playing at the same loudness, but the rest of the system is quieter. So if it is possible, it would be great if 80% on dial wold present 100% sound level, while 100% on dial would stand for e.g. 120% or 150% depending on the base of log used. p.s. might be it is possible to make a log scaling as a plugin to Amarok?
Lukas, I hope after a little efforts to dig in the problem, developers wil use world standrad rather some kind of semi-log scale :-) As for > 100% - well, you have digital source, and you can not get more than 100% as far as sound will be absolutlely broken (hard-limited).
It's great irony - A 1.4 fork (clemetine) also uses log-scale (keeping percents for UI) :-)
to add some more confusion: http://www.sengpielaudio.com/calculator-levelchange.htm concerning the percent scale, what should 50% mean? -3dB, -6dB or -10dB or half of the available dB range?
Tim, Of course, "half of the available dB range" (with -inf dB for 0%). I'm sure, "1% corresponds to 0.5dB" is a good scaling proportion. I.e. we have: 100% 0.0dB 99% -0.5dB 98% -1.0dB ... 02% -49.0dB 01% -49.5dB 00% -inf dB (mute) I hope, this table is sufficiently transparent for 2-3 lines patch. At least, at version 1.4.x era I used Amarok with siongle line patch :-) And now - absolutely killing "news". Phonon DOES ALREADY HAVE these dB-oriented API!! From Qt official doc: ""... volumeDecibel : qreal This is the current volume of the output in decibel. 0 dB means no change in volume, -6dB means an attenuation of the voltage to 50% and an attenuation of the power to 25%, -inf dB means silence. Access functions: qreal volumeDecibel () const void setVolumeDecibel ( qreal newVolumeDecibel ) ..." Is A2 team aware of Qt doc? ;-)
> Of course, "half of the available dB range" (with -inf dB for 0%). I'm sure, > "1% corresponds to 0.5dB" is a good scaling proportion. I.e. we have: a dynamic range of 50dB seems reasonable > And now - absolutely killing "news". Phonon DOES ALREADY HAVE these dB-oriented > API!! From Qt official doc: > > ""... > volumeDecibel : qreal > This is the current volume of the output in decibel. > > 0 dB means no change in volume, -6dB means an attenuation of the voltage to 50% > and an attenuation of the power to 25%, -inf dB means silence. > > Access functions: > > qreal volumeDecibel () const > void setVolumeDecibel ( qreal newVolumeDecibel ) > ..." my patch uses this api. > Is A2 team aware of Qt doc? ;-) i cannot comment on that, but it seems, they are a victim of the loudness war :/
Myriam, BTW, what does VLO priority mean? This page https://bugs.kde.org/page.cgi?id=fields.html#priority doesn't say about any priority levels other than P1-P5. Are there still reasons to block this bug resolving at situation when last one doesn't demand any developers efforts (as far as qt has appropriate volume-related methods variants) and the bug is one of the most voted ones?
Please read comment #16. That is not going to change.
wrt comment #16 - there isn't still published any reasons/arguments why those developers can not read at least this *bug* page which contains sufficient information about psychoacoustics (or to read *any* literatute about human listening). I don't say about such simple and obvious thing like own experience of *any* not-deaf man on the Earth :-) So, as I can see, developers have reasons, and last ones: - are secret, - have nothing with human listening nature. It is the only case I have met in open source world, during many years having single boot Linux, when developers are such deaf to feedback. There are, of course, cases, when, say, developers have not time or experience to deal with this or that problem. But I don't remember other cases when developers even don't accept such obvious bug existance itself. Sorry, it is a shame. It is in contrary with common OSS soul and practice. The only reason I can suspect, there are some politics-marketing reasons (shadowed from to be opened) to insist on keeping of obvious defects.
to add some oil to the flamewar ... during the linux audio conference, i had a brief discussion with lennart poettering, the developer of pulseaudio ... he suggested using a piecewise cubic mapping, and pointed me to a page of the pulseaudio wiki [1]. while i do not completely agree with him, his approach is way more reasonable, than what is currently implemented in amarok! after 10 years of using linux and contributing to several projects, i have _never_ received so much ignorance as from the amarok devs responding to this bug/feature/whateveryouwanttonameit. [1] http://pulseaudio.org/wiki/WritingVolumeControlUIs
Tim, Ufortunately, the situation takes place not for this bug only. Say, this one is also long standing, high voted and ignored: https://bugs.kde.org/show_bug.cgi?id=229452
hm ... from my limited experience with color skinning it seems, the amarok devs spent more time managing bug reports than to fix them ... it would surprise me, if the skinning code, fixing that bug would exceed 10 lines of code
It has been explained over and over again, the mailing lists are full of it. Closing. Do NOT reopen this report, it will be closed again without comment.
Myriam, Unbelievably! Thanks for the bug resolving! Can you, please, point us to those mailing lists' discussions?
Well, the amarok@kde.org and amarok-devel@kde.org archives are public.
(In reply to comment #35) > It has been explained over and over again, the mailing lists are full of it. http://search.gmane.org/?query=decibel&group=gmane.comp.kde.amarok.devel shows me 28 posting, all amarok-related postings were part of the `db volume scaling' thread. it is a nice source to read, if you want to read how people ignore psychoacoustic. apparently NO developer did a single comment about psychoacoustic. i guess it is more fun to call peoples `troll', than to read wikipedia pages or books about psychoacoustics. or even better, go to a quiet room with good speakers and listen themselves. sure, users won't need to know about logarithms, because their ears do. comment #14: > I don't know what is db exactly, but scaling is too fast near 0% and too slow > near 100% (I use mouse wheel on tray icon). myriam, you probably have a better overview of the amarok lists, please post some more specific links, where `over and over' is.
wrt comment #37 Miriam, I have found this thread: http://thread.gmane.org/gmane.comp.kde.amarok.devel/14552/focus=14581 I hope you mean just this one. I have not found any arguments against using of db-aware volume-related functions. There are arguments against using 'dB' to "fool users" in UI. There were suggestions to use % for GUI and dB for leveling. And comment #27 says about the same compromise. Still I have not found any arguments against this compromise. So, closing the bug isn't more rather than emotional act. The compromise *will* close the bug. Please, reopen.
How difficult is it to understand that it is NOT possible to implement a valid dB display in Amarok for 3 reasons: KMix Phonon backends Alsa Document yourself about the technical limitations before you call Amarok developers names and ignoring psychoaccustics. Also most of our users simply don't understand a dB display, not everybody is interested in reading tons of documentation about it because it is to technical for most people. Read ALL the threads in the mailing lists, you can go back as far as 6 years, it comes up with a big regularity and the developers will not implement it, same reasons give over and over again. Now move on.
Miriam, Sorry, did you read above message? Did you read that mailing list thread? Must I cite own message just posted? "There were suggestions to use % for GUI and dB for leveling. And comment #27 says about the same compromise. Still I have not found any arguments against this compromise." Do *You* understand the technical background of a theme we are talking about? Are you aware of what does mena "linear" for our ears? I'm all in doubt... Yes, my English is ugly. But "How difficult is it to understand that" comment #27 ? I mean: "... "1% corresponds to 0.5dB" is a good scaling proportion. I.e. we have: 100% 0.0dB 99% -0.5dB 98% -1.0dB ... 02% -49.0dB 01% -49.5dB 00% -inf dB (mute) ..." There are no any relation with ALSA at all (as far as Phonon is abstracted from ALSA) as well as with KMix - it is possible KMix isn't used at all. And as for Phonon - must I cite own messages more and more? Again, let's see comment #27 : "...Phonon DOES ALREADY HAVE these dB-oriented API!! From Qt official doc: ""... volumeDecibel : qreal This is the current volume of the output in decibel. 0 dB means no change in volume, -6dB means an attenuation of the voltage to 50% and an attenuation of the power to 25%, -inf dB means silence. Access functions: qreal volumeDecibel () const void setVolumeDecibel ( qreal newVolumeDecibel ) ..."
myriam, > How difficult is it to understand that it is NOT possible to implement a valid > dB display in Amarok for 3 reasons: > KMix > Phonon backends > Alsa great, that we can talk about _technical_ issues! as you probably know, decibel describe a ratio. no one ever proposed to display any kind of sound pressure level, sound power level or sound intensity level. all we are talking about is relative level to the unit gain. > Document yourself about the technical limitations before you call Amarok > developers names and ignoring psychoaccustics. btw, if you have a look at my patch, you can see, that it uses a phonon function, called `setVolumeDecibel'. > Also most of our users simply > don't understand a dB display, not everybody is interested in reading tons of > documentation about it because it is to technical for most people. reading comment #14, someone complained about the resolution of the scale, not knowing anything about decibel and logarithmic mapping. > Read ALL the threads in the mailing lists, you can go back as far as 6 years, > it comes up with a big regularity and the developers will not implement it, > same reasons give over and over again. Now move on. great, now please answer two final questions: - what is the technical limitation, that makes it impossible to implement a logarithmic scaling? - what is the technical limitation, that makes it impossible to use decibel? i have done both many times and have used software, that does both.
(In reply to comment #40) > How difficult is it to understand that it is NOT possible to implement a valid > dB display in Amarok for 3 reasons: > KMix > Phonon backends > Alsa > Document yourself about the technical limitations just as a side note. with the pulseaudio stack, you are able to control the volume of the complete audio pipeline: http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes with a decent phonon/pulseaudio integration, even from within amarok! myriam, it would be nice, if we could discuss the technical limitations, that you see, but i don't. maybe you see more than me, or i see more than you. one of us could get some insights, though
No, discussing the technical limitations is useless and you would have to do this with the developers (which I am not), since the main reason this will not get implemented are the end users. As I said, most people simply don't understand dB. The developers decided not to implement it, period. It is useless to discuss this, the decision stands since years and the core developers will not change their opinion any time soon.
(In reply to comment #44) > No, discussing the technical limitations is useless and you would have to do > this with the developers (which I am not), well, you started telling me about technical limitations ;) > since the main reason this will not > get implemented are the end users. As I said, most people simply don't > understand dB. there are two points. db units and logarithmic mapping. while you think, that people are too stupid to understand db, their ears may still prefer a logarithmic mapping (comment #14). when driving a car, you don't need to know, how the gearbox works nor which units they use for transmission ratios, but you still want the manufacturer to provide a car with reasonable transmission ratios. if i have 4 gears to drive on the highway, but only one gear for driving in the city, the ratios are wrong, no matter how the gear works or what units they use!