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: MP3 normalization when encoding (Read 13434 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 normalization when encoding

How to normalize mp3s to have all peaks be at 0 dB maximum and prevent clipping. I've tried Replay Gain, but don't really like it as it lowers volume of files often by more than 8 dB. unnecessarily quiet. I also know mp3s can store peaks above 0 dB but many decoders don't know this and just clip. I can see why this problem would be negligible/unaudible with properly mastered material, but I have several lossless albums that are already quite clipped and distorted to the max by horrible mastering and I don't want to make this problem worse. Please don't just tell me to use lossless compression, I want lossy and I'm aware of the fact that pictures don't make sounds, but I don't want to make an already existing problem worse.

I've tried to normalize to -0.5 dB in LameXP, but my files still often peak over 3 dB above full scale? What am I doing wrong?

MP3 normalization when encoding

Reply #1 –
If the files are already clipped then the peaks contain high frequencies that are either filtered out or not encoded. When the decoder reconstructs these peaks they can go quite a bit above full scale due to the missing information that would have defined flat tops.

Your best bet is to use a program that analyzes what the file will decode to, and reduce the gain accordingly.

MP3 normalization when encoding

Reply #2 –
Thanks, but is there such a program other than ReplayGain, which reduces the volume way lower than is needed?

MP3 normalization when encoding

Reply #3 –
Mp3gain if you want to alter the volume of the data without having to reencode.  The GUI can tell you exactly how much you can adjust the level and keep it from clipping, IIRC.

PS: RG is just a scanning algorithm and tag specification. It is not a program.  There is no reason why the volume must be lower than what is necessary to prevent clipping with RG since peak values are included in the metadata.  Foobar2000 has a preamp function and a max no clip option, for example.

PPS: Whether clipping is made audibly worse because of lossy compression is determined through a double-blind test on a case-by-case basis. IOW, you won't know if it's actually worse unless you listen...objectively.  This is not to say that taking precautions is a bad idea.

MP3 normalization when encoding

Reply #4 –
Quote
I've tried to normalize to -0.5 dB in LameXP, but my files still often peak over 3 dB above full scale? What am I doing wrong?
I assume LameXP is normalizing before MP3 encoding.  The lossy encoding process makes some peaks higher and some peaks lower, and it's probably hard to predict.

You can try normalizing the encoded MP3 with mp3DdirectCut.  Note that you can only make lossless changes to an MP3 in 1.5dB increments so your wont generally be exactly 0dB.

MP3 normalization when encoding

Reply #5 –
@Neuron: You should take a moment to think about your listening interests. Let me explain what I mean:

You are asking for a way to reduce the volume, because you are aware of what digital clipping is, and you know that some or your files contain it.
I guess you have heard about the loudness war as well, (as it is a topic that appears here in Hydrogenaudio from time to time), and so you might know that clipping is a consequence of loudness war, and that reducing the volume is a wise decision in general.

So with this information, what are the ways of reducing the volume and preventing clipping?

The first obvious one is the one you mentioned, which is normalizing below full scale (i.e. 0dBFS). As you found out, this solution is not really good to remove completely the clipping scenario (especially if applied before lossy encoding), and does not alleviate the loudness war effect.

The second one is to use algorithms that take into account the loudness of the file, which include Replaygain, EBU R128, or Itunes SoundCheck. The primary intention of these algorithms is to leverage the loudness (not the peak amplitude) of files, so that the listening experience is similar.
Since this is achieved generally by lowering the volume, it avoids the problem of clipping, and in the case of full replaygain implementations, there is the possibility to avoid in all cases the clipping effect by use of the "... and prevent clipping" playback option.


So you know that you will have to reduce the volume, and the question is how much.
EBU R128 targets -23 LUFS.
Replaygain targets approximately -18 LUFS  (89 dBL)
Itunes Soundcheck targets approximately -16.5 LUFS

You said that in your files, replaygain lowered the volume by 8dBL. That's the usual value nowadays, and definitely not of the worst  (-10 and -11 have been reported here).  The obvious problem is that if you only apply this to some files, then there's a big difference in volume respect to other files, so here, two more subjects enter into play.

First and most obvious, which player or players do you use to play the files?  Replaygain is quite prominent, but it is not present in the main players (I guess Winamp is no longer a main player).  Soundcheck is Apple's only, and not all iDevices support it. EBU by itself is just a standard, and right now, I've only seen implementations of it over the replaygain tags specification.
Finally, mp3gain (aacgain) can be applied directly to files, so players don't require knowledge of the tags to play at the changed volume. But it can only modify mp3 and mp4 (aac) files.

Why does this matter? for two reasons: First, if your player/players support one of them or not. And second, because for replaygain, players can implement an alternate target level. (foobar2000, dbpoweramp and Winamp offer this).

Second subject: Do your playback devices offer enough volume to compensate for the lower target of these standards? This is specially important for smartphones or other portable players, and more so if the EU(ropean) norm of limiting the output is applied.



With all this information, we can start to make some decisions:

* If you can use replaygain, your player supports alternate target level, and you have enough room for volume boosting, a solution can be: Use replaygain, change the target level of non-replaygained files to -7 or -8 and replaygained to 0.  If you want a bit more volume because most of your files are reduced by 6 or more dBs, you might consider to set non-replaygained to -4, and replaygained to +3, and prevent clipping activated. (This is what I do).
* If you can use soundcheck, start applying it to all your files and accept the target volume (at least it has the highest of the target volumes).
* If you cannot use any of those, but you have mostly mp3 and mp4 files, get mp3gain (or aacgain), and choose a target loudness level appropiate for your volume needs. For example, usig 92dBL instead of 89dBL might be a good compromise between no clipping and a volume not too low.
(Note: foobar2000 is able to apply replaygain to mp3 files in the same way that mp3gain does. It has an advanced option to change the target level. I can explain this some more if it is the chosen option)

MP3 normalization when encoding

Reply #6 –
Mp3gain has a max no clip gain option, but it's hidden by default. Google it or see the help file. Can't calculate it before encoding as encoding changes the sample values.

Clipping due to encoding is rarely if ever audible.

Cheers,
David.

MP3 normalization when encoding

Reply #7 –
On Linux with caudec, you can peak normalize the lossless source after decoding and before encoding. You can also add an additional gain value to apply after normalization. In your case, applying a negative gain of 4dB would very likely compensate for the worst lossy peaks above 1FS:

Code: [Select]
$ caudec -c mp3 -G albumpeak -G -4 *.flac

MP3 normalization when encoding

Reply #8 –
Thanks for all the tips guys, there's a thing I want to ask through.

Quote from: greynol on
There is no reason why the volume must be lower than what is necessary to prevent clipping with RG since peak values are included in the metadata.  Foobar2000 has a preamp function and a max no clip option, for example.


How do you set up Foobar2000 when encoding mp3s using the "max no clip" option?

MP3 normalization when encoding

Reply #10 –
replaygain is not related to the encoding process, it just applies at the decoding stage.

The options for replaygain in foobar2000 are in File->Preferences->Playback. (Prevent clipping is in the processing droplist)

MP3 normalization when encoding

Reply #11 –
Quote from: greynol on
Since you cannot know the peak levels in the lossy-encoded files ahead of time, that isn't possible.


But if you "repair" the affected files with mp3gain set to maximum no clip gain, the file is as it should be right?

Did I correctly understand that the peaks above 0 dB in an mp3 file, unlike with 16-bit wav, are actually "still there", it is just that some decoders will convert the output to 16-bit and clip them? So does mp3gain set these peaks back as they should be, or it just lowers the volume and the peaks are irretrievably clipped? I am talking about mp3 clipping, of course I know that the clipping in the source cannot be fixed.

If my assumption is correct, is it safe to just encode files as they are, then lowering the gain with mp3gain? Or does it actually clip and I'm safer using --scale in the LAME commandline?

MP3 normalization when encoding

Reply #12 –
You are correct.  MP3 format does not clip on encoding. Only the decoder, when converting to integer format (required for the soundcard to play it back) would truncate those values above full scale.

So, if the player reduces the volume (as it is done with replaygain, or mp3gain, or any volume control that acts over the floating point data, not the integer data), then, the clipping due to mp3 encoding will not exist.


Said that, using --scale ( or the upcoming --gain option ) with LAME is useful in some cases, where it can bring the bitrate required down. (Of course, with the premise that the volume won't be boosted later).

MP3 normalization when encoding

Reply #13 –
Quote from: Neuron on
But if you "repair" the affected files with mp3gain set to maximum no clip gain, the file is as it should be right?

Clipping occurs during decoding to fixed-point (not just 16-bit).

Quote
So does mp3gain set these peaks back as they should be, or it just lowers the volume and the peaks are irretrievably clipped?
Set peaks back as they should be? No, mp3gain doesn't do anything special with peaks, it just adjusts the level as instructed and everything is shifted. If the peaks are now below full-scale then there will be no clipping when decoded to fixed-point.

Quote
If my assumption is correct, is it safe to just encode files as they are, then lowering the gain with mp3gain?

Yes.

All this out of the way, wouldn't you rather have all your albums play at equal loudness, rather than use the program to "fix" something that probably isn't broken?  A better way to do it is to find the level that normalizes the loudness of everything and also satisfies your paranoia, if you feel so inclined.

MP3 normalization when encoding

Reply #14 –
Quote from: greynol on
All this out of the way, wouldn't you rather have all your albums play at equal loudness, rather than use the program to "fix" something that probably isn't broken?  A better way to do it is to find the level that normalizes the loudness of everything and also satisfies your paranoia, if you feel so inclined.


Well, most of my albums are already at the same volume level thanks to "modern" mastering so...

A bit off topic, it is really bad to see so many good electronic and metal albums brickwalled to shit. These 2 genres need some dynamic compression, but a dynamic range of 3 dB is just sad. Many people think Death Magnetic was especially bad, when now Adele's Skyfall has a DR2 and that is a pop song with an orchestral sound! I really like dubstep for example, and that genre doesn't need much dynamics, but it needs some, a DR of 3 or 4 is not acceptable for anything. Depeche Mode's Playing the Angel is synthpop, yet the first time I played it I thought that it is either damaged somehow or there's something wrong with my speakers.

MP3 normalization when encoding

Reply #15 –
Quote from: Neuron on
Well, most of my albums are already at the same volume level thanks to "modern" mastering

Within a few dB, for the most part, sure.

Quote from: Neuron on
These 2 genres need some dynamic compression

A lot of music can benefit from at least some DRC, especially if your listening environment isn't well isolated.  Stylistically, indeed, some genres might sound strange without it.

Quote from: Neuron on
dynamic range of 3 dB is just sad.

Not sure how you come up with the 3 dB figure. Is it peak to RMS ratio?  Is it the DR value?  Is that the same thing?  I can't say I'm a fan of the DR thing since large DR values aren't proof that something is audibly dynamic.  Besides, people spend too much time fixating on numbers.

MP3 normalization when encoding

Reply #16 –
DR value. And while numbers are not always indicative, in this case they made me understand why do some of my favourite CDs sound so crap in terms of sound quality. No wonder Playing the Angel sounded weird and rough, many songs in that album have a DR of 2!

MP3 normalization when encoding

Reply #17 –
I'm new here as writer (it is my first post but years of silent reading) so hello to community and special thanks to LAME developers!

===

Quote from: Neuron on
How to normalize mp3s to have all peaks be at 0 dB maximum and prevent clipping.


Hello, Neuron!

Firstly I highly recommend you to read famous ff123's article named "Added Clipping" (I know of this article many years ago from some thread /actually multiple threads/ on this forum).

Several years ago I also stand before "abovequoted" problem and had solved it by following simple (for me) way.

1. Source WAVs are analysed to find peak value. There are plenty of programs, I am using (for years) free tool Normalize from Chris Vaill.

Command line is (no normalizing here /"discard" tool name/, just examining of files):
Code: [Select]
c:\somepath\normalize.exe -n --peak --fractions --no-progress *.wav >> peak.txt

Peak values (ranged 0..1) are in 2nd column, select maximum from them (maybe sort in capable texteditor).

2. Calculate needed value for --scale: scale=0.968/peak (0.968 is empiric value for lame 3.99.5 -V 0 encode).

It is "draft" value (because we cannot say before encoding what exact "value" will be added if any) but for hi-quality (-V 0) it is good enough, not exactly at 0 dB (at 32767 in 16-bit output), but good. (The more scalevalue the more "draftness" in it, so for values like 2 /very rare but can be — for years I have encountered less than 10 wav album-sources with needed initial scalevalue greater than 2/ or so I make it slightly less.)

3. Encode:
Code: [Select]
c:\somepath\lame.exe -V 0 --scale %scalevalue% --noreplaygain file.wav file.mp3

(I use --noreplaygain because not all of my players support this tag, so I slightly speed-up encode process.)

4. Check for actual peak.
Code: [Select]
c:\somepath\mp3gain.exe /x /s s /o *.mp3

If maximum peak is 30000..32500 then it's ok for me.
If maximum peak is less than 30000 (rarely because of calculation in (2)) then I may (or may not) recalculate scalevalue: go to (2).
If maximum peak is more than 32500 (possibly but not frequent) then I definitely must (and will) recalculate scalevalue: go to (2). Yes I can use exact 32767 here but better I give some "slack space" for peaks.

Actually mostly all work is done through CMD file (cannot be widely used because of several specific things so I will not post it here in entirety).

I prefer to not adjust to exactly 0dB (32767 for 16-bit audio) because as I noted above: better I give some "slack space" for peaks (and for mp3 decoders).

It is possibly to fully automatize abovementioned procedures (and scale adjusting loop) but for me is enough to manually calculate scalevalues.

And yes, this procedure is performed for all album-files together, no track-normalizing (peak-adjusting) here.

P.S. Clarification of math in "4 go to 2" path.

1. Say we got WAVs peak maximum value of 0.987654.

2. scale=0.968/0.987654=0.980.

3. Encode...

4. Actual peak maximum value is 34000 — too big, definitely is clipping, go to (2).

2.a) Note 0.968*32768=31719.

2.b) Proportion: 0.980/34000 = newscale/31719 >> newscale = 0.980*(31719/34000) = 0.914

2.c) New scale = 0.914.

Go to (3).

<<< OR >>>

4. Actual peak maximum value is 20000 — too low, definitely worth to "up", go to (2).

2.a) Note 0.968*32768=31719.

2.b) Proportion: 0.980/20000 = newscale/31719 >> newscale = 0.980*(31719/20000) = 1.554

2.c) New scale = 1.554.

Go to (3).