The process of normalization often confuses newcomers to digital audio production. The word itself, “normalize,” has various meanings, and this certainly contributes to the confusion. However, beginners and experts alike are also tripped up by the myths and misinformation that abound on the topic.
This post addresses the 10 most common myths, and the truth behind each, below.
Peak Normalization
First, some background: While “normalize” can mean several things the myths below primarily involve peak normalization.
Peak normalization is an automated process that changes the level of each sample in a digital audio signal by the same amount, such that the loudest sample reaches a specified level. Traditionally, the process is used to ensure that the signal peaks at 0dBfs, the loudest level allowed in a digital system.
Normalizing is indistinguishable from moving a volume knob or fader. The entire signal changes by the same fixed amount, up or down, as required. But the process is automated: The digital audio system scans the entire signal to find the loudest peak, then adjusts each sample accordingly.
Some of the myths below reflect nothing more than a misunderstanding of this process. As usual with common misconceptions, though, some of the myths also stem from a more fundamental misunderstanding – in this case, about sound, mixing, and digital audio.
Myths and misinformation
Myth #1: Normalizing makes each track the same volume
Normalizing a set of tracks to a common level ensures only that the loudest peak in each track is the same. However, our perception of loudness depends on many factors, including sound intensity, duration, and frequency. While the peak signal level is important, it has no consistent relationship to the overall loudness of a track – think of the cannon blasts in the 1812 Overture.
Myth #2: Normalizing makes a track as loud as it can be
This is not necessarily true. Peak Normalization will push the peaks in a track up. Our perception of loudness is largely unrelated to the peaks in a track, and much more dependent on the average level throughout the track. So, we naturally perceive a track with a higher average level, with less high peaks as "louder" than a track with a lower average level and higher peaks.
Myth #3: Normalizing makes mixing easier
I suspect this myth stems from a desire to remove some mystery from the mixing process. Especially for beginners, the challenge of learning to mix can seem insurmountable, and the promise of a “trick” to simplify the process is compelling.
In this case, unfortunately, there are no short cuts. A track’s level pre-fader has no bearing on how that track will sit in a mix.
Simply put, there is no “correct” track volume – let alone a correct track peak level.
Myth #4: Normalizing increases (or decreases) the dynamic range
A normalized track can sound as though it has more punch. However, this is an illusion dependent on our tendency to mistake “louder” for “better.”
By definition, the dynamic range of a recording is the difference between the loudest and softest parts. Peak normalization affects these equally, and as such leaves the difference between them unchanged. You can affect a recording’s dynamics with fader moves & volume automation, or with processors like compressors and limiters. But a simple volume change that moves everything up or down in level by the same amount doesn’t alter the dynamic range.
Myth #5: Normalized tracks “use all the bits”
With the relationship between bit depth and dynamic range, each bit in a digital audio sample represents 6dB of dynamic range. An 8-bit sample can capture a maximum range of 48dB between silence and the loudest sound, where a 16-bit sample can capture a 96dB range.
In a 16-bit system, a signal peaking at -36dBfs has a maximum dynamic range of 60dB. So in effect, this signal doesn’t use the top 6 bits of each sample*. The thinking goes, then, that by normalizing the signal peak to 0dBfs, we “reclaim” those bits and make use of the full 96dB dynamic range.
But as shown above, normalization doesn’t affect the dynamic range of a recording. Normalizing may increase the range of sample values used, but the actual dynamic range of the encoded audio doesn’t change. To the extent it even makes sense to think of a signal in these terms*, normalization only changes which bits are used to represent the signal.
*NOTE: This myth also rests on a fundamental misunderstanding of digital audio, and perhaps binary numbering. Every sample in a digital (PCM) audio stream uses all the bits, all the time. Some bits may be set to 0, or “turned off,” but they still carry information.
Myth #6: Normalizing can’t hurt the audio, so why not just do it?
Best mixing practices dictate that you never apply processing “just because.” But even setting that aside, there are at least 3 reasons NOT to normalize:
-
Normalizing raises the signal level, but also raises the noise level. Louder tracks inevitably mean louder noise. You can turn the level of a normalized track down to lower the noise, of course, but then why normalize in the first place?
-
Louder tracks leave less headroom before clipping occurs. Tracks that peak near 0dBfs are more likely to clip when processed with EQ and effects.
-
Normalizing to near 0dbfs can introduce inter sample peaks.
Myth #7: One should always normalize
As mixing and recording engineers, “always” and “never” are the closest we have to dirty words. Every mixing decision depends on the mix itself, and since every mix is different, no single technique will be correct 100% of the time.
And so it goes with normalization. Normalizing has valid applications, but you should decide on a track-by-track basis whether or not the process is required.
Myth #8: Normalizing is a complete waste of time.
There are at least 2 instances when your DAW’s ‘normalize’ feature is a great tool:
-
When a track’s level is so low that you can’t use gain and volume faders to make the track loud enough for your mix. This points to an issue with the recording, and ideally you’d re-record the track at a more appropriate level. But at times when that’s not possible, normalizing can salvage an otherwise unusable take.
-
When you explicitly need to set a track’s peak level without regard to its perceived loudness. For example, when working with test tones, white noise, and other non-musical content. You can set the peak level manually – play through the track once, note the peak, and raise the track’s level accordingly – but the normalize feature does the work for you.
Myth #9: Normalizing ensures a track won’t clip
A single track normalized to 0dBfs won’t clip. However, that track may be processed or filtered (e.g. an EQ boost,) causing it to clip. And if the track is part of a mix that includes other tracks, all normalized to 0dB, it’s virtually guaranteed that the sum of all the tracks will exceed the loudest peak in any single track. In other words, normalizing only protects you against clipping in the simplest possible case.
Myth #10: Normalizing requires an extra dithering step
This last myth is a little esoteric, but it pops up sporadically in online recording discussions. Usually, in the form of a claim, “it’s OK to normalize in 24 bits but not in 16 bits, because …” followed by an explanation that betrays a misunderstanding of digital audio.
Simply put: A digital system dithers when changing bit depth. (i.e. Converting from 24-bits to 16-bits.) Normalizing operates independent of bit depth, changing only the level of each sample. Since no bit-rate conversion takes place, no dithering is required.
Normalizing can mean a few other things. In the context of mastering an album, engineers often normalize the album’s tracks to the same level. This refers to the perceived level, though, as judged by the mastering engineer, and bears no relationship to the peak level of each track.
Some systems (e.g. Sound Forge) also offer “RMS Normalization,” designed to adjust a track based on its average, rather than peak, level. This approach closer matches how we interpret loudness. However, as with peak normalization, it ultimately still requires human judgment to confirm that the change works as intended.
Original Source Here.