Does software volume leveling degrade audio quality?, A question to audio experts Options

[birdie]

I've heard several times that software volume level'ing actually worsens audio/sound quality and you should never ever touch e.g. audio player volume, you should always change only system volume.

I'd be glad if someone shed some information on this topic.

[Ethan Winer]

Changing the volume of digital audio data does impact quality. But with any competent device, the added distortion artifacts are so miniscule as to not matter. Especially when compared to the 100 times worse distortion you get from even really good loudspeakers.

This was tested recently in another forum using 32-bit math. A fellow applied 120 gain changes in a row to a Wave file, then I analyzed the result. The distortion was about 0.1 percent.

--Ethan

This post has been edited by Ethan Winer: Feb 13 2010, 20:18

[DVDdoug]

Volume adjustments are an everyday part of music production, and nobody worries about it. Mixing (analog or digital) is mostly volume adjustment.

You do have the same concerns as analog volume adjustment -

1. If you increase the volume too much you can get clipping (distortion). And, since most CDs an MP3s are already normalized (maximized) you typically can't increase the volume at all without clipping.

2. If you decrease the volume you can reduce the signal-to-noise ratio. The signal gets reduced, while (some of) the noise remains constant. With digital signals it's the quantization noise.

...and you should never ever touch e.g. audio player volume, you should always change only system volume.

I'm not sure what you mean by that, but suppose you have an iPod hooked-up to your home stereo sysetm... Then yes, you want to keep a "strong signal" coming out of the iPod. If you reduce the volume of the iPod, you probably won't notice anything. But, if you then boost the stereo system volume to compensate, you're going to boost the noise along with the signal.


"Volume Leveling" can mean "Automatic Volume Control". Yes... Automatic volume control or dynamic compression will mess-up musical expression.

[rpp3po]

This was tested recently in another forum using 32-bit math. A fellow applied 120 gain changes in a row to a Wave file, then I analyzed the result. The distortion was about 0.1 percent.

That was probably floating point based, which is the best choice with one exception (that doesn't matter at all in practice): For integer based 24 bit output the upper 256 positions of a digital volume control are completely lossless (0.0% distortion) for 16 bit input. Even across unlimited generations.

This post has been edited by rpp3po: Feb 13 2010, 20:53

[birdie]

I'm sorry I'm not a native English speaker, so I will try to explain my question better.

What I heard is that most software volume level'ing algorithms are far from perfect, thus if you touch an audio application volume (not your audio card volume), then some digital distortions get in.

Unfortunately I know little about the nature of sound so I don't understand the process - what audio is in its digital form, how volume changes can alter digital audio stream (and thus audio quality).

I'm not talking about amplifying sound volume (which may cause clipping and all sorts of artifacts), I'm asking about making audio quieter in audio players - does it affect audio quality?

This post has been edited by birdie: Feb 13 2010, 21:10

[saratoga]

This was tested recently in another forum using 32-bit math. A fellow applied 120 gain changes in a row to a Wave file, then I analyzed the result. The distortion was about 0.1 percent.

That was probably floating point based, which is the best choice with one exception (that doesn't matter at all in practice): For integer based 24 bit output the upper 256 positions of a digital volume control are completely lossless (0.0% distortion) for 16 bit input. Even across unlimited generations.

Changing the volume digitally with 24 bit is still lossy (well unless by a power of two), its just assumed that if you change the volume to some level that has fewer then 8 leading zeros the rounding error will be at less then -96dB and thus practically inaudible. But if you did it enough times it could still add up to something noticeable.

[saratoga]

What I heard is that most software volume level'ing algorithms are far from perfect, thus if you touch an audio application volume (not your audio card volume), then some digital distortions get in.

Yes but its very small. Your audio has already had the volume changed on it several times before you ever get to it, so I wouldn't worry.

Unfortunately I know little about the nature of sound so I don't understand the process - what audio is in its digital form, how volume changes can alter digital audio stream (and thus audio quality).

Changing the volume digitally means multiplying by a constant. Multiplication of decimal numbers is only approximate. There is some error involved which add a tiny bit of noise. Most people consider this process irrelevant unless it is done many times consecutively so that small errors accumulate.

[rpp3po]

Changing the volume digitally with 24 bit is still lossy (well unless by a power of two), its just assumed that if you change the volume to some level that has fewer then 8 leading zeros the rounding error will be at less then -96dB and thus practically inaudible.

The day I finally get this right I'll buy a round! I was about to write 8 lossless positions (from the back of my head), but then I thought that there are 256 different 24 bit values from which you can reconstruct the original 16 bit value after applying the inverse attenuation function. But, of course, you are right: when scaling the 24 bit value to anything not being a power of two, the original 16 bit context cannot be projected evenly into the new set and you get tiny amounts of distortion.

[birdie]

Thank you all very much for all responses (especially Mike Giacomelli ).

[benski]

When Winamp applies Replay Gain, it does so on the floating point output from the decoder.

i.e.

Decoder -> Volume Adjustment -> Decimation -> Sound Card

This minimizes distortion somewhat compared to doing volume adjustments after decimations. Either way, however, distortion should be minimal.

[Arnold B. Kruege...]

Changing the volume of digital audio data does impact quality. But with any competent device, the added distortion artifacts are so miniscule as to not matter. Especially when compared to the 100 times worse distortion you get from even really good loudspeakers.

This was tested recently in another forum using 32-bit math. A fellow applied 120 gain changes in a row to a Wave file, then I analyzed the result. The distortion was about 0.1 percent.

Pedantic point. If volume changes are applied with a properly-designed and dithered digital gain controller, by definition zero distortion is added. What is added is random noise. If that 0.1 distortion you mention was random noise, then we have a noise floor increase to about -60 dB. Since musical recordings commonly have dynamic range on the order of 65 dB, there may have been some audible addition of noise.

Dr. Krueger recommends limiting such gain changes to maybe only 60-100 repetitions! ;-)

We have to bear in mind that some people are seemingly patholgical about signal degradation due to attenuation and gain. One high end audiophile magazine writer whose published and online antics you and I are both way to inimately familiar with has suggested that people remove the volume controls from their audio systems, and implement any of their preferences for listening at various sound levels with an appropriate choice of phono cartrdige with the desired electromechanical sensitivity. IOW, don't change the volume control, in fact don't even have a volume control. Just have a rack full of phono cartrdiges with various electromechnical sensitivities, and choose and install the one that is appropriate to your preferences for the evening.

In any good sytem with a gain control, the gain control is not the weakest link, ever. Not playing the music at an appropriate level in order to avoid audible degradation due to changing gains is just plain self-destructive.

+1 to the several posters who pointed out that gain changes are routine operation in audio production, and other than avoiding the boundary condtions of distoriton due to too loud, and noise due to not enough level, its always sonically benign, and generally advantageous.

However it is also true that creating analytical software that correctly predicts the ideal level for a musical selection seems to still be at least a tiny bit elusive. OTOH, software like Replaygain seems to be an advantageous alternative to simply normalizing.

[rpp3po]

Pedantic point. If volume changes are applied with a properly-designed and dithered digital gain controller, by definition zero distortion is added. What is added is random noise. If that 0.1 distortion you mention was random noise, then we have a noise floor increase to about -60 dB.

With 32 bit floating point samples 0.1% was rather the end result, and thus far away from -60db.

[pdq]

Pedantic point. If volume changes are applied with a properly-designed and dithered digital gain controller, by definition zero distortion is added. What is added is random noise. If that 0.1 distortion you mention was random noise, then we have a noise floor increase to about -60 dB.

With 32 bit floating point samples 0.1% was rather the end result, and thus far away from -60db.

What could 32 bit floating point possibly have to do with 0.1% being equal to -60 dB?

[Arnold B. Kruege...]

Pedantic point. If volume changes are applied with a properly-designed and dithered digital gain controller, by definition zero distortion is added. What is added is random noise. If that 0.1 distortion you mention was random noise, then we have a noise floor increase to about -60 dB.

With 32 bit floating point samples 0.1% was rather the end result, and thus far away from -60db.

????????

Doing the math:

0.1% = 1 part in 1000 = -60 dB

I'm frankly surprised that 120 level changes done with 32 bit arithmetic gave such poor results, even ofer 100s of repetitions.

Must have been 32 bit fixed point and not floating, and must there have been some gain staging problems. IOW the input signal must not have been anywheres near full scale at the beginning and the end. Most reakl world gain adjustments involve signals that peak higher than -20 dB FS at the beginning and higher than -60 dB FS at the end. 60 dB attenuation is close to completely turning the signal off, from a practical perspective.

[rpp3po]

What could 32 bit floating point possibly have to do with 0.1% being equal to -60 dB?

I thought that the loss per iteration in this case for floating point is smaller than for integer data (except for the few lossless cases) and 0.1% is plausible, although even higher than what I would have expected. Also, with floating point based attenuation you should only get uncorrelated quantization error (= random noise) and correlated distortion for int operations as long as you don't re-dither after each step. Or am I missing something?

PS I didn't multiply lg(0.001) by 20, but 10, which is wrong for sound pressure. Arnold is right.

This post has been edited by rpp3po: Feb 15 2010, 16:49

[Ethan Winer]

Dr. Krueger recommends limiting such gain changes to maybe only 60-100 repetitions! ;-)

No kidding, but this was related to what actually happens in a large DAW project. Besides any math on each track due to gain changes, adding dozens of tracks requires dozens of fetch / add accumulations just to sum all the tracks.

I'm frankly surprised that 120 level changes done with 32 bit arithmetic gave such poor results, even ofer 100s of repetitions.

Me too, but I didn't do the test. Perhaps I should try to replicate his results. As I understand it, 32-bit floating point has 7 decimal digits of accuracy. So that's a total of 140 dB dynamic range if the signal stays at the same general level and the exponent stays unchanged. The guy said it was definitely 32-bit FP, and the stating level of the sine wave was -6 dBFS.

--Ethan

[rpp3po]

Me too, but I didn't do the test. Perhaps I should try to replicate his results. As I understand it, 32-bit floating point has 7 decimal digits of accuracy. So that's a total of 140 dB dynamic range if the signal stays at the same general level and the exponent stays unchanged.

More exactly, 32 bit floating point audio has a dynamic range of 6.02 * 2^8 = 1541.12 dB, but a SNR of 6.02 * (32-8) = 144.48 dB. The latter should stay constant at any signal level, since the full length of the mantissa is used for storage regardless of the current exponent.

This post has been edited by rpp3po: Feb 15 2010, 20:52

[pdq]

Me too, but I didn't do the test. Perhaps I should try to replicate his results. As I understand it, 32-bit floating point has 7 decimal digits of accuracy. So that's a total of 140 dB dynamic range if the signal stays at the same general level and the exponent stays unchanged.

More exactly, 32 bit floating point audio has a dynamic range of 6.02 * 2^8 = 1541.12 dB, but a SNR of 6.02 * (32-8) = 144.48 dB. The latter should stay constant at any signal level, since the full length of the mantissa is used for storage regardless of the current exponent.

6.02 * 2^2^8
6.02 * 2^(32-8)

[Ethan Winer]

I'm frankly surprised that 120 level changes done with 32 bit arithmetic gave such poor results, even ofer 100s of repetitions.

Arny, or anyone else, maybe you can help me out with a test method. I was going to try this myself in Sound Forge 6.0, but the SF manual doesn't say what type of math it uses internally for gain changes on 16-bit or 24-bit data files. If you were going to apply 60 gain change up/down pairs, how would you do it?

Also, the guy who did the earlier test used +/- 0.34 dB for each change. I don't know if that's random, or if he picked a change amount that would give the worst results. (He was trying to refute my position that 32-bit FP math is pretty darn accurate.)

--Ethan

[rpp3po]

Arny, or anyone else, maybe you can help me out with a test method. I was going to try this myself in Sound Forge 6.0, but the SF manual doesn't say what type of math it uses internally for gain changes on 16-bit or 24-bit data files. If you were going to apply 60 gain change up/down pairs, how would you do it?

Sound Forge 6 is quite old, I can't guarantee what it uses internally. Nowadays all major audio apps use 32 bit floating point data paths regardless of input. To be sure just convert your 16/24 bit data files to 32 bit float format prior to your experiment. If Sound Forge supports this, you can record two macros: one applying negative, one applying positive gain. Then create a batch job applying each 30 times on your test file.

You can also solve the problem mathematically. Usually 32 bit FP arithmetic is even done at higher precision than 32 bit in hardware, but the worst case would be 60 32-bit re-quantizations. So 60 times you add quantization error smaller than 144db. I'm no audio professional (only a programmer) and don't know how different kinds of noise are summed, but maybe you do.

+/- 0.34 dB is fine.

This post has been edited by rpp3po: Feb 16 2010, 01:35

[pdq]

Please ignore my earlier post. I wasn't thinking.

[Arnold B. Kruege...]

I'm frankly surprised that 120 level changes done with 32 bit arithmetic gave such poor results, even affer 100s of repetitions.

Arny, or anyone else, maybe you can help me out with a test method.

IMO, the best test method is the one that gives the results that are closest to what a naive person or a sophisictated person would obtain in the real world. I would guess that the naive person would use a tool like Replaygain, and a smart person would use one of the standard DAW programs like SF or Audition.

In the real world the music being changed would either be highly compressed rock at about FS, or some wide dyanmic range jazz, pop, or classical.

The actual adjustments would probably in the range of maybe 6 dB (but not exactly 6 dB), probably alternating up and down.

I was going to try this myself in Sound Forge 6.0, but the SF manual doesn't say what type of math it uses internally for gain changes on 16-bit or 24-bit data files. If you were going to apply 60 gain change up/down pairs, how would you do it?

I use CEP 2.1 and its author is no more forthcoming about how it works than you are encountering.

I've frankly never worried about this sort of thing. I never adjust things that much, and I've never seen any bad artifacts. The multi-rep work I have done involved things like converters and power amps, the later of which can actually cause audible changes with not that many reps. I generally do my testing using 32 bit floating point files for test signals and captured signals.

Also, the guy who did the earlier test used +/- 0.34 dB for each change. I don't know if that's random, or if he picked a change amount that would give the worst results. (He was trying to refute my position that 32-bit FP math is pretty darn accurate.)

With audio, even 16 bit math is pretty accurate within reason. Probably the worst math out there is being done by digital consoles, which AFAIK use 24 bit fixed point and 48 or 56 bit accumulators, if memory serves.

If you do things right you do your production steps basically in one pass of each kind of processing, and simply undo change settings and redo until you get what you want.

DAW software varies tremendously, and some of it like PT has changed their processing several times along the way. Other software like CEP has always used very strong algorithms. I believe that it does all processing with 32 bit FP no matter what sort of file you are processing. The few glitches I've encountered were not with the basic processing, but with weaknesses in the UI used to specify the processing.

This post has been edited by Arnold B. Krueger: Feb 16 2010, 14:10

[rpp3po]

The actual adjustments would probably in the range of maybe 6 dB (but not exactly 6 dB), probably alternating up and down.

You can back that up, right? Regarding FP math I would see no reason why 0.1 dB, 6dB, 6.01 dB, or 0.34 dB would make any difference. The result of each gain change (mathematically: multiplication with a gain factor) is saved with the same 23+1 bit of mantissa precision.

Could anyone give me more insight into the math involved in the calculation of FP quantization error? For integer based samples you need to apply dithering after a gain change or you get truncation, since not all samples divide evenly without remainders (except for powers of 2). The amount of noise added with each iteration is thus equal to the amount of dithering noise required (+ the amount of bits lost when attenuating). With FP truncation should not be an issue (and you also don't loose bits when attenuating), since it isn't limited to natural numbers. FP also can't save more than 24 bit precision, but the last digit is correctly rounded from the following (unsaved) digits (32 FP hardware usually calculates with higher precision). So how would you calculate the total quantization noise for FP after n iterations?

And one additional question, that just came to my head: Why do we truncate at all for ints instead of proper rounding?

With audio, even 16 bit math is pretty accurate within reason.

Merging two tracks with 16 bit math leaves you with 8 bits worth of SNR afterwards. I wouldn't call that accurate. Let alone the merge of a 20 track project.

If you do things right you do your production steps basically in one pass of each kind of processing, and simply undo change settings and redo until you get what you want.

One pass on the graphical interface doesn't necessarily mean one pass internally. Especially a multitrack track merge requires very many intermediate gain steps. So it's not too far fetched to ask for the costs of each step.

Edit: typo

This post has been edited by rpp3po: Feb 16 2010, 17:23

[pdq]

Merging two tracks with 16 point math leaves you with 8 bits worth of SNR afterwards.

You're going to have to explain that one to me. When you add two 16 bit integers you get a 17 bit result. Shift right with rounding and you still have 16 significant bits.

[rpp3po]

You're going to have to explain that one to me. When you add two 16 bit integers you get a 17 bit result.

This time I wasn't thinking, forget that! But one bit per multi track merge step is still a lot.

When you add two 16 bit integers you get a 17 bit result. Shift right with rounding and you still have 16 significant bits.

That would still be integer math but not 16 bit math. Attenuation without word length extension always means that you loose about the same amount of information. With FP math the only lost information is the tiny amount of additional quantization error.

This post has been edited by rpp3po: Feb 16 2010, 17:21