If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade? IE, accidently running dither again over the now
16-bit file. Also, what about dithering 24-bit to 16-bit if the original
recording is 16 bit. Ive done this by mistake a few times. Does it do much
to the signal?

Dave

In article ,
"DaveDrummer" wrote:

If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade? IE, accidently running dither again over the now
16-bit file. Also, what about dithering 24-bit to 16-bit if the original
recording is 16 bit. Ive done this by mistake a few times. Does it do much
to the signal?

Dave



It adds a very small amount of noise and you probably wouldn't notice an
extra pass or two unless it's a very quiet passage or some delicate
classical music, and even then, without A/Bing, you'd probably just
assume it's the natural noisefloor.

Thanks.
--
Jay Frigoletto
Mastersuite
Los Angeles
promastering.com

DaveDrummer wrote:
If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade? IE, accidently running dither again over the now
16-bit file. Also, what about dithering 24-bit to 16-bit if the original
recording is 16 bit. Ive done this by mistake a few times. Does it do much
to the signal?

I am not an audio processing guru, but I do know a little about image
processing (and I stress that it's a little), which also uses dithering
for similar purposes.

Anyway, it seem like it would depend on the particular dithering
algorithm used. Some dithering works by adding a certain amount of
noise to the signal before rounding down to the smaller precision.
This type of dithering could produce additional noise if the amount
of noise it adds is large enough.

Basically, when converting from 24-bit to 16-bit samples, you have
three bytes:

aaaaaaaabbbbbbbbcccccccc

and you are getting rid of the all the bits labelled "c". In your
case, if you converted directly from 16-bit to 24-bit, all your "c"
bits would be zero. For example, if you convert this 16-bit quantity:

0011010101010111

into 24-bit bit, you will get this:

001101010101011100000000

Random dithering would add random noise to the lower 8 bits and then
round to the nearest 16-bit value when converting. But how much
noise does it add? If the binary values it adds vary between
+127 and -127, then it will never round to anything different than
it rounded to when those bits were all zero. Only if you add numbers
starting at +128 or larger (or starting at -128 or smaller) can it
ever affect the value that you round to. In other words, when your
last 8 bits are all exactly 0, then you are exactly in the middle,
really far away from the points where you would switch to rounding
to a different number; therefore, you have to add relatively large
numbers in order to round to a different number.

That covers dithering that works by adding random noise, but there
are other forms of dithering, such as those that choose a current
value based on accumulated rounding error for the previous values.
In other words, if you were working in decimal numbers, they'd
convert 11.3 to 11.0 but remember that they were 0.3 off. Then
on the next sample, if you see 10.4, you might convert that to
11 as well, since you know that this means your total error
will be minimized. I'm not 100% sure they use this type of
algorithm for audio stuff (seems like it could introduce
high-frequency junk in some cases). But anyway, the point is
that with something rounds based on accumulated error, if you
are converting 16-bit to 24-bit and getting all zeroes for
the last 8 bits, then you're not going to have ANY accumulated
rounding error, which means that the dithering is going to do
nothing at all to your signal.

All this is sort of a long way of saying that it depends on the
algorithm. If there are algorithms that use accumulated error,
then an unprocessed sample converted from 16- to 24-bit will
not change at all when dithered back to 16-bit. And even
for those that add noise, there is no point in adding (much?)
more noise than can be represented by the least significant bit.
Therefore, even in the worst case, you should expect to raise
the noise floor by only about 3dB, which is most likely not
a huge problem.

- Logan

Logan Shaw wrote:
DaveDrummer wrote:

If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade? IE, accidently running dither again over the now
16-bit file. Also, what about dithering 24-bit to 16-bit if the original
recording is 16 bit. Ive done this by mistake a few times. Does it do much
to the signal?


I am not an audio processing guru, but I do know a little about image
processing (and I stress that it's a little), which also uses dithering
for similar purposes.

Anyway, it seem like it would depend on the particular dithering
algorithm used. Some dithering works by adding a certain amount of
noise to the signal before rounding down to the smaller precision.
This type of dithering could produce additional noise if the amount
of noise it adds is large enough.

Basically, when converting from 24-bit to 16-bit samples, you have
three bytes:

aaaaaaaabbbbbbbbcccccccc

and you are getting rid of the all the bits labelled "c". In your
case, if you converted directly from 16-bit to 24-bit, all your "c"
bits would be zero. For example, if you convert this 16-bit quantity:

0011010101010111

into 24-bit bit, you will get this:

001101010101011100000000

Random dithering would add random noise to the lower 8 bits and then
round to the nearest 16-bit value when converting. But how much
noise does it add? If the binary values it adds vary between
+127 and -127, then it will never round to anything different than
it rounded to when those bits were all zero. Only if you add numbers
starting at +128 or larger (or starting at -128 or smaller) can it
ever affect the value that you round to. In other words, when your
last 8 bits are all exactly 0, then you are exactly in the middle,
really far away from the points where you would switch to rounding
to a different number; therefore, you have to add relatively large
numbers in order to round to a different number.

That covers dithering that works by adding random noise, but there
are other forms of dithering, such as those that choose a current
value based on accumulated rounding error for the previous values.
In other words, if you were working in decimal numbers, they'd
convert 11.3 to 11.0 but remember that they were 0.3 off. Then
on the next sample, if you see 10.4, you might convert that to
11 as well, since you know that this means your total error
will be minimized. I'm not 100% sure they use this type of
algorithm for audio stuff (seems like it could introduce
high-frequency junk in some cases). But anyway, the point is
that with something rounds based on accumulated error, if you
are converting 16-bit to 24-bit and getting all zeroes for
the last 8 bits, then you're not going to have ANY accumulated
rounding error, which means that the dithering is going to do
nothing at all to your signal.

All this is sort of a long way of saying that it depends on the
algorithm. If there are algorithms that use accumulated error,
then an unprocessed sample converted from 16- to 24-bit will
not change at all when dithered back to 16-bit. And even
for those that add noise, there is no point in adding (much?)
more noise than can be represented by the least significant bit.
Therefore, even in the worst case, you should expect to raise
the noise floor by only about 3dB, which is most likely not
a huge problem.

- Logan

Thanks Logan, that is a very nice way of explaining the addition of dither.

I can add that in audio we also use several forms of dither. Some of
them are based on the amplitude distribution of the random noise dither
signal.
The form that has a rectangular probability density function (PDF) adds
at most 1/2 LSB so that it basically does not alter the 16 bit
representation after the rounding off.
The widely used dither with a triangular PDF has a peak of plus and
minus 1 LSB so that would definitely lead to different values after
another rounding to 16 bit. That would certenly raise the noise floor.
But only slightly as you mentioned already.
An important reason why dither is added to the signal in the first place
is that it changes the rounding so that the error sounds better.

Doing an extra pass of dithering may have raised the noisefloor indeed.
But only with a benignly sounding noise of a very low level.

My regards

Bert Kraaijpoel

DaveDrummer wrote:

If you dither a file down, such as 24-bit to 16-bit, and then do it
again, would anything degrade?

Just barely measurably, and certainly not audibly.

IE, accidentally running dither again over the now 16-bit file.

If the file started out noise free, then there would be some minor
degradation. However, the noise from other sources that is present in the
file washes out the increase.

In the real world, audio files have dynamic range of no more than 80 dB due
to all the other sources of noise including the room itself.

The noise added by dither is about 93 dB down. The sum of -80 dB noise
and -93 dB noise (uncorrelated noises) is -79.8 dB. The 0.2 dB difference
would be inaudible if both noises were at full volume, but they are about 80
dB down and further masked by the far louder music. The audible difference
between -79.8 dB noise and -80 dB noise listened to along with music
averaging say -12 dB or -6 dB is non-existent.

Also, what about dithering 24-bit to 16-bit if the original recording is
16 bit. I've done this by mistake a few
times. Does it do much to the signal?

Same basic considerations apply. The effect is truly negligible.

In article writes:

If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade?

You'll add more noise to the audio, which is exactly what (and all)
dithering does. Do it once and it's not really audible unless you
really try to listen for it. Do it a few times and it can become
audible.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

DaveDrummer wrote:
If you dither a file down, such as 24-bit to 16-bit, and then do it
again, would anything degrade? IE, accidently running dither again over
the now 16-bit file. Also, what about dithering 24-bit to 16-bit if the
original recording is 16 bit. Ive done this by mistake a few times. Does
it do much to the signal?

Adding to what others have already said, you should be aware of the
theoretical 'need' to dither anything that has real time processing going
on in your software. For instance, when working on a 16 bit file in
software that uses a higher internal bit resolution to process audio (this
means practically all software), you'll be reducing bits again when saving
to a 16 bit file again. In Wavelab, which works with an internal bit
resolution of 32 bit (float) the process would look like this: 16 bit file
- processing (reverb, compression) = 32 bit file - bit reduction to 16
bit file - dither (not automatic in Wavelab) - save.

Luck, Arjan

--
----Real email: news then at then soundbyte then dot then nl----

"Jay-AtlDigi" wrote in message ...
Thanks.
--
Jay Frigoletto
Mastersuite
Los Angeles
promastering.com


It's working fine. ;-)

If I am working on a 16bit file with 24 and 32 bit processing (very little),
am I damaging anything by NOT using any sort of dither?

Thanks,

--
David Morgan (MAMS)
http://www.m-a-m-s.com
http://www.artisan-recordingstudio.com

"Mike Rivers" wrote in message
news:znr1083805525k@trad...
You'll add more noise to the audio, which is exactly what (and all)
dithering does. Do it once and it's not really audible unless you
really try to listen for it. Do it a few times and it can become
audible.

But not nearly as audible as the distortion that's created if you don't
dither your word-length reductions!

I found the following site *very* useful in understanding the need to
dither:

http://www.mtsu.edu/~dsmitche/rim420...20_Dither.html

Hope that helps.
Bill Ruys.

"DaveDrummer" wrote in message
...
If you dither a file down, such as 24-bit to 16-bit, and then do it again,
would anything degrade? IE, accidently running dither again over the now
16-bit file. Also, what about dithering 24-bit to 16-bit if the original
recording is 16 bit. Ive done this by mistake a few times. Does it do much
to the signal?

Dave

Bob Olhsson wrote:

"Mike Rivers" wrote in message
news:znr1083805525k@trad...

You'll add more noise to the audio, which is exactly what (and all)
dithering does. Do it once and it's not really audible unless you
really try to listen for it. Do it a few times and it can become
audible.


But not nearly as audible as the distortion that's created if you don't
dither your word-length reductions!

So, if you're using 32-bit floating-point math, how is this dither
accomplished at every addition operation?

I don't think it's part of any FPU's instruction set; ie, there's no
"Add but dither any reduced-precision arguments first" (FADDBDARPAF?)
instruction.

On Fri, 07 May 2004 07:58:00 -0700, S O'Neill
wrote:

Bob Olhsson wrote:

"Mike Rivers" wrote in message
news:znr1083805525k@trad...

You'll add more noise to the audio, which is exactly what (and all)
dithering does. Do it once and it's not really audible unless you
really try to listen for it. Do it a few times and it can become
audible.


But not nearly as audible as the distortion that's created if you don't
dither your word-length reductions!

So, if you're using 32-bit floating-point math, how is this dither
accomplished at every addition operation?

I don't think it's part of any FPU's instruction set; ie, there's no
"Add but dither any reduced-precision arguments first" (FADDBDARPAF?)
instruction.

That's what makes stored-program computers so neat, it may not have
the one instruction you need, but you can combine a few (or a lot of)
instructions to do the operation you want.

What's a "reduced-precision argument"? If you mean you're adding a
16-bit integer track to a 32-bit floating-point track, it should
convert each 16-bit int to a 32-bit floating point and then add,
resulting in a 32-bit floating point number. It's when you go the
other way, from 24 or 32 bits to 16 bits that dither is used (a small
random number [this is noise in the analog domain] is added to each
sample, then it's truncated (the LSB's are dropped off) to 16 bits).

Here are the usual links I give that explain dither. The first is
more technical, but the figures may help give an intuitive feel for
what dither does and how it helps. This involves analog-to-digital
conversion, but that is effectively the same thing as going from a
high bit depth to a lower bit depth, and the noise here gets added in
the analog domain:

http://www.national.com/an/AN/AN-804.pdf

Here's a long but slightly less technical explanation. Click on
articles, then dither:

http://digido.com

-----
http://mindspring.com/~benbradley

Ben Bradley wrote:

On Fri, 07 May 2004 07:58:00 -0700, S O'Neill
wrote:
So, if you're using 32-bit floating-point math, how is this dither
accomplished at every addition operation?

I don't think it's part of any FPU's instruction set; ie, there's no
"Add but dither any reduced-precision arguments first" (FADDBDARPAF?)
instruction.

What's a "reduced-precision argument"?

When the FPU goes to add two floats (in a mixer function, for example) the
exponents must be equal. This involves shifting the mantissas by the difference
in the exponents: the mantissa of the sample with the smaller exponent must be
shifted right, losing bits as a result. Dither should be applied in preparation
for this. Even if the FPU does its work in double-precision or more the result
would still have to have dither applied before converting back to
single-precision (ie, 32-bit). I don't know of an FPU instruction that's
specialized in this area, do you?

In article ,
S O'Neill wrote:
When the FPU goes to add two floats (in a mixer function, for example) the
exponents must be equal. This involves shifting the mantissas by the difference
in the exponents: the mantissa of the sample with the smaller exponent must be
shifted right, losing bits as a result. Dither should be applied in preparation
for this. Even if the FPU does its work in double-precision or more the result
would still have to have dither applied before converting back to
single-precision (ie, 32-bit). I don't know of an FPU instruction that's
specialized in this area, do you?

This is an inherent problem with floating point math - there really is
no way to dither it when doing float - float calculations. The
assumption is that float is so high res. that it's not important, and
it seems to hold in the real world.

For some algorithms, this problem can be avoided by calculating and
adding up all the small stuff and then adding the larger terms. This
can work if you know which terms are going to be small before they're
calculated, since it minimizes the instances when two quantities that
have grossly different magnitudes are directly added together. I
honestly don't know how prevalent that is though...

Most folks don't seem to worry about this, and those that do use wide
fixed point math. Both can sound good in practice.


Regards,

Monte McGuire

The idea behind using FP for "in between" data is that the (effective)
resolution of 24 bits is so high, that no dithering is required. The amount
of noise required to make something at -150dB (which is inaudible to begin
with) audible is way too much...

The use of floats instead of integers is mainly to prevent overflow or
underflow.

If one is certain of the range (e.g. adding 4 16 bits channels: you'll need
add most 18 bits to hold the result) of the values, there is no need to use
floats. Using 32 -bit integers will be faster (and more accurate...) for
predictible operations like adding signals and volume changes.

When using convolution filters (e.g. bandpass), inbetween values tend to be
very small or very large compared to the final values, especially when
cascading several of these filters. In these cases, the use of floats
eliminates the need for range checking. The final step will usually consist
of normalizing and converting to integers, with dithering if the resolution
is to be 16 bit (or less).

ML