Normalize or Compress First?

Page: < 12 Showing page 2 of 2
jardim do mar
Silver Bronze
  • Total Posts : 1247
  • Joined: 2003/12/02 06:23:57
  • Status: offline
RE: Normalize or Compress First? 2004/11/02 14:07:37 (permalink)
If you use RMS values and normalise to 0dBfs or close to that, you would be clipping the peaks of your audio. Not a good idea.

Hi under tow,,,

this might be true sometimes but should not be used as a guideline...

the result of normalizing a track at 0db using RMS power generally will result in a compression (effect) meaning it will not "clip" but might contain some distortion ,,(which could be used if needed) I quickly tested 5 ..4 min. audio files in soundforge ,,,using the normalize set at 0db with RMS power and the results were as I mentioned... as a rule it's good to use RMS when normalizing, RMS will measure the sound(over time) and peak just grabs the highest db, in essence the RMS will give you a better reading ,, I achieve good results with "meta normalize" in wave lab and "group wave normalize" in AA1.5 when mastering.. Naturally ,,knowing how to,,what to and why is, the adjustments being made,,, help,, IMHO,, working with audio there are no set rules ,,just guidelines to follow/start with .. (sometimes). IMHO,, you just throw all the numbers out the window and "let go and flow" to quote sonar,,,,, as always.. use the ears......

naturally these are "my" learnings and experiences and doesn't necessarily make them "right"
< Message edited by jardim do mar -- 11/2/2004 2:25:09 PM >

And Remember,,,,One thing at a Time.....
Silver Bronze
  • Total Posts : 2099
  • Joined: 2003/11/07 17:26:14
  • Location: Colorado Springs, CO
  • Status: offline
RE: Normalize or Compress First? 2004/11/02 14:43:20 (permalink)

Your audio is in 24 bits which means it has 16777216 "amplitude slots" for each sample. Or put otherwise, 16777216 possible different levels for each sample. Everytime you do a gain change, the chances of the samples falling at exactly the right place is close to nil. So the samples have to be quantised into those 16777216 slots. That is called quantisation errors. This is audio degradation.

Ahhh now, this is where *I* think your wrong. I can only talk form the point of view of the DXi Plugin's I've worked with, but as far as I can tell internally Sonar is working with high precision Floating Point numbers. So when your audio is created, it may come in at 24 bit, but internally thats represented as a number between -1.0 and 1.0. It's only at output time that it's converted (in sonar 4 through the wonderful POW-3 dithering) back to 24 (or 16bit) quantisation.

So in your normalisation example you are not introducing any quantisation error since you are working with floating point numbers.

Andy C
As ever this is jut my interpret ion of whats going on !

I don't think the point is valid.
1. Floats can still ahve quantization errors. While they reflect decimals, they still have a limit amount of precision I remember old C classes where adding 2 and 2 could produce a result like 4.0000000000000001 when using floats.

2. It's negligable in either case. The quantization error will make the result less than one millionth off, even with 24 bit.

If the sound was recorded too low to start with, the normalization is going to be less accurate, but turning up the gain will have the same issue.
Andy C
Silver Bronze
  • Total Posts : 1257
  • Joined: 2003/11/04 10:09:38
  • Location: Scotland
  • Status: offline
RE: Normalize or Compress First? 2004/11/02 15:04:50 (permalink)
ORIGINAL: mlockett
2. It's negligable in either case. The quantization error will make the result less than one millionth off, even with 24 bit.

Which is the point I was trying to make ! I think Dave's point about raising the noise level during normalization is much more important !

Silver Bronze
  • Total Posts : 2045
  • Joined: 2004/05/01 21:52:56
  • Location: North Wales
  • Status: offline
RE: Normalize or Compress First? 2004/11/02 15:23:19 (permalink)
Well I'm trying to put several tracks onto a CD that I can listen to in a car, and distribute to friends, etc. My issue is that one particular project uses my old Roland SC-55 Sound Canvas as a MIDI playback device and the individual volume on each track is a bit low- so that even with the master volume on the SC-55 turned up all the way as an input to my Delta 1010, I'm not getting as much signal as I'd like for the final wave file. I then use SONAR 4.0 export to dither down to 44.1 and 16 bit for my CD-burning software to work (although my native Delta 1010 and SONAR 4.0 resolution is 24/96).

I might be doing it all wrong which is why I'm posting here.


firstly, Have you got the correct input sensitivity level set on the Delta? try changing the +4/-10 setting (a black pushbutton next to the jack input) and see if you get a decent level.

Secondly, the bigest problem with normalisation is that it raises the noise floor.
It also leaves you with no headroom left to further apply processes (even dipping in an EQ may produce a gain change, as the frequency you're lowering may have been cancelling out another frequency/harmonic, which would then be increased)

and it also introduces quantization error, which for most domestic users won't be noticeable, but bad practice is bad practice.
Gold Member
  • Total Posts : 3848
  • Joined: 2004/01/06 12:13:49
  • Status: offline
RE: Normalize or Compress First? 2004/11/02 18:58:25 (permalink)

ORIGINAL: mlockett
2. It's negligable in either case. The quantization error will make the result less than one millionth off, even with 24 bit.

Which is the point I was trying to make ! I think Dave's point about raising the noise level during normalization is much more important !


We are talking about normalising the very final stereo file. This will increase the volume AND the noise floor in exactly the same amounts. So there is no change in the S/N ratio. This is similar to increasing the level on your amp. The signal goes up but so does the noise. So this is not an issue.

The only point in normalising in this case is to get the final CD or whatever to be as loud as others. It is pointless to have a few dB of extra headroom on the final CD ...

Bronze Member
  • Total Posts : 413
  • Joined: 2004/08/02 21:12:50
  • Status: offline
RE: Normalize or Compress First? 2004/11/03 00:14:51 (permalink)

This is the most ridiculous discussion I've ever heard in my twenty years as a programmer. If you're going to try and teach someone something, please be sure you know what you are talking about. A quantisation error of .00000001, give me a break. How many quantization errors of .0000001 will I have to have in order to ruin a track? About a hundred normalization processes? A thousand? Ten? By all accounts in this stinking discussion, kicking the gain on multiple tracks should make me wind up with music that is just unlistenable. Take a listen at this track of mine: Everlasting Love.

Every track on this mix has gone through multiple normalization(in SF not CW btw cause CW normalize sucks donkey dick) and compression(UAD-1 Fairchild & Sonitus Multiband). I'm still experimenting and this is by no means a final "I'm Done With This Track" mix(neither are any of the others there), but it is pretty close to what I'm shootin for. Changing the volume is just that, changing the volume. Whether you use a plug or CW's trims and faders or a stinking normalization to equalize the peaks on a bunch of tracks. If you recorded at -64db and normalized to 0db, yes it will sound like crap. Same if you were using tape and recorded at -64db and increased the gain to 0db. The noise floor gets just as much of a lift.

The absolute correct answer is: if you really have a low gain track, you need to re-record IF POSSIBLE. If you're only choice is increasing the gain and gating out the noise floor. In the digital realm, raising the volume of an audio track is not much different, mathwise, than increasing the brightness on a digital image except that on a digital image, it is raising/lowering three different parameters equally and on audio it is only one. Load up an image in Photoshop(or you editor of choice) and kick the brightness up. If I were to follow the logic set forth here, the reds should start turning blue and the blues purple, etc.

I'm sure that normalizing, then compressing, then normalizing, then limiting, then normalizing, then eq, then limiting yet again will start to destroy a track, but the track above has broken every one of the recommended gotchas listed here and at least IMHO, sounds pretty decent. And actually, most plugs have an output fader on them. The logic set forth here says that every stinking plug I use and happen to kick the gain a db or two on three or four different plugs, would end up with a unusable track.

Sorry for the rant folks, but fer gad sake this is truly a ridiculous thread.

- Guitardood
Bronze Member
  • Total Posts : 61
  • Joined: 2004/01/06 20:16:31
  • Location: Chicago
  • Status: offline
RE: Normalize or Compress First? 2004/11/21 21:25:55 (permalink)
Thank you everyone for your input- judging by the number of replies here it appears there a lot of opinions on this subject.

I believe the most useful reply was the one that recommended I double check the -4/+10 setting on the back of the Delta1010 where the Roland SC-55 is plugged in.

And yes, I know there are good hardware modules out there that are a lot newer than my old trusty SC-55. But I'm currently using Gigastudio for most of my sample playback needs, along with my Yamaha S80 in multitimbral mode.

I think some people when they record are going for absolute perfection, but if you take this to the extreme one might never stumble across new and often useful ways of altering sound. Heck, look at some of the oddball tricks the beatles used with tapes- I'm sure some of the purists of 60s would have cringed at the techniques they used. But in the end the songs kicked butt.

Silver Bronze
  • Total Posts : 2447
  • Joined: 2003/11/13 13:01:40
  • Status: offline
RE: Normalize or Compress First? 2004/11/21 22:00:05 (permalink)
< Message edited by tazman -- 11/21/2004 9:09:20 PM >
Page: < 12 Showing page 2 of 2
Jump to:
© 2014 APG vNext Commercial Version 5.1