Normalize track volume

I think Replay Gain can be more useful when comparing two different tracks than using it as you suggested.

As an example, imagine one records with the same volume (e.g. energy) two audio tracks, say audio1 and audio2.
audio1 is a signal at 500Hz and audio2 is at 1kHz. Human ears will perceive audio1 louder than audio2 (perceived loudness can reach 10dB).
To rectify this, in Replay Gain algorithm signals are filtered through a "equal loudness" filter. As a second step, the track is divided in 50ms chunks and energy mean is calculated and such values are sorted in ascending order."The value which most accurately matches human perception of perceived loudness is around 95%, so this value is used by Replay Level".

This means that if gain is set accordingly to replay gain tag and just below clipping, one can have clippings since the loudest value is not the replay gain suggested one.

On the other hand, if these values are used to compare two tracks and pregain of one track is auto-adjusted to reach the same "perceived loudness" of the other (and both are "far away" from clipping), one can switch from one track to the other and the audience will not perceive any volume difference.

My suggestion is hence the following:
If both tracks have ReplayGain tags set and if button on Channel X is pushed, pregain of track on Channel X is set accordingly to pregain value of the other track and the two ReplayGain tags.

I did something similar in a mapping for Hercules DJ Control Mp3 ( http://www.mixxx.org/forums/viewtopic.php?f=7&t=1648 ) but not (obviously) using ReplayGain algorithm or tags.

I agree with Vittorio in this case. Adjusting the songs so the peaks are similar is not how ears perceive loudness. See here for more info: http://replaygain.hydrogenaudio.org/calculating_rg.html

I'm opposed to implementing ReplayGain analysis within Mixxx itself, as I think this is outside the scope of Mixxx. The ReplayGain should be measured and applied when the file is encoded in whatever format it is in. The standard FLAC encoder does this, for example.

I'm assigning this to myself since in my TagLib branch I will implement loading ReplayGain values from all the metadata formats (APE, ID3v2, Xiph, MP4) and then apply the replay-gain at track load time if it is present.

We're talking about two different things here (and perhaps should split this into two separate bugs.)

The first (and easiest) thing I'd like to see is maximizing the dynamic range of the deck. This is simply done by auto-adjusting the Gain knob so that the loudest transient in the track is immediately below clipping.

The second is auto-adjusting for perceived loudness. This should be done with the deck's volume slider, NOT the gain control.

(And I agree that calculating ReplayGain is outside the scope of Mixxx. I was just unaware that it deals with perceived loudness, in which case it should be applied to the volume slider, not the gain control.)

I might also add here that defaulting the deck volume sliders to around 80% might be a wise idea so there's somewhere to go if one loads a quieter track.

Hi all,

I'm a happy user of a Hercules DJ Control Steel.

If you move sliders and knob in mixxx, it won't move on the console, and my console and mixxx will be desynchronized on each track !

I see 2 options :
- normalize audio transparently
- create a new application that normalize all audio files of a directory for example ?

Regards

Stéphane

Hi there,
in the spirit of learning some c++ (it is just a week), I have implemented an analyser which calls a widely used replaygain algorithm (see e.g. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/vorbisgain/natty/annotate/head:/gain_analysis.c ). For now, the result is just printed on screen.
As a top, the process takes about 4/5 seconds for an 8 minute track on an AMD phenom II and an optimized build. Everything seems to work pretty well even if trying to downsample affects a lot precision against a little speed up. If it is interesting for you, I can post it. Even if my 3 days work is just a couple of minutes for you.

About volume/pregain thing: It is just my personal opinion, but I'd prefer to use sliders for doing other tricks. If only pregain is affected, I could locally move volume sliders according to my taste and I could align "perceived loudness" by simply align volume sliders. If I change the position of volume sliders according to replaygain and I move sliders, I have to remember the exact position of both to realign loudness. Am I wrong? My perception can be altered by the fact that the Hercules console I use, has volume sliders but not pregain controls...

For taglib thing, I did some search in the last days and I think one of the best examples of using taglib to read stored replaygain tags is from amarok: http://gitorious.org/amarok/amarok/blobs/master/shared/MetaReplayGain.cpp
Note the comments at lines 251 and 278. That is why I thought it could be an idea to implement replaygain as an analyser: just to fit the holes that taglib is not able to fill. I am willing to spend some other weeks in trying to learn and then trying to implement the MetaReplayGain.cpp ideas in mixxx taglib branch just to learn something new.

At last, in my personal ideal world the implementation would be the following: If Replay Gain has been calculated/read, pass the ReplayGain value (plus an initial "boost" of +9/+12dB) as a UI/MIDI control and let people choose how to use it.

At last, I'd like to point out the origin of all the evil: http://it.wikipedia.org/wiki/Loudness_war
Thanks for reading,
Vittorio

I forgot to add the following:

* Actual Replay Gain algorithm is based on equal loudness contours as carried out by Robinson and Dadson. As far as I know, this last had been corrected by ISO 226:2003. Expect it to be not so precise when on low frequencies (actually the differences can be of 10/12 dB)

* For non-italian speakers, the root of all the evil is here: http://en.wikipedia.org/wiki/Loudness_war ;)

Stéphane: I'm planning on implementing "soft-takeover" in the controller engine to prevent exactly that problem (sudden jumps in levels.) See bug #555547.

Vittorio is already very close to finishing this in lp:~l0rdt/mixxx/features_replaygain

It just works now. It is not yet configurable but it is able to calculate/read replaygain tags and transparently applies such values to pregain.

Is it being applied via an EngineObject or is it being added to the pregain
CO?

Phillip: It works exactly as "file_bpm". Take a look at src/player.cpp, lines 56 and 168 . To see how it is applied, have a look at src/engine/enginepregain.cpp . Thanks in advance for any comments/suggestions.

Finished! :)

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5529