Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "normalize" program vs ReplayGain (Read 3920 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"normalize" program vs ReplayGain

Audio is speech. The source wave file before encoding is already normalized by SoX

Code: [Select]
sox --norm ${inputWav} -b 16 -c 2 ${outputSox} rate -v 48000 dither -s


When archived with flac (Linux - flac 1.3.0)

Code: [Select]
REPLAYGAIN_TRACK_GAIN=+2.85 dB
REPLAYGAIN_TRACK_PEAK=0.99914551


When compressed with oggenc (vorbis-tools 1.4.0) and I use vorbisgain (VorbisGain v0.36 (libvorbis 1.0)) I get

Code: [Select]
REPLAYGAIN_TRACK_GAIN=+2.91 dB
REPLAYGAIN_TRACK_PEAK=1.01474988


When compressed with lame (LAME 64bits version 3.99.5) and the --replaygain-accurate switch, in the lame header I get

Code: [Select]
REPLAYGAIN_TRACK_GAIN=+3.3 dB
REPLAYGAIN_TRACK_PEAK=0.95100796


Those are all very similar,
But using normalize 0.7.7

Code: [Select]
Computing levels...
  level        peak         gain
-10.8049dBFS -0.4359dBFS  -1.1951dB  audio.mp3


It wants to reduce the gain.

-=-

I'm assuming this likely means that normalize isn't using the ReplayGain algorithm but is doing something different, but is it normal for it to want to take the volume in the opposite direction of ReplayGain ??

normalize was run on the mp3

"normalize" program vs ReplayGain

Reply #1 –
That command in sox is probably just doing peak normalization and it is readily accepted that lossy encoding can produce large peaks relative to the source file.

With respect to this topic at a very minimum, your use of the --replaygain-accurate switch accomplishes nothing.  It merely runs a test decode in order create metadata that is compatible with barely anything.

"normalize" program vs ReplayGain

Reply #2 –
Quote from: greynol on
That command in sox is probably just doing peak normalization and it is readily accepted that lossy encoding can produce large peaks relative to the source file.

With respect to this topic at a very minimum, your use of the --replaygain-accurate switch accomplishes nothing.  It merely runs a test decode in order create metadata that is compatible with barely anything.


Well I take that metadata from the lame header to create the TXXX frames that is readable by more players.

I just am wondering if it is normal for the lame metadata to suggest a 3dB increase while the normalize scan of same file wants to suggest a decrease, or if that indicates something screwy with either lame or normalize.

"normalize" program vs ReplayGain

Reply #3 –
As I said, this is perfectly normal.

I wrote a script that transferred RG metadata once. Because Lame only computes track gain it was worthless to me. I don't think it uses the R128 algorithm, if that matters, though vorbisgain probably doesn't either.

"normalize" program vs ReplayGain

Reply #4 –
Looking back over your post, I didn't know anything about the normalize program so I did a little research.

Apparently it merely normalizes to an RMS level.  This is an extremely primitive algorithm which will only be compatible with loudness-based normalization over just a select group of audio recordings, and perhaps only after the level is calibrated.  That it diverges for speech is hardly surprising. I'd avoid that program if I were you.

I apologize for not noticing this earlier.

"normalize" program vs ReplayGain

Reply #5 –
Thank you!