I want this also. I installed Juk in a bar this week and normalizing volumes is one of the top priorities. So please add.

BTW this can proberly also be a Arts issue.

Yes, I'd like to see this too, but I think Scott or someone else who can code well should implement plugin support for JuK.. It'd be nice to users who doesn't want to have all those "useless" features and if something is missing you could do it yourself. My 10 votes for this anyway :)

Sorry guys, but you shouldn't be confirming wishlist items for stuff that you don't work on.

If you're thinking of adding normalizing support you should look at ReplayGain. It just requires an "analyse" phase, and then the small produced data can be saved in ID3V2 tags or such.

The (seriously outdated) site is at http://www.replaygain.org/ and has the full "proposed standard" there.

I think it's worth a look, since it's already done and is already used in some software, including commercial apps, some Winamp plugins, and open-source software as well, XMMS for instance (in its vorbis plugin).

I did a little research today and found out that the Lame and FLAC encoders support Replay Gain while encoding. It would be a good idea to see where and how they store the data. Maybe the code can even be reused (I'm not sure about the legal aspects though, Lame is LGPL and FLAC is BSD).

As FLAC uses Vorbis tags, it should store the data in the same fashion as a Vorbis tool, but I'd check the XMMS vorbis plugin anyway.

This really seems to be the closest thing to a standard in normalizing audio...

The following ReplayGain metadata is stored for FLAC and Ogg Vorbis audio formats (from the vorbisgain man page):

              REPLAYGAIN_TRACK_GAIN=-7.03 dB
              REPLAYGAIN_TRACK_PEAK=1.21822226
              REPLAYGAIN_ALBUM_GAIN=-6.37 dB
              REPLAYGAIN_ALBUM_PEAK=1.21822226

I verified that the same metadata ids are used in the Flac format.

Lame uses the MP3 info tag to store Replay Gain info, as described here:

  http://gabriel.mp3-tech.org/mp3infotag.html#replaygain

The author of the vorbisgain tool (previously called replaygain) implemented the ReplayGain support for the XMMS Vorbis plugin; he describes the required algorithm in his initial announcement. Both the XMMS plugin and vorbisgain code are licensed under the LGPL, but the description allows for a clean-room implementation if one so desires:

  http://www.xiph.org/archives/vorbis-dev/200201/0150.html

I am pretty sure Juk should support ReplayGain directly (by adjusting the volume based on the ReplayGain values) and not the decoders (the aRts media format plugins). As ReplayGain commonly is something that is:

  a) switched on/off explicitly

  b) commonly implemented in the player code, not the decoding code

  c) offers a explicit choice between album gain and track gain

this probably belongs in Juk.

At this moment, there is no ReplayGain support in any of the aRts supported formats that also include gain information in the file format.

Here is an overview of current ReplayGain support in the aRts plugins, and available ReplayGain implementations:

 - Ogg support:

     http://lxr.kde.org/source/kdemultimedia/mpeglib/lib/decoder/vorbisPlugin.cpp

   This is licensed under the GPL so it could reuse the XMMS implementation;
   implentation is at:

     http://cvs.xmms.org/index.cgi/xmms/Input/vorbis/vorbis.c?rev=HEAD

 - MP3 support:

     http://lxr.kde.org/source//kdemultimedia/mpeglib/lib/decoder/splayPlugin.cpp

   Licensed under the GPL. The MAD project does have ReplayGain support in
   their madplay package, and this is also under the GPL. It is the player
   that decodes the RealPlay information and adjusts the mp3 decoder/audio 
   output accordingly. Mostly in player.c (in madplay), downloadable from:

     ftp://ftp.mars.org/pub/mpeg/

 - FLAC support:

   Done via xine, so flac decoding is done at:

    http://cvs.xmms.org/index.cgi/xmms/Input/vorbis/vorbis.c?rev=HEAD

   Licensed under the GPL. So is he flac project, which includes a XMMS plugin 
   that supports ReplayGain:

    http://cvs.xmms.org/index.cgi/xmms/Input/vorbis/vorbis.c?rev=HEAD
   
   and a encoder/decoder/player tool that also supports ReplayGain:

    http://cvs.sourceforge.net/viewcvs.py/flac/flac/src/flac/decode.c?rev=HEAD

   Both cases its again the player code that adjusts the gain based on
   preferences and file info.

Oh, and Flac is (now?) licensed under the GPL.

There's also the standard normalize libs you can find at http://www.cs.columbia.edu/~cvaill/normalize  This is a fairly standard linux package (most distros include it) and it shouldn't be too hard to be able to pipe through it.  (Or something...I haven't looked at it, so I don't know exactly what it does...I just know that K3B uses this package.)

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

Using 'normalize' is a bad Idea, since it needs 2 passes.

ReplayGain is the only thing, we should use. There's ReplayGain-Support in almost every relevant Audio-Format nowadays. So we need some kind of libreplaygain, which could be fed with the volumelevel and/or gainlevel. Basically, you take the pcm-samples, convert them to float32 (if not already done so), and apply the wanted level.

The player interface could have a small icon which tells you, if the current song has replay-infos or not, so you can fix it. Perhaps the player could offer a function to run 'mp3gain', 'vorbisgain', 'metaflac --add-replay-gain', etc. on selected files.

This is an off the cuff didn't read everything reply.

I don't know if juk can run with esd or not - I don't use it - 

There is however a program called AudioCompress that normalizes esd quite well, and it will normalize for *all sounds* not just what's playing in juk.

This is how I start it.

~/.kde/Autostart/start_esd
---------------------------
#!/bin/sh
nohup esd&>/dev/null&
sleep 1
nohup AudioCompress -g 255 -e localhost&>/dev/null&

Just adding my vote. It would be good it juk could store the volume levels it calculates as part of the playlist db. That way, each file would not need to be parsed beofre playing each time.