---

Wav normalizing is *lossy*.

The reason for this is that all WAV data *does* have to be changed for the volume to be changed, unlike MP3, where a single gain value for the entire file can be adjusted.

---

Basically, no.

But for what you are doing, the loss is of such an extent that I surely wouldn't worry about it.

Normalizing WAV files is "lossy" in the same sense that being charged 4.5% tax on a $1.00 purchase is lossy (since you can't have half a penny or half a bit).

There is a PEAK chunk that can be added to a WAV file. The PEAK chunk stores the peak amplitude value, and thus the file could be normalized by the decoder. Normally it is used for floating point audio.

Saying that normalization is 'lossy' is way overstating the facts. There are rounding errors; every sample must be a discrete 16 bit value. To normalize you multiply every sample by the normalization value. In most cases the result of the multiplication is not an exact 16 bits (like multiplying any number by pi) so the remainder is thrown away. Its a quantization error, the same as creating a 16 bit sample from analogue in the first place. Any lossy compression makes far greater changes in the data.

These errors can possibly add up to something audible if you do enough operations on 16 bit samples (noise reduction, + pop and click removal, + compression, + hard limiting, + reverb, + EQ, etc) but for a single normalization the error is more theoretical than actual in that it will never approach audibility.

Lossless is a well-defined term.

Normalizing a WAV is not lossless.

Its true that normalization isn't exactly a two way mapping, but I did not write anything suggesting that it is, although it almost is, relative to most other things one might do to an audio file. I don't know what numerical value to place on its impact in terms of errors, but I suspect it would compute to a least an order of magnitude less than the operations usually referred to as "lossy." I repeat that a single normalization transform on a file is insignificant in terms of anything audible -- except of course that playback will be at a different volume.

I believe I understand the way in which you are using the word, but I don't recall seeing it applied to normal transforms. These, such as normalization, are not very relatable to the information reduction processes where the term is most commonly used. For my enlightenment, can you point to an accepted definition that includes these other processes?

And within that 'lossy' concept, mp3gain is also effectively lossy. The 'loss' is applied at playback time rather than destructively to the file itself, but its result is surely not a wit less.

You could:

1) encode the WAV files with a lossless audio codec (FLAC, WavPack, etc.)
2) use Foobar to apply ReplayGain
3) use Foobar or Burrrn to write the CD with the ReplayGain values

That should do the trick.

It depends on the source material, but normalization will add no more than 6dB of quantization noise, and will add 3dB of quantization noise on average.

I would define an operation f(x) as lossless, if there exists a function f-1(x) such that f-1(f(x)) = x. Clearly this is not the case with normalization unless it is a multiple of 2 (6dB)

You are simply wrong: the playback is lossy. mp3gain is not. Depending on the decoding setup, this does or does not make a difference, but it certainly is something different from doing it with a WAV.

You can reverse the change 100%. This is not possible with WAV. This is why mp3gain is lossless, and gaining a WAV is not.

Meaning, you can put any mp3 file into mp3gain, run it through, undo it, and end up with the same file. No information is lost, original is 100% recoverable.

You cannot do this with WAV except in degenerate circumstances.

Is this important? It depends on what you want to do. Consider switching between album and track gain 100 times. No loss with mp3gain. With a WAV, you might have issues.

It seems to me at least, that this is a rather theoretical oversimplification of the problem.
The original poster wanted to know if normalising a wav was lossy, to which you, Garf have said "yes" and AndyH has said "no".
I agree with Andy.
No, it's not lossy.
Yes, as AndyH suggested, there are minute rounding errors at the bottom end of the dynamic range, but not enough for you to hear it after just one transform.
Garf, I appreciate your theory that normalising a wav up and down 100 times might introduce errors, but that's not a real world example, is it?
The orignal poster wanted to normalise some wavs to burn to CD, which only amounts to one transformation of the wavs, not 100's.
So, what we're really talking about, in this instance, is... is it lossy after one transformation, to which I'd say again, "no".
And to the human ear (which is analogue), the same distortion (if you want to be a real stickler for the numbers) introduced by normalising a wav prior to burning to CD, will also be introduced by gain replaying an MP3, because it's still just a 16 bit source, and if you normalise it on playback, there is stil real time "distortion" happening to the bits at the bottom end of the dynamic range.

Just out of curiosity I took a CD track and normalized it. In this case that was a fairly substantial 5.71dB increase in amplitude. Then I reversed the process by amplifying by -5.71dB. I mixed-pasted inverted the original into this result. As a rough and ready measure, the Average RMS measurement across the final outcome of these two normalization operations is -95.3dB – almost certainly very difficult to detect by ear.

For comparison I converted that same track to a CBR320 mp3, then decoded it. The Average RMS on the result of mix pasting the original back into that result is -63.4dB. This is also very small, but it is an order of magnitude larger that on the normalization operations.

I'm not saying this is the best way of comparing the two processes but it does give some idea. Also, normalization is only one operation, there is no additional change at playback, so the actual error is less than indicated here. MP3 playback requires both operations.

I did not get my request fulfilled for a definition of ‘lossy' that includes transformations such as normalization. Its more common usage refers to some process that actually reduces resolution rather than one that simply has small errors.

The process esa372 described is, unfortunately, just another, rather long winded, way of applying normalization. It cannot result in any less error.

The rebuttal to my comment about mp3gain did no more than restate my position; I did say ‘effectively.' I understand the difference if we consider the file as a starting point for further software transformations, but the result to the listener of the music is the same. In the sense that the inquirer asked the question -- does it 'degrade' my music -- mp3gain is no more 'lossless' than is normalization.

I don't think we really have any disagreement here except on the definition of one word. There doesn't seem to be any great confusion about what actually happens, no?

I don't think that can be reproduced. (edit: If it can, it's not a fair comparison.)

Wav normalization is certainly not lossless, therefore it must be lossy.

-

Not really. Your old tracks will be the same, but the new tracks will be different from the originals; they will all have been altered to have a similar volume level.

edit:


Well said.

Here's another vote for Replay Gain, which is better than peak normalization.

The Japanese term for "lossless compression" is (edit: literally) "reversible compression." The Japanese term for "lossy compression" is "irreversible compression."

If it's reversible, it's lossless. If it's lossless, it's reversible.
If it's irreversible, it's lossy. If it's lossy, it's irreversible.

Peak normalization is irreversible; therefore, it is lossy.
On the other hand, mp3gain is reversible; therefore it is lossless.

--- --- ---

I don't think I've ever heard people say "lossless" to mean "preceptually virtually lossless."

The term "Lossy" of course just reffers to the fact that a loss will occure, no matter how small or how imperceptible it is... You cannot say that just because the loss is neglible then the process sudently isn't lossy anymore...

Absolutely

Edit: Beaten by kjoonlee

If you look at what Burrrn is actually doing, you will find that steps 1 and 2 are completely unnecessary. Burrrn does not use the Foobar replaygain values; it takes the wav files (after decoding if necessary) and applies WaveGain to them.

Maybe I overstated reality when I said that everyone know what is actually happening. This process of "write the CD with the ReplayGain values" is first normalizing the file, then writing it to the CD.

We have two aspect of the difficulty here. One is that some of you have decided to apply the term 'lossy' to quantization error. There is no argument on my part that there isn't an irreversible change, but I suspect you can't find your definition of lossy anywhere used by the rest of the world. Normalization is definitely not compression, of any sort. Lossy just isn't the correct word in that context. Show me that I'm wrong and I'll acknowledge it. Ok, I'll even acknowledge it here: it is the slang usage this group has adopted as its own in-group speak; I should recognize the sloppy terminology in the future without comment.

The other aspect of it is that my original post was simply an objection to that technically incorrect use of the term (lossy) ...because... I saw it giving the wrong impression to the person asking the question. I sort of assumed Bourne understood the lossy concept and was just ignorant of its involvement, or non-involvement, in his operation of interest. That he understand the term may be assuming too much, I don't know.

Surely the only useful reason for wanting to know about the results when making a compilation CD, which is just something to listen to, is to know whether or not it might degrade the audible quality. With any lossy compression there is always that possibility, but with normalization there isn't, therefore the difference has some meaning.

Bananas have a yellow skin. That sour oval shaped fruit has a yellow skin, therefore it must be a sour banana? In the usual use of the term lossy, your application to compression is correct, your application to normalization is not. However, I don't think that horse can even twitch a muscle any more, so I think I'll quite beating it.

I don't know what you mean either by reproduced or fair. If you think I can't do it again and get the same result, or that someone else can't do it and get the same result, you are wrong.

For some kinds of situations, the mix-paste inverted is very good for presenting a picture of what has, or has not, happened. It might even give you some idea about the differences you hear (or don't hear).

When used to compare an original file and its perceptually encoded, then decoded, version, it is a much less useful tool. It really isn't any kind of a guide at all to differences in the sound of playback, which is what one is usually interested in. It does give some insight into how much the file is physically changed by the process but not to the relevance of the changes.

Again out of curiosity I did the same test but resample the file to 32 bit before doing the amplification, de-amplification. Then I resample back to 16 bit to compare with the original. This time the Average RMS measurement on the result was -117dB, rather well below perception I suspect. Common advice is do all transforms in 32 bit but when the straight operation gives -95dB, is there any reason to strive for -117dB? It depends on how many operations you are going to do.

I also tried the experiment of simply resampling to 32 bit then back to 16 bit, then did a mix-paste inverted with the original. All measurements were either minus infinity or zero, as appropriate. There might be rounding errors, but they are clearly well below 16 bit resolution. However, if resampling the bit depth simply changes the data type of the number then I think that probably means there is actually no change that could possibly effect the final result, i.e. no errors. Only applied transforms could make any difference.

You're using straw man tactics to refute what I haven't said.

Also, you're still not doing a fair comparison.

1. Pick an MP3 file. Decode it to .wav.
2. Decrease the volume of the original MP3 file
3. Increase the volume of the MP3 file from step 2. Decode it to .wav
4. Decrease the volume of the .wav file from step 1.
5. Increase the volume of the .wav file from step 4.

Files from step 1 and step 5 will be different, so the wavgain process can be proved to be lossy.

Files from step 1 and step 3 will be the same, if nothing goes wrong. In such cases, MP3Gain would have been lossless.

A fair comparison of what? I did a comparison of the amount of change due to errors (normalization) vs the amount of change due to a lossy process (least lossy encode to mp3). The point of it is that the amount of change due to normalization, which is not technically a lossy process, does not compare to that from even the least mp3 compression, which is a lossy process.

Technically, a lossy process is one which deliberately discards data (data that is ‘expendable' by the criteria of that particular process). Normalization definitely does not do that. Lossless is simply used as contrast for a process similar to the lossy one that does not discard data. Compression is the main data manipulation to which the terms correctly apply. That lossy isn't exactly reversible is simply a measurable characteristic, the result not the cause.

Someone borrows money from you. You being a sharp operator get an agreement for 3.25% interest compounded every day. After a number of weeks the person returns with the principal and some extra to pay your interest changes. You make the calculation and exact your due, down to the last penny (this is the smallest measure of physical money in the U.S., 0.01 dollar, in case you are unaware of U.S. currency terms).

But wait, the calculation that gave you the amount to charge wasn't exact to the penny. One bank I did business with explained that to duplicate their results I had to carry out all my calculations to 12 decimal places. Whatever number of decimals you choose, rounding will be involved. It is extremely unlikely your final result will come out to the even cent. You will round up or down in order to know exactly what to charge. Do you call that rounding lossy? If so, I say you are really stretching the language, making up your own definitions as you go.

Your suggested test is between destructive and non-destructive processes. As applied to audio editing and similar activities, a destructive process alters the source data, a non-destructive one alters the data as it is being used in real time, without changing the source. What's to argue about there? What's to test? Whether or not some particular process is destructive or non-destructive? Who raised that question?

Perhaps it was raised in the suggestion to use ReplayGain (a non-destructive process?) within a CD writing application. ReplayGain may be non-destructive, not altering the original source, but its result in the data that is written to CD will of necessity be destructive (but not lossy, no data is discarded), the file written to the CD will contain altered data. This is normalization by another route. I don't, however, see how that relates to the tests I ran. I also don't know how many ways I can say that my posts had nothing what-so-ever to do with any claims that data is not altered during normalization. I never even slightly suggested that normalization is non-destructive -- but of course it can be.

You can't write files to an audio CD that are both normalized and unchanged from pre-normalization, but you can do normalization non-destructively. Normalization is another word for amplification. It can be positive (increase) or negative (decrease). Normalization, as it is most commonly used in digital audio, is just a special case of amplification where the amount is (usually) automatically calculated by a program and applied across whatever audio is selected.

When levels are adjusted in a multi-track editor, perhaps also in some simpler editors, the process is non-destructive on the sources. It is only applied destructively on a mix-down file. During editing, all processes, such as the level adjustments, are applied in real time as the data is played. This is exactly what is accomplished in any non-destructive process, such as the MP3Gain you suggested for testing. There isn't any difference.

Technically, every process that involves a loss, that being rounding errors or not, is simply a lossy process and hence, WAVE normalization is definetely lossy(as it isn't lossless). The fact that lossy compression has a bigger loss than WAVE normalization does is entirely besides the point, as we are not talking about lossy compression here, but simply a lossy process in general...

This is truly broke record country. That has been said a dozen times in this thread, but "technically" the declaration is not correct. In this group's mind set it seems to be, but try to find a genuine, generally accepted definition that says any such thing. Lossy refers to the process, primarily compression. It is lossy if it deliberately discards data. One consequence of lossy compression, one particular detail, is that it isn't completely reversible. The data that has been discarded, with deliberation and forethought, doesn't come back when the file is decompressed.

People in these parts have latched onto that one consequence of the process and declared it not only be the defining cause but have then applied it to anything they consider to have an even remotely similar consequence. Therefore, by that view, if I open a file in an editor, then save it, it is lossless. If I open it and change the value of one sample by increasing or decreasing its value a tiny amount, then save it, it is lossy. If I add reverb, then save it, it is lossy. Certainly those are destructive change, but aside from the fact that they aren't compression, which may be the only place the word is "technically' used, no data has been discarded, the defining process for lossy.

It seems to me much like the use of "RIP" around here. This started out as a slang term for DAE. Asking why people want slang is pointless, but at least most other places I've read anything people keep their head straight as to what they are talking about. I can only imagine the evolutionary process that has gone on here.

Someone who has no idea about what goes on uses the word in a incorrect way. Instead of educating him/her, the majority sloppily incorporate that new view into their way of talking about whatever is the immediate topic. Eventually, case by case, it reaches the current exceedingly vague state of being used for: just what? Virtually any kind of data movement, it seems to me, making no distinction between process that are really quite different from each other. It is almost a 1984 newspeak kind of thing. Reduce the vocabulary so people can't think clearly about differences and it becomes easier to channel their limited thoughts onto controlled paths.

I am not with the language police and I don't propose to pursue people that continue down that degenerate path, but I hardly accept it either. It is hard enough to think clearly without introducing more impediments. A perusal of this thread's contents, could anyone be able to stomach making it, would show there has never been any serious dissension about what happens to the data (other than a few incorrect details by a few people)

It started with me pointing out there is an order of magnitude difference in the consequence of two different processes, where lossy was used in a "technically" incorrect way. It developed into a debate as to whether or not I adopt this special definition of a standard word. Its fun for awhile, but isn't enough enough?

There should be no reason for language ninjutsu here.

It should be very clear if a process is lossless or not. It should not even factor if changes due to processing are subjectively noticeable or not. If data is lost or changed in the process, it is lossy. I'd like to think that yes, our definition is 'technically correct.' Considering I have no idea you can manage to extrapolate any other definition from the word, 'lossless.'

Being subjectively lossless doesn't make it lossless.

It has nothing to do with subjective. It is the standard use of the word in the world outside HA. That does not include "data is ... changed in the process." This isn't hard to understand.

Maybe I'm wrong. I've asked for a source other than people's emotions quite a few times now. I can find plenty of sources for my belief. It is possible none of them say anything like 'exclude other possible descriptions,' but there don't seem to be any standard accepted definitions that fit the local usage, while what I've said about it is found all over the place.

Actually, i'll think you find that outside the world of HA, if data is changed in the process, it's still called lossy, otherwise WinZip/WinRAR/7-Zip would not work.

Well if people outside of here are referring to a lossy process as lossless (or the other way round) then all it means is that they lack understanding of how digital compression works. The definition of lossless should be implied by the word itself.

Just because alot of people are using the term wrong does not mean the definition should change.

I'm not interested in getting into the "what is lossy" debate, but I would like to add something about wav normalization.

Using the strict mathematical sense of the word lossless, a wav normalization in the increasing direction (i.e. gain > 1.0x) would theoretically be lossless because it could be exactly reversed, even if pseudorandom dither had been applied (true random dither would destroy information, but I don't suspect that's too common). Of course, a little information would have to be stored about how the transformation was done (like MP3Gain).

On the other hand, wav normalization that reduces the level is certainly lossy, effectively raising the noise floor by the same amount as the audio is reduced. And this is, unfortunately, the direction that ReplayGain generally turns out to be.

edit: added paragraph break

You can edit the parameters for the decoders so that it uses replaygain when decoding. In Settings look at the Decoders tab.

How exactly would you do this? I.e. what are the correct parameters? I'd like to have this information, could come in handy.

You have not read this discussion. Its content is not what you addressed.

These examples are all compression schemes. This IS where lossy/lossless are used correctly, unlike in most posts of this debate.

None of this debate is about whether or not information is changed or whether or not it is a reversible change. It is all a rather funny bit about the adjectives applied to the processes. Some processes are destructive and irreversible, but find the dictionary or textbook that calls them 'lossy' simply because of that. A lossy process is one where data is deliberately discarded, according to some systematic rules, not one where there are simply rounding errors.

So rounding is not discarding data (digits) according to systematic rules ?

AndyH: since you have sources that back up your claims, why don't you just post them. This debate is getting rather silly proportions.

Put "lossy" into Google and get pages of references. Look at what they are about. These include a variety of dictionary and encyclopedia entries, and a large number of articles about ----- data compression. Yes, it is a bit silly, but it has been amusing.

No, I would say that when you have a number container of a specific precision and it is obviously the case that it is impossible for it to hold any greater precision, doing calculations with it is not discarding data. It might or might not involve reducing precision of some of the results. Do you understand "significant figures?" Quite aside from the terminology, it can't be discarding data if it isn't data.
http://www.angelfire.com/oh/cmulliss/

Surely a comression is lossy if the original data can't be restored bit-by-bit!

But for me the question is: Will the round not appear if you use replaygain? Isn't the audio-output (on the soundcard) of a levelled wav not the same like the original wav with replaygain?

That would mean that it isn't "more" lossy than replaygain....

Big_Berny

AndyH-ha: Do a search for lossless-join decomposition (funny enough also related to 'normalization' ). A decomposition is called lossy when the original data cannot be uniquely recovered (iow the process is not reversible). So now you have the word lossy used in a "technical" context where indeed whether the process is reversible or not matters.

Big_Berny: the difference is the reversibility of ReplayGain (can be done) and normalization (cannot always be done).


edit: spelling, spelling, spelling...

Yes, I know. But there isn't a difference in the soundquality, right?

Garf essentually said in the first two replys of this thread that

1. Wave normalization is not generally lossless.

but

2. For the proposed usage the extent of data loss would be neglegable.


I don't believe we have moved from this point. It was correct then and is correct now.

The only other worthwhile thing that has been brough forth is Bryant's observation that upward wave gain is generally reversable (not withstanding clipping or non-deterministic dither).

Reducing precision is indeed discarding data, when the precision can never be recovered.

The stumbling block here seems that you only apply the terms "lossy" and "lossless" with regards to compression. However, the rest of the world applies them more generally to processes of any sort. A process is lossless when it can be reversed. Nothing is lost.

Compression is a process. But then, so is rounding (or truncating, as the case may be). Applying the terms lossy and lossless to both of them is equally justified.

Furthermore, you went on earlier about the "amount" of change being a factor, but the terms are not that specific. Yes, the amount of loss in a rounding operation like this being applied to a WAV is extremely small, but it nevertheless exists and is real. It is indeed lossy. If you want to apply a judgement call on the amount of change, then where, exactly, do you draw the line in the sand between lossy and lossless? A normal person would say "if there is loss, then it is lossy", because that would be the obvious line.

Well, there is loss. You can never recover that precision. It is, in theory, audible. It is a loss that is additive over multiple operations (this being why most good audio programs actually represent the data as floating point in memory, only converting to 16-bit when saving). Okay, so it's minor, but that does not matter when the question is "is it lossy?".

WTF is this so difficult to understand ?
If the change is irreversible, it is lossy. End of story.

The part about lossy comression is true, but unfortunately you don't win any points because you have not figured out what this debate is about (hint: it is not that).

I'm not sure what you are asking in the second part of your post, but as to what I think you are asking, the answer is ‘there is no difference between normalization and ReplayGain' so far as what comes out the end of the reproduction chain for you to hear. They are both doing the same thing to the data, giving the same result. The difference is that ReplayGain does it in real time each time the audio is played, normalization does it one time by modifying the source data.

I'm not sure if this is offered tongue-in-cheek or not. It does point out a legitimate technical use of the words unrelated to data compression, so I have to concede that, but alas, this use is quite unrelated to audio or signal processing. Also, I don't think you can, by any stretch, draw an analogy between database normalization, or measurement normalization, and audio file normalization.

Using "wave gain" where the discussion was about normalization is getting kinda sloppy in the current context. Regardless, I think what bryant said in that post is not true, at least as stated. Am I missing something?

Usually we are discussing 16 bit integer data, simply because that is most what people here deal with, but this should apply in the same way to 32 bit or 64 bit floating point (or whatever format):
Initially, each sample is some specific value. Once the file is normalized, each sample is some new value. This new value is arrived at by applying a factor to the original value via a multiply. If the transform is dithered, additional changes are applied.

There now exist some particular difference between the original sample value and the new sample value -- but, at least for the normalization part, it is a different difference for each sample. Therefore, to be able to get back exactly to the original, that specific difference must be stored for each sample. It can not be recalculated from a single factor the way the normalized value was calculated. That is the reason it is irreversible.

This is not a ‘little' information that has to be stored, relative to the amount of original data. (Some, probably quite small, amount of lossless data compression might be done on this difference data to take advantage of the places where some number of adjacent samples have exactly the same value, or possibly where there are more complex patterns.)

The storing of difference data and the restore of the original values would work exactly the same way whether the normalization increases or decreases the amplitude, or even if it results in clipping. The noise floor does not enter into consideration.

Let's consider a reasonable example that isn't lossy data compression, such as resampling 16 bit to 8 bit. There are probably audio operations other than resampling that might be used, but none come to mind at the moment. In most transforms, such as normalization, to choose another example, there is no loss of precision.

Resampling to a lower bit depth (or sample rate) indeed results in a loss of data, and it is deliberate. Its magnitude is probably comparable to that of fairly severe (i.e. to low bitrate) lossy compression, but I don't see its parameters as comparable to the ‘deliberation' that is done in lossy compression, a choosing of what data to discard in order to achieve a particular goal. I guess that could be argued either way.

More important for this debate, however, is that ‘lossy' just isn't the term applied to it. You say "the rest of the world applies them more generally to processes of any sort." That is exactly what is not true.

And you know this because you had a mystic insight into the true nature of life, the universe, and everything? Because your mother told you so? Because you have an emotional need for it to be so?

You also are missing the point of this debate. Your heart-felt declaration of your belief does not make it factual. You need evidence to back up your claim. It is not self evident and it is not available from an examination of the process. ... I don't believe evidence exists (that supports your position).

So what do you want to call it then?

A 'sorta-lossy' process?

That's still lossy.

Yuck.

In the professional meaning of the word, permanently adjusting volume levels of audio data will never be considered "lossless."

But whatever, not everyone is a professional

This isn't about what I want to call a destructive edit, it about what the 'professional' audio world calls it. Being professional 'they' are a little more exacting with their use of technical terms than is this neighborhood.

The first person who replied on this thread is a professional, you know.

They call it 'adjusting the volume?'

This thread has developed into a rather deep philosophical debate, which is all very well, but unfortunately the OP's original question seems to have been largely forgotten, and (s)he is probably still wondering what (s)he needs to do to achieve his/her goal. To recap:



Let's begin by noting that *normalization* of WAV files will not achieve Bourne's goal. The generally accepted meaning of "normalization" is the application of linear gain so as to bring the peak level of the file to a standard level (typically 0dB). However, the perceived loudness of a track is just as much dependent on the dynamic range as it is on peak levels. Therefore simple normalization won't do what Bourne wants.

Algorithms such as ReplayGain will determine the linear gain required in order to achieve a given perceived loudness by taking into account the dynamic range as well as the peak level. However, if the original file has a very large dynamic range, there is a danger that the required gain is so great that it would result in the peak levels being pushed into clipping. And you *really* don't want that to happen. In order to avoid this, you have three options:
(i) choose a very low "target loudness" for the ReplayGain algorithm, so that all linear gains calculated are certain to be less than unity (ie. result in a loudness *reduction*). The downside to this is that all your mix CDs will be very quiet.
(ii) Accept that those files with a large dynamic range are going to sound a bit quieter, and apply the maximum possible gain without causing clipping - in other words, normalize those files to 0dB. The downside here is that your mix CDs will still have variations in loudness between tracks.
(iii) Apply some dynamic range compression so as to reduce the dynamic range of the quieter files, which makes them sound louder. The downside here is that dynamic range compression tends to "squeeze the life" out of music, so it should only be used in moderation.

I don't have any practical experience using WavGain, but my understanding is that it uses the ReplayGain algorithm to determine a linear gain that is applied to the WAV file. I don't know whether it backs off the required gain in order to avoid introducing clipping - perhaps someone else here can verify this.

If you want to persue option (iii), then you might like to try out a piece of shareware I wrote called Volume Balancer. It doesn't use the ReplayGain algorithm as such, but it does use similar dynamic range measurement to determine perceived loudness and then applies linear gain and/or dynamic range compression in order to bring a set of WAV files to a defined level. It only uses compression where the target loudness cannot be achieved through linear gain adjustments.

One last thing. *All* of these processing options for WAV files result in non-reversible changes to the audio data, and so in a formal sense they are "lossy". But from a practical point of view options (i) and (ii), which involve only linear gain adjustments, are benign. Option (iii) is less benign, but may in some circumstances be the best compromise.

Bourne, the original inquirer, asked about CoolEdit's Group Waveform Normalize which I believe is an RMS based process used to balance perceived loudness. I'm not positive about that, as I've never had interest in doing that task, but I seem to recall reading that is its purpose.

You introduce a new descriptor "formal sense" into the debate. Have you any evidence, that being the sticking pont or the whole issue? I maintain that is an incorrect use of the term lossy. Its not losing anything, its changing it, but more importantly, it isn't the accepted technical use of the term.