The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Good dither practices, what are yours? Dynamics Plugins
Old 19th December 2018
  #541
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by i_magi_nation View Post
@chrisj And once again thank you - it was very important information! It means, that although the Airwindows plugins take the audio to higher bit depth, I don't need to think of dithering, after using your plugin, because it's already noise shaped.
No, nope, not how dither works. I'll try to sum up.

If you're doing stuff that alters the sound, it will increase word length. That also applies to plugins that avoid denormal numbers by adding sound to stop the signal being 'almost zero': it increases word length, and typically if you took a 24 bit file, did it, and then resaved directly at 24 bit without dither, you'd revert to exactly the same file again. Totally separate issue from noise shaping to the floating point buss, which is only Airwindows and those using the open source code.

In normal context noise shaping only refers to fixed point wordlength reduction. It's about saving the excess information lost to quantization (whether or not you actually dither!) and re-incorporating it somehow. That's the same thing I'm doing in floating point.

Regardless, if you end up at a word length and you're going to convert to a lower word length, you still need to dither. I'm just imagining you going 'since the Airwindows thing says it already noise shaped, I can just burn this to a CD and it's already had the THING done that you do'. It doesn't work that way.

Dither (correctly defined) is applying calibrated noise to completely stop quantization noise from being related to the audio. Dither is also a shorthand way to mean 'anything as the final stage with the purpose of converting to a shorter word length', but that's informal.

Noise shaping is a thing you can do ANY TIME the word length gets smaller, and it doesn't carry forward: you don't 'shape the noise to fit into lower word lengths', it's what you do AFTER you wedge audio into a smaller word length and have 'noise' left over. You can do it to a dithered signal which has only noise to distinguish it from the original long word length audio, or you can do it to a signal that got truncated (and your 'noise' will be nastier and less random). It's never 'preparing the sound to go into the lower word length', only 'what you do with the differentness from correct, long word length audio'.

That said, if you only meant 'I don't have to use a plugin and then dither all over the floating point buss' you're right, you don't. When you're going to a short word length, you still have to dither or at least do something, and noise shaping you did before NEVER helps. It only applies to each stage where you're making the word length smaller, and isn't even a thing you automatically want to do: noise shaping can give you better transparency at certain frequencies but sound fake. It's a complicated subject.

Also, if you only meant 'going back and forth between 32 bit float and 64 bit float' you likewise don't need to do anything like dither until you go to some fixed point format for output (or not at all, if you're outputting 32 bit float files). People do not normally do the slightest thing to cope with going from 64 or 80 etc. float to 32 bit float, partly because they get confused and think there's no quantizing happening because you can represent tiny tiny numbers in it, therefore any place anywhere in the audio must be able to scale down to tiny tiny degrees of difference. This is of course not at all true, but it's still not something you dither over
Old 22nd December 2018
  #542
Gear Head
 

Thank you for all the input, I have learnt a lot in this thread.

I have a question relating to dither when monitoring through an 24bit interface/DAC that uses digital volume control (usually in 32bit floating points).

1. If i dither to 24bit in the master bus to the monitor out inside a DAW, does it get converted to 32bit floating point by the interface, then get dither again inside the interface?
2. so maybe if one is using an interface/dac that employs digital volume control, one should not dither for monitor out?

I bet one using an interface/dac with digital volume control should still dither the master bus/monitor out since the end product we want to monitor are still fixed point audio.

Last edited by legolee; 22nd December 2018 at 10:19 PM.. Reason: clarifying
Old 22nd December 2018
  #543
Lives for gear
 

Quote:
Originally Posted by legolee View Post
I have a question relating to dither when monitoring through an 24bit interface/DAC that uses digital volume control (usually in 32bit floating points).
Can you state a specific audio interface/volume control that does this or is the one you are referring to?
Old 22nd December 2018
  #544
Gear Head
 

Quote:
Originally Posted by pentagon View Post
Can you state a specific audio interface/volume control that does this or is the one you are referring to?
At least some interface/DAC that uses ESS sabre DA chip should be using 32bit digital volume control. Some that I can think of are UAD Apollo X series, Benchmark DAC2 & DAC3.

Both the ESS presentation and Benchmark dac manual mentioned 32bit digital volume control with dither, but I cannot confirm they are floating point.

Last edited by legolee; 22nd December 2018 at 11:59 PM.. Reason: correction
Old 23rd December 2018
  #545
It comes down to how the audio is getting to the controller. If it is over an AES/EBU link from your interface, then that is a 24 bit fixed-point transfer so you should enable dither in your DAW's monitoring path. OTOH, if the interface and the monitor controller are one and the same, then what you should do depends on your audio drivers. Some audio interfaces do provide a 32-bit driver mode, but it's not usually the default. Check the your driver options to see if you can turn it on.
Old 23rd December 2018
  #546
Lives for gear
 

Quote:
Originally Posted by legolee View Post
Both the ESS presentation and Benchmark dac manual mentioned 32bit digital volume control with dither, but I cannot confirm they are floating point.
Floating point or fixed point, after a digital volume change, it would require dithering. Which would have to be implemented by the hardware system (since there's no insertion point for a user to implement such a thing)

My question for which hardware more had to do with 24 bit fixed point volume control is more than enough resolution for anyone. Really no advantage to go to 32 bit (float or fixed) for volume. Adjusting gain for digital audio is pretty straight forward. (as long as there is no other processing being requested like applying eq/filters to the output/input)
Old 23rd December 2018
  #547
Gear Head
 

Quote:
Originally Posted by pentagon View Post
Floating point or fixed point, after a digital volume change, it would require dithering. Which would have to be implemented by the hardware system (since there's no insertion point for a user to implement such a thing)

My question for which hardware more had to do with 24 bit fixed point volume control is more than enough resolution for anyone. Really no advantage to go to 32 bit (float or fixed) for volume. Adjusting gain for digital audio is pretty straight forward. (as long as there is no other processing being requested like applying eq/filters to the output/input)
http://www.esstech.com/files/3014/40...me-control.pdf

ESS seems to think otherwise.
It is interesting that the ESS chip is internally 32bit, but externally
16/24bit, and the digital volume control has access to the DAC internal data path, so as to reduce the noise floor.
Old 23rd December 2018
  #548
Gear Head
 

Quote:
Originally Posted by David Rick View Post
It comes down to how the audio is getting to the controller. If it is over an AES/EBU link from your interface, then that is a 24 bit fixed-point transfer so you should enable dither in your DAW's monitoring path. OTOH, if the interface and the monitor controller are one and the same, then what you should do depends on your audio drivers. Some audio interfaces do provide a 32-bit driver mode, but it's not usually the default. Check the your driver options to see if you can turn it on.
1. Agreed, dither when the digital volume control is behind an AES/EBU Link that can only carry 24bit fixed point data.

2. I am using the Apollo x6 via thunderbolt3 acting as both the monitor out and monitor controller. The WDM driver is 32bit, not sure about the ASIO driver. The ESS DA chip used is 32bit externally and 16/24 bit internally.
Old 23rd December 2018
  #549
Lives for gear
 

Quote:
Originally Posted by legolee View Post
http://www.esstech.com/files/3014/40...me-control.pdf

ESS seems to think otherwise.
It is interesting that the ESS chip is internally 32bit, but externally
16/24bit, and the digital volume control has access to the DAC internal data path, so as to reduce the noise floor.
Hilarious document comparison to 16 bit DAC. As I mentioned, 24 bit not 16. Also no mention of dithering despite mentioning noise floor and errors. Once again, 24 bit is more than enough for a volume control. As a single end output, errors aren’t being compounded and 24 bit with dither will resolve more detail than your monitoring system.
Old 23rd December 2018
  #550
Motown legend
 
Bob Olhsson's Avatar
 

I'm not sure if I'm repeating myself or not. It's important to understand that truncation distortion is louder than and accumulates faster than dither noise. We are almost never dealing directly with the audio signal that our customers' customers will be hearing. Our goal should be to try to minimize the downstream distortion by preventing truncation.
Old 25th December 2018
  #551
Lives for gear
 

Quote:
Originally Posted by chrisj View Post
Technically, to use CoreAudio (and plugins) it must revert to 32-bit float between each plugin.

Their use of 64-bit in mixing I heartily endorse, but it's no different than plugins doing their internal calculations on a double precision buss. We can pass around floats by way of routing audio, but Logic had no business doing all their mixing math just with floats: always should have been doubles, even when the audio streams are floats. I've been using doubles internal to plugins since 2007.

Heck, if there were good ways to dither to floats (32 bit), we'd never need anything more as floats are always less than half the quantization of 24 bit fixed point for any signal not clipping (and get better, as the volume drops: the quantization's directly tied to how loud the sample is). Since there isn't a good way to dither to floats, using 64 bit makes the quantization much smaller for any given level.

That's just arbitrary, by the way. You could have a 64 bit float with worse quantization than 16 bit fixed point if you set it up that way: you'd pretty much be using it to record numbers much closer to infinity or to zero, so the granularity in the range of audio samples could be worse. You could have a 32 bit float that was better optimized for audio by using a much smaller exponent, so you'd have say +40 dbFS headroom (rather than four million dB) and it'd give up on near-silent audio much quicker.

What we've got is what general purpose computing uses, so our 32 bit float is better than 24 bit in the audio range but with some limitations, and then it also offers headroom (and ability to do faint noises) way way beyond anything we practically need. 64 bit is the same general purpose thing, but it expands not only in 'ultimate limits' but also in terms of the granularity within the ranges we use.
Ok so I spent Christmas day reading through this whole thread as well as the related dither threads on GS absorbing as much as I could - my brain has just exploded !!

I have a few questions on subjects that were touched upon but not delved into in more depth that really piqued my interest.

@chrisj

1) So all DAWS running on the MAC OS will drop down to 32bit FP between plug-ins EVEN IF the DAW runs everything at 64bit FP (such as Reaper)?

2) Can you clarify in greater detail the statement you made about VST staying in double precision

"VST offers a 'doubleReplacing' mode where you can run a 64-bit buss. CoreAudio doesn't do that."

3) Does this mean that it's THEORETICALLY better to use VST's in a 64bit FP DAW as opposed to AU?
Old 26th December 2018
  #552
Gear Maniac
 

reaper will not change wordlength as long as you dont use any of its native plugins such as faders, panlawgain, reaplugs, etc. not even summing busses.
Old 26th December 2018
  #553
Lives for gear
 

Quote:
Originally Posted by 5.333V View Post
reaper will not change wordlength as long as you dont use any of its native plugins such as faders, panlawgain, reaplugs, etc. not even summing busses.
This I know and it seems to be the behaviour of all the DAWs if the audio is just "played" through with no gain changes or any sort of processing.

But I would like to know with more clarity about the Core Audio spec that Chris from Airwindows mentioned which forces the audio to 32bit float between plug-ins (IIUC).

Is this standard on all DAWS on the Mac running at 64bit float ?
Old 30th December 2018
  #554
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by siddhu View Post
This I know and it seems to be the behaviour of all the DAWs if the audio is just "played" through with no gain changes or any sort of processing.

But I would like to know with more clarity about the Core Audio spec that Chris from Airwindows mentioned which forces the audio to 32bit float between plug-ins (IIUC).

Is this standard on all DAWS on the Mac running at 64bit float ?
Audio Units do that. I've opensourced the code, you can see for yourself: the data coming in and going out are a 32 bit floating point format. VST CAN be also a 32 bit floating point format, but if the host defines it as double AND the VST plugin has 'double replacing' (or, I suppose, 'double adding?) then the VST will work as 64 bit.

In theory that could be better, so long as the plugins themselves are also running 64 bit word lengths for everything, which is hardly a given. Mine do, or 80 bit (long double) but then I also noise shape to the floating point buss at 32 bit, so I don't think my stuff suffers from being on CoreAudio buss.

Mostly I'd say: yes you're right, but don't worry about it. Anything you could possibly do, no matter what it was, would have a bigger effect. I suppose if you always use dozens of plugins on everything, you'll begin losing a bit of quality, but then you're already using dozens of plugins so you'll have already overprocessed and lost so much of the original sound that you'd never notice a difference.

Also remember this is all different from 64 bit memory addressing. That's a completely separate issue.
Old 30th December 2018
  #555
Lives for gear
 

Quote:
Originally Posted by chrisj View Post
Audio Units do that. I've opensourced the code, you can see for yourself: the data coming in and going out are a 32 bit floating point format. VST CAN be also a 32 bit floating point format, but if the host defines it as double AND the VST plugin has 'double replacing' (or, I suppose, 'double adding?) then the VST will work as 64 bit.

In theory that could be better, so long as the plugins themselves are also running 64 bit word lengths for everything, which is hardly a given. Mine do, or 80 bit (long double) but then I also noise shape to the floating point buss at 32 bit, so I don't think my stuff suffers from being on CoreAudio buss.
.....
Thanks for clarifying that Chris. So if I'm understanding correctly, even if the DAW runs at 64bit FP, and the plugins are also all running at 64bit FP, the "pure" 64bit floating point chain is "broken" between plugins because CoreAudio needs the to receive the audio at 32bit FP?

I'm not to worried about it in the sense of my audio is getting ruined, but it's interesting to me on an academic level to understand how things work under the hood.

I do almost all my processing with outboard on the way in and then use very few plugins during the mixing process. Normally just some corrective EQ and any FX plugins that are used for sound design.

Happy Holidays
Old 8th January 2019
  #556
Triangular always if further nonlinear processing is going to happen to a 24bit file (ie mastering), or no dither and render at 32 bit floating point.

AirWindows NotJustAnotherDither for 24 bit final mastered track, and NotJustAnother for 16 bit CD quality (gets 24 but quality loudness on to CD). No exceptions, unless some other character is wanted, then a different airwindows did.

It replaced ozone mbit+ and is (IMHO) about 100 times better, guesstimate and not exaggerating. And, it's free.
Old 8th January 2019
  #557
Quote:
Originally Posted by theMuzzl3 View Post
It replaced ozone mbit+ and is (IMHO) about 100 times better, guesstimate and not exaggerating. And, it's free.
AMEN to that. AirWindows' dithering plug-ins are AMAZING. There are so many of them though! I still have to go deeper into all of them to learn exactly what the differences are.
Old 8th January 2019
  #558
Quote:
Originally Posted by chrisj View Post
Dither (correctly defined) is applying calibrated noise to completely stop quantization noise from being related to the audio. Dither is also a shorthand way to mean 'anything as the final stage with the purpose of converting to a shorter word length', but that's informal.
So, from a theoretical point of view and to get this straight once and for all: is dithering a randomly-generated noise meant to MASK the partials that result from quantization noise, or is dithering a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to being with?

Quote:
Originally Posted by chrisj View Post
People do not normally do the slightest thing to cope with going from 64 or 80 etc. float to 32 bit float, partly because they get confused and think there's no quantizing happening because you can represent tiny tiny numbers in it, therefore any place anywhere in the audio must be able to scale down to tiny tiny degrees of difference. This is of course not at all true, but it's still not something you dither over
So, if got it right, to sum things up:

1. From a theoretical point of view: going from 80/64 bits FP to 32 bits FP DOES IMPLY truncation happening to the signal.

2. From a practical point of view for us mixing engineers: there's no need to do anything here and let it happen because (1) there does not exist a dithering plug-in for such application because it would be extremely CPU-heavy (2) the quantization noise generated from the truncation from 80/64 bits FP to 32 bits FP is extremely low and unnoticeable specially given a musical program which would already imply a much greater noise floor to begin with which, at the same time, would kind of serve as a self-dithering function to the quantization noise to begin with.

Thank you so very much @chrisj !!!
Old 8th January 2019
  #559
One more thing to say, and please excuse yet another post, is a big THANK YOU to every participating in this AMAZING thread here at GS specially to @chrisj and to @FabienTDR from whom we have learnt such a lot here.

I do think StillWell's Bitter plug-in needs a desperate update in terms of GUI so as to better measure 64 bits. What do you think? Is there another VST plug-in out there that will be more accurate and that I'm missing? Thank you!
Old 8th January 2019
  #560
Quote:
Originally Posted by chrisj View Post
Nope, I don't have a SRC. What I use is an old version of Audacity, with the 'Secret Rabbit Code' library, which is just sinc based interpolation. I don't use the highest quality version but the medium quality: for that particular library, it has ideal out of band rejection and differs in terms of how close to Nyquist it can get (more quality, steeper brickwall at Nyquist) and I liked the medium one.
After doing some research it seems that the 'Secret Rabbit Code' is a well-loved SRC algorithm among the forums BUT in order to use it you have to compile it yourself onto your own build of Audacity? Meaning that the code's available for free at the developer's website (Secret Rabbit Code (aka libsamplerate)) but no front-end software is provided. What a shame for us non-programmers!

@chrisj I was wodering what you thought about REAPER's built-in SRC-conversion algorithm (and it's many quality options). Thank you again!
Old 8th January 2019
  #561
Quote:
Originally Posted by morfi View Post
So, from a theoretical point of view and to get this straight once and for all: is dithering a randomly-generated noise meant to MASK the partials that result from quantization noise, or is dithering a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to being with?
It is the latter. But I would not call the residual errors "partials", since they are no longer correlated[*] with the signal. With correct dithering, the residual error is not distortion, but simply noise.

MASKING is not practical. If one allowed (non-dithered) truncation to occur, the resulting distortion spurs would be much too high to be masked by a typically-scaled dither noise.

David L. Rick
Seventh String Recording

[*] For audio purposes, we only care about correlation as judged by the first two statistical moments.
Old 8th January 2019
  #562
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by morfi View Post
So, from a theoretical point of view and to get this straight once and for all: is dithering a randomly-generated noise meant to MASK the partials that result from quantization noise, or is dithering a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to being with?

So, if got it right, to sum things up:

1. From a theoretical point of view: going from 80/64 bits FP to 32 bits FP DOES IMPLY truncation happening to the signal.

2. From a practical point of view for us mixing engineers: there's no need to do anything here and let it happen because (1) there does not exist a dithering plug-in for such application because it would be extremely CPU-heavy (2) the quantization noise generated from the truncation from 80/64 bits FP to 32 bits FP is extremely low and unnoticeable specially given a musical program which would already imply a much greater noise floor to begin with which, at the same time, would kind of serve as a self-dithering function to the quantization noise to begin with.

Thank you so very much @chrisj !!!
OK, point by point:

Dithering is a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to begin with. When we speak of dither in a mathematical sense we mean a form of TPDF: two random sources one bit in size, handled however. I have a bunch of different TPDFs, that sound different and are about equally noisy and all work as TPDF. They make it so the signal drops below the (raised) noise floor without interacting with it in any way. If you don't do TPDF or if you assume you can 'self-dither', it DOES interact and you can hear it.

Back in the day, I did a 'hear the difference between noise, and low-bit noise' ABX test, which I aced. It was plainly obvious which was which. An audio guru (I'd like to say Bruno Putzeys, but I'm not sure) said, TPDF dither this noise you've got. (in other words, add more noise to the noise, two sources each one bit in loudness according to the quantization level). As soon as I did this I absolutely couldn't hear a difference anymore. Self-dithering isn't a thing.

1: no, from a practical point of view you're absolutely truncating. Anytime you make a calculation that expands the wordlength and then put the result in a 32 bit (or indeed 64 bit) float you're truncating. You're almost ALWAYS truncating when you're doing math in the computer, unless it doesn't expand the word length. But,

2: there's no practical thing to do about it, especially if you're not the programmer. I've been doing 64 bit internal busses for many years, and 80 bit internal busses in some cases, and I noise shape to the 32 bit output buss when it's 32 bit. The TPDF dither for such a situation would not be that absurdly heavy, you'd just need to generate your TPDF and then scale it over 256 values depending on what the exponent was going to be.

On the other hand, though you could do this, it means you'd be painstakingly dithering to a '25 bit' area of the output word AT WORST, and almost all the time you'd be dithering to a flat-out ridiculously tiny number that's literally impossible to hear ever. I get that people haven't considered this to be a thing because people haven't grasped the realities of producing the floating point mantissa (effectively a 24 bit fixed point number that's part of how a floating point 32 bit number works). It's almost true that it would be a lot of processing to generate a dither and apply it, except that you don't have to make 256 noise values, just one (and store one for the TPDF) and then scale it on a sample-by-sample basis, making it not much different from regular dither.

And then, the only places where your dither would even approach a 24 bit level would be the very loudest outer parts of your output: 6 dB down and the level of the dither would be 26 bits, 6db below that and it's 27… in a world where people argue that you can't hear lossy compression and 16 bit dither is unnecessary, nobody is going to go to the trouble of making regulation TPDF dither to 32 bit floating point.

Oh, all right, I will, but if you go around saying you can hear the difference between that and 32 bit floating point truncation, everyone will make fun of you, even me

Also, the last time I used Audacity to convert from 96K to 44.1K, I must have had a newer version. It only gave low and high quality sinc interpolation. That's the same as Secret Rabbit Code, and I used the high quality and it was just fine (and sonically beat everything else I tried by a noticeable margin). So you probably don't need to compile anything, just use the 'sinc interpolation' in Audacity.
Old 8th January 2019
  #563
Gear Addict
 
Sniff's Avatar
 

Chrisj

aka Emmett Lathrop "Doc" Brown, Ph.D.

Thanks for making awesome plugs. Don't understand waht you're saying tho'
Old 9th January 2019
  #564
Quote:
Originally Posted by morfi View Post
So, from a theoretical point of view and to get this straight once and for all: is dithering a randomly-generated noise meant to MASK the partials that result from quantization noise, or is dithering a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to being with?



So, if got it right, to sum things up:

1. From a theoretical point of view: going from 80/64 bits FP to 32 bits FP DOES IMPLY truncation happening to the signal.

2. From a practical point of view for us mixing engineers: there's no need to do anything here and let it happen because (1) there does not exist a dithering plug-in for such application because it would be extremely CPU-heavy (2) the quantization noise generated from the truncation from 80/64 bits FP to 32 bits FP is extremely low and unnoticeable specially given a musical program which would already imply a much greater noise floor to begin with which, at the same time, would kind of serve as a self-dithering function to the quantization noise to begin with.

Thank you so very much @chrisj !!!
Wow. Thats crazy. I've gotta spend a good 200 hours studying just his dithers and what he talks about with them. Its really worth it.

I hear a lot of people say things like "we can't hear the difference," and then they assume "it doesn't matter if its processed in the 100% "best," or "most correct" ways that we are able to. Even if we are unable to hear a difference, there is a difference. These can add up, and I argue that they also have a psychological and physiological effect on us. Also, if we can do something in the best way, why not do it? Laziness is a big thing... but its usually bias of opinion, based on assumptions made from known facts or widely accepted theories.

Color one thing red and another green, on the GUI... and we'll thing the green one sounds better, even if tests show that evidence supports that we can't detect audible differences. My theory is that, we can stick anything inside of uLaw, and it is instantly better (haha, not joking... but don't blow your ear drums or speakers). Dithers might be neat... RawGlitters and RawDithers was spectacular.

I know more about the frequency depth issues... and I hear tons of people saying "oh we can't hear anything over 22 kHz." They don't realize that everything in the inaudible areas are vibrating and are energy... so they cause the audible frequencies to vibrate and behave in different ways. Remove information above 20 kHz, from a 96 kHz recording... and you've instantly removed what I call the "life" part of the audio out of it. I've even done boosts at 32 or 40 kHz on stuff that was 44.1 or 48 k... and boosting the bits, all though they're empty "zero" bits, effects the audible frequencies... and about 50% of the time, I feel a 0.2 to 1.0 boost is beneficial in a final master. It might take something away from the mids, but it also causes them to behave differently... even audible silence is energy, whether the stuff is vibrating or not... its there. 50% of the time, the damage to the mids isn't worth getting the highs and bass to behave like something thats more alive than usual digital processed/generated audio or low freq rate recordings/mixes.

22-27ish kHz causes our nose hairs to vibrate, as well... so we know it has some effect on us, we just aren't completely sure.

I could go on and on, but I'll stop since its off-topic.
Old 11th January 2019
  #565
Quote:
Originally Posted by David Rick View Post
It is the latter. But I would not call the residual errors "partials", since they are no longer correlated[*] with the signal. With correct dithering, the residual error is not distortion, but simply noise.

MASKING is not practical. If one allowed (non-dithered) truncation to occur, the resulting distortion spurs would be much too high to be masked by a typically-scaled dither noise.

David L. Rick
Seventh String Recording

[*] For audio purposes, we only care about correlation as judged by the first two statistical moments.
Dear David; thank you so very much for making that clear for me.

Indeed, what a dithered-truncated signal gets is residual noise and rather than 'non-musical/non-correlated' partials, as, per being dithered, it gets no partials from truncation distortion whatsoever. Thank you for clarifying that too.

Thank you!

Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 11th January 2019
  #566
Quote:
Originally Posted by chrisj View Post
OK, point by point:

Dithering is a calibrated noise that induces randomness to the LSB in the first place so that the partials that result from quantization noise are not musically RELATED to the signal to begin with. When we speak of dither in a mathematical sense we mean a form of TPDF: two random sources one bit in size, handled however. I have a bunch of different TPDFs, that sound different and are about equally noisy and all work as TPDF. They make it so the signal drops below the (raised) noise floor without interacting with it in any way. If you don't do TPDF or if you assume you can 'self-dither', it DOES interact and you can hear it.

Back in the day, I did a 'hear the difference between noise, and low-bit noise' ABX test, which I aced. It was plainly obvious which was which. An audio guru (I'd like to say Bruno Putzeys, but I'm not sure) said, TPDF dither this noise you've got. (in other words, add more noise to the noise, two sources each one bit in loudness according to the quantization level). As soon as I did this I absolutely couldn't hear a difference anymore. Self-dithering isn't a thing.

1: no, from a practical point of view you're absolutely truncating. Anytime you make a calculation that expands the wordlength and then put the result in a 32 bit (or indeed 64 bit) float you're truncating. You're almost ALWAYS truncating when you're doing math in the computer, unless it doesn't expand the word length. But,

2: there's no practical thing to do about it, especially if you're not the programmer. I've been doing 64 bit internal busses for many years, and 80 bit internal busses in some cases, and I noise shape to the 32 bit output buss when it's 32 bit. The TPDF dither for such a situation would not be that absurdly heavy, you'd just need to generate your TPDF and then scale it over 256 values depending on what the exponent was going to be.

On the other hand, though you could do this, it means you'd be painstakingly dithering to a '25 bit' area of the output word AT WORST, and almost all the time you'd be dithering to a flat-out ridiculously tiny number that's literally impossible to hear ever. I get that people haven't considered this to be a thing because people haven't grasped the realities of producing the floating point mantissa (effectively a 24 bit fixed point number that's part of how a floating point 32 bit number works). It's almost true that it would be a lot of processing to generate a dither and apply it, except that you don't have to make 256 noise values, just one (and store one for the TPDF) and then scale it on a sample-by-sample basis, making it not much different from regular dither.

And then, the only places where your dither would even approach a 24 bit level would be the very loudest outer parts of your output: 6 dB down and the level of the dither would be 26 bits, 6db below that and it's 27… in a world where people argue that you can't hear lossy compression and 16 bit dither is unnecessary, nobody is going to go to the trouble of making regulation TPDF dither to 32 bit floating point.

Oh, all right, I will, but if you go around saying you can hear the difference between that and 32 bit floating point truncation, everyone will make fun of you, even me
Dear Chris, thank you for such an explanation! There's more information in there that I, being not a software developer but a mixing and mastering engineer, needed to know! So thank you for that.

Quote:
Originally Posted by chrisj View Post
Also, the last time I used Audacity to convert from 96K to 44.1K, I must have had a newer version. It only gave low and high quality sinc interpolation. That's the same as Secret Rabbit Code, and I used the high quality and it was just fine (and sonically beat everything else I tried by a noticeable margin). So you probably don't need to compile anything, just use the 'sinc interpolation' in Audacity.
Thank you this little hint as well. I've just downloaded the latest 2.3.0 version to check your recommendation.

Not to take this thread of topic but I'm planning on doing a shootout between this Secret Rabbit Code algorithm in Audacity and my current applications that I use for Sample Rate Conversion: REAPER 5 and iZotope RX 7. Both have quite a few options in terms of quality for when downsampling; it's a bummer that RX won't open a 64 bit file (as it's not the "industry standard"...) though. Of course I could do a fair comparison among them with a 32 bit audio file (as what we're trying out here is the quality of SRC, not dithering) but if I think in real terms for my workflow REAPER would be much more convenient since I'm always mixing and mastering to 64 bit.

Thank you!

Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 11th January 2019
  #567
Lives for gear
 
DistortingJack's Avatar
 

Quote:
Originally Posted by morfi View Post
I'm always mixing and mastering to 64 bit.
Mixing I absolutely get, but mastering to 64 bit? The whole point of mastering is to end up with a finished file for mass consumption. A 64-bit file is not a good format for that. All computers can play 24-bit files natively, even smartphones. Almost no software can play 64-bit files.

32-bit is already "almost there" theoretically during mixing, where you're applying possibly up to a dozen different plug-ins to a single signal, through busses and master out. Almost as in "there might be an incredibly small degradation after 20 plug-ins, maybe".

64-bit is overkill, but easy to implement, so it was.

A single conversion between 64-bit and dithered 24-bit at the final stage of a mastering session is 100% inaudible no matter how you go about it.

Basically, you should mix at 64-bit for peace of mind, and your final master should be 24-bit at native sampling rate for archival, with an extra 16-bit, 44.1 kHz file for CD. The latter file's dither and sampling rate conversion is the only bit you should really think about in terms of specific algorithms.

If the mix was done at 88.2 or 96k I usually do another bounce at 24-bit, 48 kHz as a slightly better mass-market option, since that's the highest resolution that can safely be played on most consumer converters such as iOS devices.

If you're sending a file to be mastered by a pro, you'll likely be asked a 24-bit file. If they accept a 64-bit file, they will likely run it through processes, including D/A/D conversion, that convert to 24-bit anyway. There is no issue with this.
Old 11th January 2019
  #568
Quote:
Originally Posted by DistortingJack View Post
Mixing I absolutely get, but mastering to 64 bit? The whole point of mastering is to end up with a finished file for mass consumption. A 64-bit file is not a good format for that. All computers can play 24-bit files natively, even smartphones. Almost no software can play 64-bit files.

32-bit is already "almost there" theoretically during mixing, where you're applying possibly up to a dozen different plug-ins to a single signal, through busses and master out. Almost as in "there might be an incredibly small degradation after 20 plug-ins, maybe".

64-bit is overkill, but easy to implement, so it was.

A single conversion between 64-bit and dithered 24-bit at the final stage of a mastering session is 100% inaudible no matter how you go about it.

Basically, you should mix at 64-bit for peace of mind, and your final master should be 24-bit at native sampling rate for archival, with an extra 16-bit, 44.1 kHz file for CD. The latter file's dither and sampling rate conversion is the only bit you should really think about in terms of specific algorithms.

If the mix was done at 88.2 or 96k I usually do another bounce at 24-bit, 48 kHz as a slightly better mass-market option, since that's the highest resolution that can safely be played on most consumer converters such as iOS devices.

If you're sending a file to be mastered by a pro, you'll likely be asked a 24-bit file. If they accept a 64-bit file, they will likely run it through processes, including D/A/D conversion, that convert to 24-bit anyway. There is no issue with this.

Maybe I didn't say this the right way: of course I master to end-formats (i.e. 16 and 24 bits) but my mastering chain is thoroughly digital in a 64 bit floating point environment (REAPER) and with 64 bit-processing DSP (plug-ins by Tokyo Dawn Labs, AirWindows, Klanghelm and d16 Audio Group exclusively which, coincidentally or not, ALL process internally at 64 bits - or higher - give the project's setup).

So basically I'm keeping my audio at 64 bits floating point from coast to coast up until I need to bounce to disk, which is where you apply SRC and dither (in what order exactly...?!).

Now a few shortcomings of my current setup is that (1) if I need to SRC I can do that from the REAPER render dialog and apply dither afterwards, but only REAPER's excellent built-in dither but still not AirWindows' dither or any other VST for that matter, get what I mean? so (2) if I simply bounce to disk without applying SRC I want to bounce still at 64 bit for the further processing of SRC but then again I wouldn't be able to open such a file in iZotope RX if I preferred to use their algorithm for SRC.

Rendering a 64 bit master to a temporary 32 bit file for SRC outside the DAW seems pointless. And of course I could work in 32 bits all along and get rid of this problem but there's proof (even inside this very own thread) that 64 bits does sound/can sound/probably sounds/should sound/I hope will sound "better" than even 32 bit. =)
Old 11th January 2019
  #569
Lives for gear
 
DistortingJack's Avatar
 

Quote:
Originally Posted by morfi View Post
Maybe I didn't say this the right way: of course I master to end-formats (i.e. 16 and 24 bits) but my mastering chain is thoroughly digital in a 64 bit floating point environment (REAPER) and with 64 bit-processing DSP (plug-ins by Tokyo Dawn Labs, AirWindows, Klanghelm and d16 Audio Group exclusively which, coincidentally or not, ALL process internally at 64 bits - or higher - give the project's setup).

So basically I'm keeping my audio at 64 bits floating point from coast to coast up until I need to bounce to disk, which is where you apply SRC and dither (in what order exactly...?!).

Now a few shortcomings of my current setup is that (1) if I need to SRC I can do that from the REAPER render dialog and apply dither afterwards, but only REAPER's excellent built-in dither but still not AirWindows' dither or any other VST for that matter, get what I mean? so (2) if I simply bounce to disk without applying SRC I want to bounce still at 64 bit for the further processing of SRC but then again I wouldn't be able to open such a file in iZotope RX if I preferred to use their algorithm for SRC.

Rendering a 64 bit master to a temporary 32 bit file for SRC outside the DAW seems pointless. And of course I could work in 32 bits all along and get rid of this problem but there's proof (even inside this very own thread) that 64 bits does sound/can sound/probably sounds/should sound/I hope will sound "better" than even 32 bit. =)
You're doing it right, then. SRC will require dither like any other process, but that's normally done internally in the plug-in. Dither should be the last part of the chain.

You're overthinking. There is no audible degradation to be had for you to take your final master at high rates, convert them to 32-bit once, and do SRC and dither inside RX, especially in processing as subtle as mastering.
Old 11th January 2019
  #570
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by FabienTDR View Post
AFAIK, this only happens when exporting to a fixed point format or sending out audio to the convertors (always fixed point). It never happens inside the DAW, the latter being typically floating point (32bit fp or 64bit fp) and generously sized. Oh, and floating point can't be dithered anyway!
I think you may be wrong on some of this. (and please correct me if i am)

It depends on what the internal mixing of the DAW considers to be 0dBFS.
This concerns 32 bit floats.

So, as far as i know, many DAWs cosider the value of 1.0f to be 0dbBFS.
This means that the signal below 0dBFS is only coded by the mantissa of the 32 bit floating point, which is 24 bits.
Moreover, the math that appliers to this mantissa is basically integer math.

So, if you have a 24 bit source, summed to a 32 bit float that assumes 1.0f is odBFS, and you lower the amplitude you will be truncating.

And so, in this case you do need to dither after the gain change.

If it's a 64 bit fp bus then the whole 24 bit original can fit in the mantissa without any truncation and this problem doesn't occur (or at least it will lead to an error that is waaaay down the scale).

This begs the question tho, what exact floating point value is considered 0dBFS by the various DAWs on their mixing busses?
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump