Bug 81661

Seconded.  amaroK should honor RVA tags - using normalize to set RVA tags is the best way to normalize music volumes.

*** Bug 88864 has been marked as a duplicate of this bug. ***

I don't think this suggestion is the right way to add mp3 replaygain support.

1. normalize's algorithm don't use the right statistics to caracterize "how loud" a song sounds. 
Thus adjusting gain based on the results of this algorithm doesn't make files sound as loud as each other. It may help a little, or it may make things worse in some case.
The "replaygain" algorithm is much better designed for this task.

2. replaygain tags
few linux programs are based on this suitable "replaygain" algorithm. The only one I know is mp3gain (has a debian package).
When called as
mp3gain *mp3
it calculate tracks' and whole album's suggested gains, and store those in tags.
Problem : it uses "APE2 tags", supposedly more flexible and easy to program, and this seems to be the norm among the rare "replaygain-able" players.

TagLib is planning on supporting such tags in the near future (as well as other possible replaygain tags - lame tag, RVA2, ..)

It seems to me the right way is to wait for that to happen and then make use of the replaygain info via TagLib.

Oggs make use of vorbisgain.  As someone with a 100% ogg collection, I'd love to see Replaygain support right now. 

Ogg tags are standard, so should be trivial to read and make use of for setting volume. 

-Z

Flac uses ReplayGain, too. Support for ReplayGain for .ogg, .flac,... would be very great!

For people who don't want to run these tag-creating utils over their collection (or, more likely, who add to their collection frequently but only remember to do this step infrequently) it'd be nice to have the option to do this automagically -- scanning ahead the next several songs and calculating the gain preemptively.

Yeah, we need volume normalization.  I don't mind if ReplayGain, normalize,
whatever...

Yes, please support replaygain. I dont want to hardnormalize my music. replaygain is just so phantastic, i can scan my collection, let the tools set the track and album gains and everything is fine (and sounds a lot better then normalize). I think that it is easily to implement. 1. Load the tags 2. have a "normal" soundvolume in amarok 3. scale normal volume to real volume like this: http://replaygain.hydrogenaudio.org/player_scale.html

This has my vote too. I mean Replaygain here, as it does not "break" intended volumes in songs/albums as normalizing does.

On a sidenote: some applications ignore meta-tags, and create text-files to store the information. I don't know which ones, but I have two albums on my HD that have these files. Here is one as example:

[cd1] cat ReplayGain\ --auto.txt 
   Level Adjustment   |   Peak Level   (Adjst)|  Filename
----------------------+-----------------------+-------------------------------
 +0.00 dB => -5.39 dB |     0 => 32901 (17689)| 01 - Frail (You Might As Well Be Me).mpc
 +0.00 dB => -7.48 dB |     0 => 35479 (14995)| 02 - Great Ocean Road.mpc
 +0.00 dB => -8.49 dB |     0 => 36021 (13553)| 03 - Rescue Me.mpc
 +0.00 dB => -6.19 dB |     0 => 33453 (16403)| 04 - My Electricity.mpc
 +0.00 dB => -8.12 dB |     0 => 36163 (14199)| 05 - Liberty Bell.mpc
 +0.00 dB => -7.62 dB |     0 => 34453 (14329)| 06 - Red Is A Slow Colour.mpc
 +0.00 dB => -2.51 dB |     0 => 32881 (24628)| 07 - The Big Sleep.mpc
 +0.00 dB => -3.25 dB |     0 => 33491 (23037)| 08 - Marooned.mpc
 +0.00 dB => -7.16 dB |     0 => 34139 (14971)| 09 - Travel.mpc
          => -7.37 dB |       => 36163 (15479)| 

Excellent choice, How to measure a planet is a fantastic album :)

I'd really like to see Replaygain support in amaroK too

We have plans to add ReplayGain support for 1.3. See this document, and feel free to add information:

http://amarok.kde.org/wiki/index.php/ReplayGain/VorbisGain_Support_-_What_Would_it_Take%3F

Would it be possible to provide an update on the status of this.

I am trying to collect some pledges to create a bounty to see if if any devs 
would be interested in coding this feature for cash.  I am willing to put up 
$150 myself.

*** Bug 90575 has been marked as a duplicate of this bug. ***

Automatic volume normalization, by any means necessary, is very much needed. I find myself adjusting the volume as much as 40% between songs when not playing songs from the same album. I don't have any preference as to what mechanism is used, so long as it is either

1. Automatic and Cached (done for the song when it plays the first time, and then saved somewhere, so I don't take a performance hit each time I play that song)

or

2. Semi-Automatic and Available through amarok (I set the normalization once and it's saved, and I don't have to use some external program) 

One of the nicest things about amarok is that I can do 95% of what I want to do with my music files automatically or through the Amarok GUI. Generating the volume normalization outside the GUI would be a big wart.

May be you are not aware of the replaygain script:
http://www.kde-apps.org/content/show.php?content=26073
It does mostly what you need, and generating the normailzation from the gui is just a matter of time (it is in the todo list)

The replayggain script works ok, but I hate the lag it has when a song plays before it changes the volume...

Also, I'm thinking about writing a script for amarok so you could right-click a song on the playlist and say "mp3gain it" or something, that would help with new songs.  I don't ever code so progress might be slow but I will try.

The lag issue is something I'd like to have more information about. It seems distribution related. On my system (SuSE) it is almost unnoticeable (about 0.1 secs or less), while I have a couple of reports from similar hardware specs running kubuntu where they have large delays (~1 sec). It may be some library, I guess. 
An easy workaround is using crossfade, taking a time 1.5 or 2 times longer than your delay.
About of applying replaygain from the amarok gui, the 0.8.0 script's release is almost ready and will be out soon. This release has what you are asking for and much more, but if you are impatient you may download it from svn.

"The replayggain script works ok, but I hate the lag it has when a song plays before it changes the volume... "

This is exactly my problem, too. It's very annoying when a song starts very loud and then turns volume down.

I have a lag around 1 second.

System:
amarok 1.4.0a
xine output
replaygain script v0.8.5
KDE 3.5.2
Slackware 10.2/current
Kernel 2.6.16.16

Dual AMD Athlon 1.6 GHz (SMP)
2 GB Ram

Please, please, please, if you do this, make it an option!! I use FLAC and digital passthrough from Xine -> Alsa -> my receiver to avoid messing with the digital data from my original CDs. I don't want this "feature" imposed on me. If it's an option, great. If it's added and not an option, I have to strip out these tags from my whole collection.

I don't think this bug should even be open anymore.

Eric -- ReplayGain functionality is provided by the ReplayGain addon script (which you can disable).  Although you should probably be aware that all it does is change Amarok's volume (it does not modify the audio data itself), so I don't think you'd have to worry *too* much about quality loss.  But I don't know anything about the internals of the volume control, so ... ::shrug::

I disagree -- this bug definitely should still be open.  While the addon script is much better than nothing, it is definitely a stopgap measure:  most significantly, as previous commenters here have mentioned, at least on some configurations it suffers from a lag after a track starts, which can blow you out of your chair if the new track is a lot louder than the previous one.

Yes, it should definitely still be open. The script works not half as good as replaygain in XMMS. The lag after track start can even blow your speakers in some situations...

The script does not change only the volume in amarok. I had to remove all replaygain tags from my music to be able to play those songs on my ipod. Otherwise ipod didn't played them.
Maybe the script could automatically remove those tags when transfering files to media device?

ReplayGain tags in MP3 are Monkey Audio tags. Some MP3 players have problems with them. Until now I only found mpg123 that cannot decode files with ReplayGain tags.

If ipod doesn't play tagged files it's ipod's fault. Ape tags are a open standard feature which doesn't modify the audio data at all. Complain to Apple or replace the firmware with a better one (http://www.rockbox.org). What is more, you can use the script to add and remove the replaygain tags at your will.
The script isn't involved in file transfers to media devices, so actually it can't do nothing about it.

Josh,

I'm aware of the current situation. What I see here is people arguing for this functionality to be moved into amarok itself. If it is, it should be an option. 

As for "too much" loss in audio quality, "any" is "too much" for some of us.

well, by its very nature, replaygain does nothing to the audio quality.  It 
somply adds a tag which allows a compliant player to adjust the volume so you 
don't have to keep reaching for the volume to adjust it manually when one 
song is louder than another.  Also, by definition it is optional, because if 
you don't want to use it, don't tag your music with replaygain tags and the 
volume will automatically not be adjusted.

Greg,

I have a complete digital path from the hard disk to my stereo's preamp. Anything that adjusts the volume on that *is* screwing with that path and therefor the quality. amarok's built-in volume control can screw with that if I am not careful to always have it at 100%.

As for removing tags, do you have any idea how long that would take for my 150 GB of music?

Eric,

Your music does not have the replaygain tags if you don't add them yourself.

The way I ripped them they are there. I don't want to argue over this with anyone, just state "If this is implemented, it should be optional, not applied if the tags are found"

Of course it should be optional. The question is wether it should be enabled by default.

Sure it should be optional like in other players (XMMS, Winamp, Foobar2000), too.

> I have a complete digital path from the hard disk to my stereo's preamp.
> Anything that adjusts the volume on that *is* screwing with that path and
> therefor the quality. amarok's built-in volume control can screw with that
> if I am not careful to always have it at 100%.
Eric,
I think you are exagerating things quite a bit here. The quality difference caused by a (not extreme) volume adjustment is completely inaudible. Most people even can't hear a difference between lossy vorbis (aotuv-b4.5) 128 kbps and the original.
I suggest you to join the hydrogenaudio.org community and to do some abx tests. You may get quite a surprise :-)
Anyway, I agree about the thing being optional, if it ever gets implemented into amarok itself.

And for those of you who suffer lag with the script, there is a new release (0.9-beta) designed to reduce lag. Give it a try (please read the howto in the release notes)

Eric, if you're concerned about your files being edited (or did I misunderstand you there?) you should be more concerned about bug 99791.

You've misunderstood me.

I collect music from netaudio labels and all of my files have replay-gain tags.

amarok is past version 1.3, still without replay gain (save the py script). 

Greg Meyer, did you every figure out how to set a bounty on this feature? Willing to chip in.

For purposes of background music (like in a cafe) it might be more convenient to have an automatic volume adjustment. In those situations you often want to narrow differences between loud and soft passages anyway. 

Volume adjustment can be done in many different ways: Peak level, RMS level, EarCurve Level, Multiband compression, with/without peak prediction or combinations of those. Would be nice to throw in a hard, predictive, pre-ramping peak-limiter (for clipping) and some dithering (for nice sound) too, though I think this is not necessary for background purposes.

I have some experience in the field (unfortunately with the rather ugly XMMS plugin interface).

This "plugin" MUST be optional: when you listen to an album on your own, you want NOTHING to meddle with your music, when you listen to background music it can be switched on so you don't have to use the volume slider everytime.

Ehm. Maybe that (#39) should be another bug report...

I'm not sure if #39 should go in another bug report, but I completely agree: completely transparent normalization for background music without fiddling with tags is a must for any serious player. If such a request is created please post it here, I will vote.

"You are a voter for the bug, or are watching someone who is."

What other player does this?

In reference to Michel's comments in #39:

In my experience, most audio players that handle replay gain or volume normalization allow you to choose different settings for playing an album vs. shuffling or playing tracks from multiple albums.  For example, the Squeezebox/SlimServer has "smart gain" mode, in which if consecutive tracks are from the same album then use the album gain value, otherwise use the track gain value.  Similarly, Rockbox has the following values for its "Replay Gain Type" setting:

  1 Album Gain
  2 Track Gain
  3 Track Gain if Shuffling

I assume that the 3 is the same as Squeezebox's "smart gain" mode.

I like the "smart gain" mode since I want tracks from different albums to be "normalized", but on the other hand when listening to an album from start to finish I would like the volume differences preserved.

There are several plugins for winamp, and at least one for xmms.

Here's an old comparison of several winamp ones:

http://faq.arstechnica.com/link.php?i=1635

It's important to notice that these things change the song ranges making everything uniform, unlike gain tags, were a song can still have very soft and very loud passages. This makes this kind of normalization very valuable for background work, party, pubs, public, etc. spaces music.

I like the "smart gain" feature, will be in next script release.
About normalization, it could be done somewhat, I guess, though it would be a complex thing. May be sometime in the future...

At #39: I suggestet such a feature some time ago in the forum:
http://amarok.kde.org/forum/index.php/topic,10341.0.html

"Hi
amaroK still has no Replaygain support. But I think at first it would be enough to use a normalizing option like the VDR MP3 plugin:
The plugin scans all files of a playlist in background and stores the loudness information in a file. So all files of the playlist can be played at nearly the same volume. This method works fine with random playlists but is not the right thing to use on whole albums.
So my suggestion is:
1. Use a background scanner for volume scannig.
2. Build in a button to quickly activate/deactivate the normalizing feature. So it is possible to use it only on playlists with random music.
3. Save the information in the database.

PS: This feature is really nice for party playlists."


But now I have replaygained all my files and want perfect replaygain support in Amarok ;)

Does iTunes save normalization data in a track's ID3? Is the format open? If amarok supports any normailzation other than iTunes' format, it is broken. Just like embedded cover support.

To #47,
 I don't know if iTunes supports it or not, I just know that the ReplayGain format is open and there is a proposed standard (Not an IEEE/ISO/RFC standard, but a standard nonetheless @ http://www.replaygain.org/)  So, if iTunes doesn't support it, then that is Apple's problem, not KDE/Amarok's since most of the other popular media players support the tag. (WinAMP/xmms, as stated above for sure, not sure if WMP does or not through Illiminable's DirectShow filter).  My $0.02
  --Brendan

Is there a need for additional comments?  If yes, I vote for Replay Gain too.

I've been using the amarok replaygain script (which is GREAT, thanks to the script writer), however, it would be just so, so great to have the tag info logged in the database so that amarok automatically changed the volume, in other words, before the song started playing.  With the replaygain script there is oftentimes a little lag between the start of the song and the volume change.  (Even with the newest versions of the script, and everything set up right, there are lag issues sometimes with the script, like if I'm working on something else that's using resources)  

I think once you've listened to playlists with replaygain normalization you can't go back to listening with the volume all over the place.  I used to have the remote to my stereo nearby while I was working so that I could stop every five minutes to change the volume.  Now it just goes, it's great.  It could be better if it were in the program instead of in a script.

I wrote a simple script to replaygain tag my collection once I learned I liked it.  If you run this before you go to sleep it will be done when you wake up, with 2.8ghz intel p4 and 80 gigs of music.  I'm not a programmer, there may be an easier way to write this but this gets the job done.

#!/bin/bash
for x in * */* */*/*                                   #down 3 levels
do
   if [ -d "$x" ] && ls "$x" | grep mp3 1>/dev/null    #check dirs for mp3s
   then
     cd "$x"                                           #descend, tag, ascend
     aacgain -a -k *mp3
     cd "$OLDPWD"
   fi
   
   if [ -d "$x" ] && ls "$x" | grep ogg 1>/dev/null    #check dirs for vorbis, descend, tag, ascend
   then 
      cd "$x"
      vorbisgain -a *ogg
      cd "$OLDPWD"
   fi
     
   if [ -d "$x" ] && ls "$x" | grep m4a 1>/dev/null     #check dirs for aac, descend, tag, ascend
   then
       cd "$x"
       aacgain -a -k *m4a
       cd "$OLDPWD"
    fi

done
      
------------------
you just turn that into a txt file and make it executable, (for those that don't know anything about scripts, like me until a few months ago....)

chmod +x WhateverYouNameIt

thanks everybody.

> ------- Additional Comment #3 From Samuel Krempp  2004-09-12 18:18 -------

> TagLib is planning on supporting such tags in the near future

Is TagLib actually still supported? Or how far is the near future still away?

Anything new about this? This lag is certainly anoying.

On my machine

Pentium M 1.7GHz
512MB RAM
Ubuntu Feisty (yes, Gnome user alert)

it varies between 0.5 seconds and 3 seconds (directly after starting Amarok up).

Even Winamp has ReplayGain hardcoded, so why not Amarok?

> Even Winamp has ReplayGain hardcoded, so why not Amarok? 

Neraly every good music player has built in ReplayGain support. Even the Amarok clone Exaile will get it in the next releases.
I hope Amarok 2 will finally have it. The plugin works via DCOP and DCOP is dropped in KDE 4/Amarok 2.

Well, if one of you is going to implement it for Amarok 2.0, hoooray! If not -> it's considered really low priority for us right now. Also taglib still doesn't support those tags, and I doubt we will take care of that on our own (i.e. no implementation without taglib anyway).

For the KDE dropped DCOP thing: it _replaced_ DCOP with DBUS, so updating the script for KDE 4/Amarok 2 is a search&replace action.

I'm not sure if this was already mentioned, but it would especially be nice to have this working for lastfm.

Then you have to go and ask the last.fm guys. There (sadly) is no way for any player software to normalize streamed media, because you'd have to analyse all the data before playback.

since my last comment on this thread i have started using mp3gain on my mp3s. the biggest pain i experience is not scanning my entire library (that can be set to chug along over night), but scanning new files that i get. 

hence my current dream is not a replay-gain enabled player, but a replay or mp3gain enabled player that will also pre-scan any file it's about to play.

on my windows machine i'm using breakaway for "normalized" listening which does destroy dynamics, but sounds quite good! it also works on module files and anything else i play back, not just mp3/ogg/flac :)

To #57
Have you ever updated the replaygain script since your last comment?
Because it does exactly that since 1.0beta1, which it is 1 year old by now. Not to mention that it is not needed to use mp3gain by hand on your files since 0.8 which is reaaaaally old.

Would it make sense to have Amarok provide a sound buffer for any music it is about to play? If at all possible. That way people could create any plug-in they want, simply for a sound buffer. Someone could even add a chipmunk plug-in for all I care.

Would it perhaps be possible to have such plug-ins sitting at the Phonon software stack level? Meaning that ANY software running through any of these plug-ins would benefit from them? No reason why Amarok would be the only sound app. in this whole stack to benefit from this.

On-the-fly/buffered volume normalization would not really solve the problem many commentors and wishers on this bug are hoping to see solved.  Volume normalization that preserves dynamic range must be pre-processed and done relative to other songs/albums, not relative to the few seconds that surrounds a particular moment of music.

There already is a great solution to this problem in the wild called ReplayGain.  Amarok just needs to support it.

On-the-fly/buffered plugins can do some really cool things.  Unfortunately, volume normalization is not one of them.

Guess what, Amarok already supports ReplayGain:

http://www.kde-apps.org/content/show.php?content=26073

You might want to read a few comments above yours. Yes, we know that there's a ReplayGain script, but it doesn't work the way it should be: lag-less. If Amarok took control of this itself, it would eliminate the lag between switching songs and the volume actually adapting. No external script could do that.

The ReplayGain-script is better than nothing, but it has some disadvantages. On the one hand it is not Lag-free (as already mentioned). On the other hand it modifies the volume fader: That sucks. I want to have the volume fader for myself. It should use some additional internal volume control, but not the UI-Fader.

> On the other hand it modifies the volume fader: That sucks. I want to have the volume fader for myself. It should use some additional internal volume control, but not the UI-Fader. 
There is no such additional internal volume control, so no way to do that.

A second internal volume mixer is one thing we could add very easily to Amarok 2, thanks to Phonon.

It's just to multiply the gain (converted from logarithmic to ordinary scale) with the value of the volume fader and use that value where the unaltered value of the volume fader was used before. No need to even care about multiple mixers and phonon.

Guys, as an end user...stop discussing this over and over. Just give us ReplayGain support.

If you have a Windows box go out and install foobar2000 to see how it should be done:
http://foobar2000.org/screenshots/img/rgscan-progress.png.html
http://foobar2000.org/screenshots/img/rgscan-results.png.html

They do it perfectly, functionality, user interface, you name it. Just copy it in terms of UI and concept, since I doubt one can improve on the excellent functionality they already have.

Guys, it's really simple.  Replaygain support will not be implemented until somebody that thinks it's important implements it.  People have been asking for this for four years (including me), but not one developer has taken up the challenge to implement it because so far not one of them has considered it important enough to add.  I'm actually tempted to close this bug as WONTFIX.

foobar2000 does a lot of things very well, but it's a geeks tool and not mainstream.  Even though I'd love the feature, the negatives of foobar far outweigh the fine Replaygain support, so I, like many others use the Replaygain script because something is better than nothing.  If Replaygain was really important, foobar2000 would be a lot more popular.  Because it runs flawlessly under wine, it doesn't lock out alternate platforms, in fact, I use it to scan new tracks to embed the Replaygain values in the tags.

98% of the user base doesn't care about Replaygain, and the replaygain script does an adequate job for a good portion of that remaining 2%, leaving a very small minority who find the current situation unacceptable.  For right now there are three choices besides whining, 1) learn how to program C++ and Qt so you can add support yourself, or 2) Use a different player that supports Replaygain properly, Quod Libet comes to mind, or 3) work on discussing this issue with one of the developers outside of this bug report to try and convince them of the importance of this feature.

Of course, I don't have the programming skills to implement this properly either (Hello World), and it doesn't belong in a bug report, but I find compelled to respond because none of the unpaid, volunteer developers will do anything unless they want to.

I dunno about anyone else, but I use nothing but LAME for mp3 encoding, and it stores a "radio mode" volume tag.  Does Ogg do anything similar?  If the various format guys could get together on the semantics of a volume tag, it could be implemented in taglib and thence in Amarok.

On the other hand, if we had some ham, we could have ham and eggs, if we had some eggs, said Pogo...

Lame radio mode is just another name for Replaygain track mode.

*** Bug 162603 has been marked as a duplicate of this bug. ***

How fare you are with this?
Does Amarok work together with other player developer from other Mediaplayer.

THX 
orleans

> Guess what, Amarok already supports ReplayGain: 
> http://www.kde-apps.org/content/show.php?content=26073


Is there any reason why this no longer shows up inside of the Amarok Get Hot New Stuff dialog?  I used to install it that way, but the other day I could not find it there and had to download it directly from kde-apps.org. Once I did, it seems to work pretty well.

kde-apps has way too many stuff to show all of it. A lot of it is also not high quality enough. So Get Hot New Stuff only offers a subset of those offered on kde-apps. Only the most popular ones? Not sure. Anyway: not much we can do about it.

Why isn't there a proper bug report for ReplayGain instead? Oh well, this serves the same purpose, right?

I agree, Amarok needs native, lag-free ReplayGain support. I've tried various other media players (Audacious, Exaile, Muine, Quod Libet) that have native support, but they just didn't satisfy my other needs, like the ability to properly play through PulseAudio, the ability to randomize a playlist, the "remove played tracks" feature, the functional cover art manager...

This, for me, is Amarok's only flaw. Please add ReplayGain support!

SVN commit 910170 by alexmerry:

Replay Gain support, stage 1: getting the metadata into the database.

BIG FAT WARNING: this will change the database schema, and force a complete rescan of your collection.  You won't lose statistics data, unless this change gets reverted or you try to go back to an older version of Amarok, in which case your database won't work (older versions of Amarok will, in fact, wipe and refuse to recreate the database in this case).

Outline:
* Make amarokcollectionscanner get replay gain data (not for all files yet) from metadata tags
* Add four new entries to Meta::Field, containing the Xesam tags for albumGain, albumPeakGain, trackGain and trackPeakGain
* Add four new columns (albumgain, albumpeakgain, trackgain and trackpeakgain) to the tracks table
* Spruce up the database upgrade path
* Make both ScanManager/ScanResultProcessor and the Xesam importer for sqlcollection get the above data
* Put the new data in the database

Changes from the patch I posted on amarok-devel:
* include peak data, which is needed to prevent clipping (so there are four new fields, not two)
* scan for replay gain tags in ID3v2 metadata of MP3 files (such as created by Foobar2000).
 Other formats will follow.  Only Ogg Vorbis files have been tested.
* Amarok will complain and exit if you try to run it with a newer version of the database
 (ie: version 3 or later, which has not been made yet)

I suggest you back up $KDEHOME/share/apps/amarok before running this version if you care about your collection data.  If you care about your stats and you are running trunk, you should be doing this regularly anyway.

Commit r911684 adds replaygain support for OGG Vorbis and FLAC files:

SVN commit 911684 by alexmerry:

ReplayGain FTW!

Make replay gain support actually do something by
(a) getting the data we stored out of the collection database
(b) using it when the track changes

Also, improve the storage of replay gain tags by storing NULL when they weren't present on the original track metadata.  This allows us to substitute the track gain for the album gain when the latter is requested but doesn't exist.

=============================

This will be in 2.1.

Support for other formats will be added as and when.  Note that if you run mp4gain or aacgain over your MP3/MP4s, the tracks will sound at the right volume on ANY mp3 player.

Also, it's track mode only.  Adding album mode is just a case of figuring out when to enable it.

Also, it won't automatically scan your music for you and add the tags, since that functionality really belongs in a script.  Open a separate feature request for that if you want it.

"Note that if you run mp4gain or aacgain over your MP3/MP4s, the tracks will sound at the right volume on ANY mp3 player."

This is only true if you use the "-a" option in aacgain/mp3gain. Otherwise it will only apply tags (AFAIR Ape-Tags) to the mp3 files.

Sorry, you are correct (well, almost: -a applies album gain, -r applies track gain).

I hope to have MP3 and MP4 tag support at least before 2.1 is released.

> Also, it's track mode only. Adding album mode is just a 
> case of figuring out when to enable it.

Hmm, it’s really not as trivial as one would assume. I guess one solution would be that iff the current track is on the same album as the previously played track (i.e., the two tracks have the same album name *and* the same album replaygain values), don’t change the volume.

A more natural solution would be to use the album replaygain value (instead of the track replaygain value) for a track if the *next* track was on the same value, but as Amarok supports playing a playlist in random order, this won’t work (or are the order determined ahead of time? – it certainly needs to be recalculated if you add a track to the playlist).

"A more natural solution would be to use the album replaygain value"

It is safe to always use album gain (and track gain as fallback, if album gain is not present), because if a track has a lower volume on an album it should certainly be played at lower volume than others.

Furthermore replaygain still has a volume error between some files. This error can be bigger than the difference between album and track gain. On the other hand it is possible to hear volume changes in an album, if you use track gain only.

"Sorry, you are correct (well, almost: -a applies album gain, -r applies track gain)."

Yes. And the normal solution would be to just use the tags instead of mp3 loudness change, because on players without replaygain support you'll get the same volume, but the volume is to low. Especially on mobile players.

The only clean solution is to use tags and a players, that support these tags.

(In reply to comment #82)
> Yes. And the normal solution would be to just use the tags instead of mp3
> loudness change, because on players without replaygain support you'll get the
> same volume, but the volume is to low. Especially on mobile players.
> 
> The only clean solution is to use tags and a players, that support these tags.
> 

There's also a problem, if you mix mp3 and Vorbis files on a portable device that doesn't support replaygain tags. Loudness change of Vorbis files is not possible as far as I can remember, here the only possible solution is using tags. On a device that can't read these tags, all vorbis files have a much higher volume compared to mp3 files.
So the default behaviour schould be using tags only, in my opinion.

There's really no need for all this quibbling :-)

Reading tags for MP3s and MP4s should be implemented before 2.1 comes out.  So everyone can then be happy (unless you're listening to WMA files, or whatever).  In the meantime, there IS the option of using replaygain with -r or -a.

My aim is to have Amarok support all the tags that the 1.4 script did (as far as taglib will allow this).  How much of this happens before 2.1 depends on how much time I have, how soon 2.1 is released and how much help I get testing files.

If you're willing to help, email me or ping me on irc (randomguy3 on #amarok).  Otherwise, be patient.

The only drawback of the 1.4 script is the lag at the beginning of the songs. Everything else is the best replaygain implementation I know:
- it supports all relevant file formats (ogg, mp3, aac, flac, mpc)
- it shows an error at files without RG
- it can apply RG
- I even like the adjusting by volume control because I can see what was adjusted

BTW: I'm back at 1.4 at the moment because after trying 2.0 pre releases and Exaile for a while, I just want to have a functional program at the moment :-) So I cannot help in testing your new code :-/

Wow, 5 years to be fixed.
> Also, it's track mode only.  Adding album mode is just a case of figuring out
> when to enable it.

Easy, do the same as the script, let the user choose, it is the safest.

(In reply to comment #85)
> - I even like the adjusting by volume control because I can see what was
> adjusted

This was one thing of the 1.4 script that peeved me (besides lagging):
1st often it disturbs the OSD, causing the OSD (showing the title of currently playing track) to disappear because of the volume slider getting changed.

2nd sometimes you want to change the "global Amarok" volume, meaning the overall volume the music is gonna play from Amarok. E.g. say your friends in your livingroom getting louder and louder with chattering. So you adjust the volume *within* Amarok. With next track change *woohm* your adjustment gets wiped out by replaygain ;)
(I know - you can change the master volume of your soundcard, but then the volume slider in Amarok gets absolutely useless.)


Thanks for your great work! I looove to see replaygain finally getting integrated *into* Amarok instead of a lagging "workaround" script :)

@ Lars: You are right. There are drawbacks with the "change volume by slider" solution.
It would be easy to add a "ReplayGain = xx dB" field in an info area. So it would be possible to see the dB change, too ;-)

Hi! I'm using yesterday's svn build of Amarok but the volume normalization does not work. Of course all files are tagged and after starting Amarok 2 it has scanned the complete collection.
So my question is: How is the volume change realized? What multimedia backend is used in Amarok 2?

I've tried both: album and track mode.

This is the biggest issue with Amarok 2, because a working ReplayGain is mandatory for me :-/

It seems there's a bug in the Xine backend.  The GStreamer one works fine (well, in this case - more generally, the GStreamer backend has several issues).

Please file a separate bug for this, though.

How di i switch to the gstreamer backend?

OK, could switch in the settings dialog. It works with the gstreamer engine.

BTW: What's the console command to start kde system settings?

@thenktor: On my Kubuntu machine, it's simply "systemsettings".