Just a quick question. Alot of mentions about using triangular. What about us S3 and S4 people with only rectangular. Should that be used or powr while mixing in 24 bit.

zumba

No worries mark4man!

My name is Chris Garrido hence cGar. And I'm Cuban so that makes me a Cuban cGar: ahh the irony is killing me!

I'm not sure if this is consequential or not, but dither is different from noise-shaping. POW-r is noiseshaping, and I believe the Waves one mentioned above is as well. I'm not thoroughly convinced that we want to go into noiseshaping right now?

For the person asking about rectangular dither, I don't think you really want to go this route, either, but if you add 1 bit's worth of rectangular dither twice consecutively you end up with the proper amount of triangular dither. Think of it like rolling dice. If you roll one you have "rectangular probability distribution" of getting any of the numbers 1-6. If you roll two you end up with "triangular probability distribution" of getting the numbers 2-12, centered on 7:

1/1
1/2 2/1
1/3 2/2 3/1
1/4 2/3 3/2 4/1
1/5 2/4 3/3 4/2 5/1
1/6 2/5 3/4 4/3 5/2 6/1
2/6 3/5 4/4 5/3 6/2
3/6 4/5 5/4 6/3
4/6 5/5 6/4
5/6 6/5
6/6

The crux is that if generate numbers of rectangular probability distribution twice you end up with triangular probability distribution. If you add an infinite number together you get "Gaussian probability distribution" - it looks like a bell curve.

So if you want triangular dither and you only have rectangular you can do it twice and get the job done - but there are still questions about whether it's the right bit depth and amplitude. Further, it's twice the work

Nika

Nika,

I just ordered your book. I was trying to understand triangular and gaussian dither a while back and came across your illustration of the triangular probabilities with the dice somewhere on the net. The light went on and a lot of things became clear. You're a good teacher.

Thanks much also for all the detailed and accurate information you've been presenting here.

I agree, I was a bit confused on the triangular and other dither types and your dice example made it pretty clear. Thanks for that. I had always had a misconception that triangular was kind of like the shape of the dither noise, like Triangular was similar to a triangular shaped wave form.

Now here's where I'm still a bit confused:

1. When I originally did some comparisons of bit reduction and adding dither, I'm assuming the steps of processing would be in this order. ADD Dither>Bit Reduction. Since a lot of dither plugins don't give the chain of processing, this is what I would have to assume is going on. Now when I did the comparison I used a plugin that I assumed is doing it in that order. Then I did a bit reduction, saved it to the HD in a fixed point .Wav file. Then I reopened that file and then applied dither. So the processing would be Bit reduction>Add dither. Well, what I expected might happen is that you would get the distortion side effects of bit reduction and then additionally get the dither noise just added to that. So, this is normally how I work, thus how I wanted to try it out to see what happens. Thus, usually I will render at 24 bit or 32 bit float, while I know the app is working at 32bit float. Then I will do all mastering processes and then as the last step add dither and render to 16 bit for CD assembly. Well, I guess where I'm confused is that adding the dither after the bit reduction, I saw virtually the same thing as applying dither and then doing the bit reduction. Why is that?

See reference spectral graphs and previous statement:

Then this graph shows where I applied dither during the bit reduction and then applied it in 2 different steps where it was applied after the bit reduction had already taken place and got the same result.
http://www.stashbox.org/uploads/1145926381/Seperate-Dither.jpg

So let me explain further what I did. I started off with a 16bit 100Hz sinewave, then I bit reduced to 8bit. In the Yellow SA track, the processing went Dither>Bit Reduce. In the purple SA trace I went bit reduce>Dither. Aside from a little bump in the 10Khz and above range, they are virtually identical.

2. Now previously you explained where adding dither at each process can add up to 3dB (RMS) of noise per dither being applied. Then you went into the details of why, which I fully understand. The part I'm confused about is that if it's 3dB RMS, then why did it take me 4 dither opperations to get an increase of 6dB RMS? So by my math that's 1.5 dB Rms per dither. The only thing I could figure out is that we're talking in Power where you need 4 times the power to get +6dB, but admitely this is still a bit fuzzy from your explaination.

I also wanted to point out where you said there is upto 3dB of noise added when dithering, but worse is that there is actually up to +6dB of distortion added by not dithering. Well from your exact explaination of why dither is only up to +3dB, this can actually hold true for the distortion. That is because, I'm thinking in my workflow where in the Mix process I would render to 24 bit .Wav. Then after this would be the mastering process, where EQ, Compression and other mastering processes will be added. Due to that the original Mix file will also no longer be "correlated", thus the distortion due to the bit reduction will also no longer be "correlated". So in a real world working scenario, I don't fully agree with your assertions that up to +6dB of distortion could be added due to not using dither. Also in this workflow, dither would be applied when going to the final 16 bit format. Thus, why I still stick to my guns and say "Dither once" and only once to avoid adding unneccessary noise floor additions. I understand this is all very highly subjective and debatable, but if you could shed some light on this then maybe I will consider changing my workflow.

Currently my workflow would go like this, and I don't think it's a bad workflow.
1. Record tracks at 24 bit.
2. App (Vegas/Acid) is using 32 bit float internal processing.
3. Render mix at 32 bit float, no dither applied.
4. Master Mix in Sound Forge working at 32 bit float again.
5. Apply dither and render at 16 fixed for CD destination.

Thus, I'm applying dither ONCE and only ONCE where I think it matters the most and trying to avoid bit reduction in the mixing process all together.

ORIGINAL: Rednroll

1. When I originally did some comparisons of bit reduction and adding dither, I'm assuming the steps of processing would be in this order. ADD Dither>Bit Reduction. Since a lot of dither plugins don't give the chain of processing, this is what I would have to assume is going on. Now when I did the comparison I used a plugin that I assumed is doing it in that order. Then I did a bit reduction, saved it to the HD in a fixed point .Wav file. Then I reopened that file and then applied dither. So the processing would be Bit reduction>Add dither. Well, what I expected might happen is that you would get the distortion side effects of bit reduction and then additionally get the dither noise just added to that. So, this is normally how I work, thus how I wanted to try it out to see what happens. Thus, usually I will render at 24 bit or 32 bit float, while I know the app is working at 32bit float. Then I will do all mastering processes and then as the last step add dither and render to 16 bit for CD assembly. Well, I guess where I'm confused is that adding the dither after the bit reduction, I saw virtually the same thing as applying dither and then doing the bit reduction. Why is that?

I don't know why you got those results. Clearly something in there is broken. If dither is added properly you won't see all of those little spikes. You'll see a smooth, upward sloping line from, say, 200Hz to 20kHz in the graph you provided. It is clear that truncation is happening to your file somewhere along the way before the dither you're adding, so the dither is essentially negated. You are correct in that the only effective way to do this is add dither -> truncate. The fact that your data showed these results indicates to me (assuming you didn't make a mistake in your testing) something is truncating the data before you think it is without you knowing. It could be the fact that it's floating point, or it could be that the sine wave generator actually truncates its results as it calculates them.

2. Now previously you explained where adding dither at each process can add up to 3dB (RMS) of noise per dither being applied. Then you went into the details of why, which I fully understand. The part I'm confused about is that if it's 3dB RMS, then why did it take me 4 dither opperations to get an increase of 6dB RMS?

You guessed right below. The RMS measurement is really a measure of the power. By doubling the power you increase the signal by 3dB. To increase the signal by 6dB you have to quadruple the power. This is basic audio engineering at work - double the signal it increases by 6dB, double the power it increases by 3dB, double the signal is equivalent to quadrupling the power.

So by my math that's 1.5 dB Rms per dither. The only thing I could figure out is that we're talking in Power where you need 4 times the power to get +6dB, but admitely this is still a bit fuzzy from your explaination.

You scare me when you say 1.5dB RMS per dither. You are correct in the second half of your statement, though. Think of the first dither as default. Dither HAS to be in the signal - it is an implied characteristic of digital audio - the 6dB/bit number ONLY works when dither is an implied part of the formula. So the "first dither" is not 1.5dB RMS. The "first dither" is implied. But if you double it (lets say you add an extra dither plugin for no particular reason at this point) then it increases the noise floor by 3dB RMS. If you do this two more times it increases it by 3dB again. If you do it 4 more times it increases it by 3dB again. If you do it 8 more times it increases it 3dB again...

I also wanted to point out where you said there is upto 3dB of noise added when dithering, but worse is that there is actually up to +6dB of distortion added by not dithering.

To be clear I said that there "IS" 3dB of noise added when dithering. Not "up to." But yes, distortion makes it somewhere between 3dB and 6dB.

Well from your exact explaination of why dither is only up to +3dB, this can actually hold true for the distortion. That is because, I'm thinking in my workflow where in the Mix process I would render to 24 bit .Wav. Then after this would be the mastering process, where EQ, Compression and other mastering processes will be added. Due to that the original Mix file will also no longer be "correlated", thus the distortion due to the bit reduction will also no longer be "correlated".

No, those absolutely ARE correlated. The quantization distortion added during the last stage is absolutely still related to the original signal (more distantly) and is also still related to the quantization distortion added at other steps. They are all correlated. Nothing has gotten in the way to un-correlate them. The quantization distortion after the last process is still related to the amplitude of the signal that enters the process - the further that signal is from the quantization steps after the process at sample time the greater the error, the closer it is the less the error. The waveform that comes out of the process is still related to the waveform that went into the process, though, and that waveform is still related to the waveform that entered the process before it, etc.

Take an example: Let's start with a sine wave at 1/4 the sample frequency. And let's say that we sample half way between the peaks and valleys. The sample values continue on forever as ... 1, 1, -1, -1, 1, 1, -1, -1, etc. Let's do some sort of mathematical process to that waveform - say, taking each value and adding half of the previous value to it. So now we have ... .5, 1.5, -.5, -1.5, .5, 1.5, etc. (pretend this is taken mid-stream so we're not dealing with any funkiness resulting from the first values). Now truncate. What you get rid of from each sample is not in any way random. It is related to the signal that went in. You change that initial waveform and what you end up truncating off changes predictably with that waveform.

So now we have a new signal (the result of our calculation above and then truncated): 0, 1, 0, -1, 0, 1, 0, -1, 0, etc. Now let's do a new process - say, taking each sample, doubling it and adding to it half of the previous sample and 1/4 of the sample before that. Our result is:

... -.5, 1.75, .5, -1.75, -.5, 1.75 etc. (again, pretend we're taking this mid-stream).

Now truncate. Once again, you'll find that the information you truncate off has a pattern to it, and that pattern is directly related to the waveform that went into the system. If you change the initial waveform the pattern of the signal you truncate off changes with it. This means that the error signal - the signal that is being truncated off - is correlated to the initial waveform, even several processes out.

OK, sure, we're dealing with a pathological case of this sine wave sampled conveniently like this. Try a different waveform. Let's take this sine wave: 0, sin(pi/5), sin(2pi/5), sin(3pi/5), etc. Throw that in an excel spreadsheet and do some math to each value and once again, patterns will emerge in the decimal places that need to get truncated off. Those patterns are correlated to the sine wave you put in and therefore yield distortion when truncated away. Even multiple processes out, after multiple truncations, your results are still related to the initial waveform, though it may get more difficult to "see" that on the screen merely looking at numbers.

The same is true if you start talking about very sophisticated waveforms - the results, even several processes out, are still correlated to what went in. The correlation may be hard to spot numerically but it is easy to identify in other ways - namely in the presence of distortion. That distortion is the byproduct of truncating off mathematically determinable data. And it is mathematically determinable specifically because it is correlated to the waveform. Change the waveform and what you truncate off multiple processes later is predictable, identifiable, and therefore is correlated.

So, how do we DEcorrelate the truncation error from the waveform? How do we make it so that when we change the waveform the bits that get truncated off the end don't change determinably and predictably? Here's how: We add some random numbers in before we truncate. Pick a random number between -.5 and .5. Add that to the processed value before truncation. Do it one more time (doing it twice makes it triangular, remember, so you've just added triangular dither that stretches from -1 to 1 - an amplitude of 2 bits) OK, NOW truncate. What you have truncated off now bears no resemblance to the waveform that went into the system. Instead it bears relation to the random numbers you added on first. Run this out for a hundred numbers or so and you'll see a pattern in your resultant data that still smells of that sine wave but with some random error on it. But try to find any pattern in the numbers you truncated off the other end and you won't find it! They are completely decorrelated from the signal itself.

Do another process and dither again. Once again, you'll still see the patterns in the numbers that remain, but what gets truncated off is again completely decorrelated from the original signal. Do it again and again and the same is true.

True, the results that remain have some randomness in them - that is because dither was added to them. Dither is noise and noise is random. In this example that noise seems very high in amplitude to the original waveform's amplitude because we're only dealing with a 1 bit system.

So in a real world working scenario, I don't fully agree with your assertions that up to +6dB of distortion could be added due to not using dither.

But it is true. I hope you can see how, now.

Also in this workflow, dither would be applied when going to the final 16 bit format.

That's irrelevant. All of the quantization distortion you've added in until that last stage is still there and can still come through even after dithering to 16 bits. I can very easily demonstrate this.

Thus, why I still stick to my guns and say "Dither once" and only once to avoid adding unneccessary noise floor additions.

This is not good policy. I hope you can see why.

For the record, your assertion is understandable, because the industry has promoted this idea for several years. What they really mean is that, as end users, we should only be applying dither at the final stage - but only because dither should be automatically added at every other stage! Dither should always be automatically added. The only reason the don't do it automatically at the final stage is because there are reasons why, at that stage, the user should have some control over it - it shouldn't simply be TPDF dither at that stage. It can be more flexible than that - the user has choices, any number of which can be "correct" at that stage. Therefore, systems have been, and should be designed so that the user only has to worry about dither once - because the rest of the time it happens automatically where and how it should - and that one place is at the end. Therefore, the tip we tell the engineers is exactly as you've been saying, "only add dither at the very end," but this is because it is already added after every other processing stage by default. The problem is that systems are getting complex nowadays that users have more control than they should and these old tips have to go by the wayside as users figure out how to defeat the better intentions of software designers, and as software designers give the users more control.

Thus, I'm applying dither ONCE and only ONCE where I think it matters the most and trying to avoid bit reduction in the mixing process all together.

Yes, that seems fine to me - but recognizing that dither is actually happening far more frequently if the software is designed properly. Dither is happening after every process along the way - it's just that you have no control over that.

Again, end users should only be adding dither at the final stage because dither should already be added by default at all of the other stages. If it's not, however, then users have to start being smart and figuring out when and how it is appropriate to add dither.

I hope this helps?

Nika

Think of the first dither as default. Dither HAS to be in the signal - it is an implied characteristic of digital audio - the 6dB/bit number ONLY works when dither is an implied part of the formula. So the "first dither" is not 1.5dB RMS. The "first dither" is implied. But if you double it (lets say you add an extra dither plugin for no particular reason at this point) then it increases the noise floor by 3dB RMS. If you do this two more times it increases it by 3dB again. If you do it 4 more times it increases it by 3dB again. If you do it 8 more times it increases it 3dB again...

Alls you had to say is that it adds logarithmically and not linearly.
Thanks I understand what you're saying now, I forgot to think in typical log/decibel fashion.

There's lots of great info you put in that post. I will probably need to chew on some of it for awhile, but everything is pretty much making sense as to what you explained.

I hope this helps?

Yes very much so, Thank you for taking the time to break it down. You explain things very well.

cheers,
Red

ORIGINAL: MArwood

Another would be Waves Type 2 Ultra. Very high frequencies used at low levels.
Max Arwood

I have read somewhere that Waves type 2 dither is an incomplete dither that should only be used when converting to 8 bits or less. I could be wrong about this. Does anyone know for sure?

UnderTow

I have read somewhere that Waves type 2 dither is an incomplete dither that should only be used when converting to 8 bits or less

I have never heard of this before.
Max Arwood

ORIGINAL: attalus

does anyone know how do we set sonar's triangular dither to 2 lsb's? can lsb's be set in sonar for the dither?

No but I am assuming it does the right thing. This option would only allow for the user to make the dither work suboptimaly or not at all.

UnderTow

Not inherently. I would assume that if they are giving you a TPDF option that they are doing it properly, and making it two bits' worth? It is certainly possible to generate TPDF dither at 1 bit, 3 bits, fewer or more bits.

Nika

Thanks Nika and everyone.

Damn, you guys are smart.

zumba

ORIGINAL: mark4man

Damn, you guys are smart.

That's for sure.

But can someone please tell me if these absolutes are also true if the source files are 16-Bit?

If I'm working in a 16-Bit SONAR5 mix...the source files are are still processed at 32 (or 64, if that option is checked), right?

Correct. The mix engine is running at 32 or 64 bit float reguardless of the bit depth of the files.

So, any bounce, to a bit format less than that of the DAW's internal precision, is a reduction of word length...regardless of the bit format of the source files?

Again correct. :)

i.e., if I mixdown a 16-Bit project to a 24-Bit wav...is dither still required, because those 16-Bit source files were processed within the DAW @ 32 or 64?

mark4man

Indeed. You understand the most relevant point in this whole discussion.

UnderTow

ORIGINAL: bthompson

ORIGINAL: attalus
does anyone know how do we set sonar's triangular dither to 2 lsb's? can lsb's be set in sonar for the dither?

Sonar's triangular dither is preset to 2 LSB, right where you want it. I measured it and its amplitude is exactly right. With this dither you get no correlated distortion and no noise modulation.

--Bill

Ahh, Thanks!

ORIGINAL: mark4man

Update...

Wait a minute...the Help files within the program (v5.2) go on to add this:

or when you "render" audio (bounce, freeze, or apply effects).

So dither will be enabled for any mixdown (when checked.)

Whew !!!

Indeed. :)

So then...regarding running in real-time...

[Let me do a quick search of the forum, here...'cause in remembering Ron K's patch post, it seemed like it would be running full time when enabled, but that's in contradiction to the book.]

That is what Ron Kuper stated in the other thread about CPU utilization in 5.2.

Ron said that 5.2 does dither when bit reducing to 24 bit when going to the soundcard. In other words, Sonar 5.2 properly dithers at every point where the signal gets bit reduced to integer formats (Export, render, freeze, bounce, out to audio drivers).

UnderTow

What a wonderful mess this thread is!

In a good way. Get my drift?

Whatta mess.

I laugh my butt off. Whatta freaking mess this is!

Kudos to eveyone who have chimed in with good information.