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 23rd January 2019
  #631
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by Deckdaddy View Post
Is it better to work in a constant 32 bit environtment than back and forth between 64 bit engine and 32 bit calculations causing distortions?
Nope. Truncation is cumulative: the fewer times you do it, the better. One thing that'll help is 'do fewer 32 bit calculations' or 'don't overprocess in the box', but whatever your choices, if you can use a 64 bit engine as part of it, that will help whether or not the engine dithers to 32 bit float. Back and forth is just fine: without it, you're doing lots of tiny little 32 bit truncations for every little calculation. I don't recommend using floats as temporary audio variables inside plugins at ALL. Use doubles, at least.
Old 23rd January 2019
  #632
Motown legend
 
Bob Olhsson's Avatar
 

The buildup of truncation artifacts is the problem. Dither simply eliminates them. Too many tech pundits and even developers seem to think it's just noise that covers them up. Paul Frindle was also opposed to noise shaping so it's interesting to see Chris coming to the same conclusion in this case.
Old 23rd January 2019
  #633
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by Bob Olhsson View Post
The buildup of truncation artifacts is the problem. Dither simply eliminates them. Too many tech pundits and even developers seem to think it's just noise that covers them up. Paul Frindle was also opposed to noise shaping so it's interesting to see Chris coming to the same conclusion in this case.
Operative words 'in this case', I'm using noise shaping for the stuff in StudioTan, but that's strictly (a) output dither for 24 and 16 bit, and (b) entirely using quantization stages that are not dither at all. It's got three sounds and two of them are quantization used as EQ (determine which quantization direction will be brighter/duller and use that) and the third is the latest twist on the Benford Realness algorithm I've had for a while. All of those make good moderate use of noise shaping to get the sound I wanted. I didn't like plain or even highpassed TPDF as much as these 'effects' for a final output to 16 bit.

But to linearize quantization that happens at all volume levels at once? I tried very hard to come up with something noise-shapey that would work. Both the previous things I'd been doing were flawed, and the more recent one was a hot mess. I tried for hours to fix it, and in the end I simply gave up, like 'fine! If the dither in this situation is that much better than anything I try, we'll just use the dither'.

And so I did. I'm more than a bit burnt out from bringing in a cord of firewood and then getting a small blizzard and digging myself out of it, but I'm working on bringing out the FP dither and might be able to have it before next Sunday.

For 'bringing out', read 'I have the demo working on Mac AU and was so impressed by the improvement over everything else I've been doing ('noise shaping') since 2013, that I am updating EVERY plugin to dither instead of 'noise shape' to the floating point buss'. So there are many hundreds of plugins to update for free. It's like making the Mac AUs 64-bit, or addressing denormals, everything must be updated in the whole library now. I have all the MacOS ones (see 'NewUpdates.zip' on my site) and now I am doing all the Windows and Linux VSTs, and then I have to build all the individual plugin downloads, so this can't happen overnight.
Old 24th January 2019
  #634
Motown legend
 
Bob Olhsson's Avatar
 

To quote an old friend of mine, "you can't learn less!"
Old 24th January 2019
  #635
Gear Maniac
 
Decompress's Avatar
 

Quote:
Originally Posted by Bob Olhsson View Post
...the early daze of high fidelity digital recording.
Classic.
Old 28th January 2019
  #636
One word:

Airwindows
Old 28th January 2019
  #637
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by theMuzzl3 View Post
One word:

Airwindows
meaning 'yeah, I did all the updates and put out DitherFloat'

Go ahead and play with it: DitherFloat and its thread in New Product Alert has much much more information. The code for the 32-bit floating point dither is also public domain (Unlicense) so anyone who wants to secretly add it to their plugins can do that with no legal barrier or requirement at all. Though honestly right now I've got people saying they can hear it even using just one plugin in a chain: I doubt that, but expected as much as it's human nature to maybe pick up on tiny hints of betterness and believe it's more obvious than it is.

It's definitely a new form of Bob Ohlsson 'not digitally crunchy' and I had the same feeling, though my impression was more 'oh. Yes, that's right. That's what it's supposed to be' without being able to put my finger on specifics of WHY the sound had just become right, or what exactly had been faintly wrong.

So anyone wanting to ride the predictable hype wave can incorporate the public domain code and then announce they've joined the party. I've asked people to not bug devs about this, as that will just make people cranky. Bottom line, though: please dither stuff that is supposed to be dithered. Turns out you are in fact supposed to dither mantissas, and scaling to the exponent is how. I'm sure it will have a larger cumulative effect across entire modern mixes than it does on isolated plugins
Old 30th January 2019
  #638
I need to learn much more about best dithering practices, I haven't read most of this thread, and I find it hard to grasp a lot of what Chris is talking about, when he explains things.

But, here are my opinions:

I used to say: either use TPDF to render audio at 24 bit, or render at 32 bit floating with no dither... for any audio that is going to have further nonlinear processing (IE rendering stems to be mixed, or rendering a stereo track to send to a mastering engineer). At some point, I became unsure if 32 bit rendered audio would be better with or with out TPDF dither.

Now, and I am unsure if this is correct, I am saying: use FloatDither and dither to 32 bit float. I am unsure if this is correct, and hopeful that some one will clarify this for me.

For final renders of a mastered track, use NotJustAnotherDither for 24 bit, in most cases. For final masterings for CD, use NotJustAnotherCD for a 16 bit rendering. IMHO, those are the best final dither on the market, by far.

Ozone's MBIT+ dither is what I used before I discovered Airwindows, some 8 months ago... and it is also good. But, making the switch was immediately one that I could clearly hear an improvement in the audio from... and though that could have been the way my brain tricked me into believing it, because I was so thrilled after watching the youtube video about the NJAD & NJACD.

I'd suggest some of the other Airwindows dithers for final dithers of some content, depending on the flavoring that you're going for. I haven't learned about that stuff yet because there is just too much information for me to try and learn right now; and I am overwhelmed by it all.
Old 31st January 2019
  #639
Motown legend
 
Bob Olhsson's Avatar
 

Indeed, dither should be an integral part of every plug-in and DAW. Dither treated as a tacked-on option is as dumb as AC bias being optional on an analog tape recorder would be.
Old 9th February 2019
  #640
First and most firstly, thank you to everybody who has contributed to this thread, specially @chrisj who has shared such a huge amount of knowledge here. THANK YOU.

After reading the latest posts over and over, and learning about the official release of the new plug-in 'DitherFloat', here are a few questions still:

Quote:
Originally Posted by chrisj View Post
You as a user wouldn't be using this. You're not switching from a 64-bit buss to 32-bit buss mid-stream.
Am I really not? My current workflow right now is 64-bit processing buss inside the DAW (as configured-per-project in REAPER 5) with some of my VSTs plug-ins processing at 32-bit (as measured with Stilwell's Bitter) and other external editors such as iZotope RX and Melodyne Studio opening and working with files at 32-bit only. So does my processing-buss go from 64-bit into (truncated) 32-bit every time I use such plug-ins or I create ("glue", "consolidate") a brand new file for opening inside an external editor? Should I apply 'DitherFloat' before going into 32-bit processing plug-ins inside my FX chain or right before rendering/glueing to a new 32-bit file that I can open in RX/Melodyne?

I guess this issue can be of many people's concern as many plug-ins, as of 2019, still don't do their math at 64-bit precision. (@FabienTDR, who has been very insightful in this thread, has just only recently had his Tokyo Dawn Labs' brand of plug-in process at full 64-bit as requested by his customers, as his first thoughts were that 64-bit processing was unnecessary and overkill. FWIW, I'm a TDL customer, user and fanatic myself. His claims on the subject can be read here at GS.)


Quote:
Originally Posted by chrisj View Post
...when he hears an imperceptible crunchiness as part of audio he's working with, and checks, and the 24 bit file was exported undithered."
We know Bob O. has got good ears and good monitoring but what how can he acually 'check' other than using his hearing? Is there a way?

Quote:
Originally Posted by chrisj View Post
"...if you can use a 64 bit engine as part of it, that will help whether or not the engine dithers to 32 bit float. Back and forth is just fine: without it, you're doing lots of tiny little 32 bit truncations for every little calculation. I don't recommend using floats as temporary audio variables inside plugins at ALL. Use doubles, at least.
Fine, so @Deckdaddy's concern are the same as mine and, as you suggest in your answer, I will keep using a 64-bit processing-buss inside REAPER. Just so we know: what are floats and doubles here? 32 and 64-bit precision algorithms?

Quote:
Originally Posted by chrisj View Post
"... I am updating EVERY plugin to dither instead of 'noise shape' to the floating point buss'.
I guess they are NOT going to dither if your plug-in is processing at 64-bit and my DAW-processing buss (that is, project settings) is at 64-bit too, right? I know for a fact that some of Airwindows' VSTs work at 80-bit but not all of them, I guess.

Once again thank you so much Chris, you're a genius!

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 9th February 2019
  #641
Quote:
Originally Posted by Bob Olhsson View Post
The buildup of truncation artifacts is the problem. Dither simply eliminates them. Too many tech pundits and even developers seem to think it's just noise that covers them up. Paul Frindle was also opposed to noise shaping so it's interesting to see Chris coming to the same conclusion in this case.
Yes indeed, the build-up and accumulation of truncation artifacts is the worst part of it, especially for us working with lots of plug-ins and summing to a digital master. Now, Bob, are you implying that noise-shaping is discouraged and advised against, whether by you, Paul Frindle or Chris Johnson?

I'm just asking honestly to know if I should tick that box in my rendering dialog or not. I haven't conducted many tests on that specific subject (strictly noise-shaping) yet. Thank you.-

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 9th February 2019
  #642
Motown legend
 
Bob Olhsson's Avatar
 

Paul and other experts suggest noise shaping should only be used in the final process which today is only found in the listener's equipment. . My work has shown it less effective with modern converters.
Old 9th February 2019
  #643
Thank you Bob for such a quick reply on a Friday night!
Old 9th February 2019
  #644
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by morfi View Post
Am I really not? My current workflow right now is 64-bit processing buss inside the DAW (as configured-per-project in REAPER 5) with some of my VSTs plug-ins processing at 32-bit (as measured with Stilwell's Bitter) and other external editors such as iZotope RX and Melodyne Studio opening and working with files at 32-bit only. So does my processing-buss go from 64-bit into (truncated) 32-bit every time I use such plug-ins or I create ("glue", "consolidate") a brand new file for opening inside an external editor? Should I apply 'DitherFloat' before going into 32-bit processing plug-ins inside my FX chain or right before rendering/glueing to a new 32-bit file that I can open in RX/Melodyne?
Indeed not, before going into 32 bit processing plugins, because those would have to be dithering after their processing before outputting 32 bit. Trying to dither first is useless. Also remember: this is of tiny tiny importance, especially on quiet sounds that are already using super fine granularity thanks to the floating point, and there's a million things more important than this. We are gilding lilies here

Quote:
Originally Posted by morfi View Post
I guess this issue can be of many people's concern as many plug-ins, as of 2019, still don't do their math at 64-bit precision. (@FabienTDR, who has been very insightful in this thread, has just only recently had his Tokyo Dawn Labs' brand of plug-in process at full 64-bit as requested by his customers, as his first thoughts were that 64-bit processing was unnecessary and overkill. FWIW, I'm a TDL customer, user and fanatic myself. His claims on the subject can be read here at GS.)
I sure disagree, but it's worth mentioning that you can get subtly different sounds through intentionally using things like floats or fixed point formats like scaled ints. I tend to like stuff where you never go for those textures but it's artistically valid.

Quote:
Originally Posted by morfi View Post
I guess they are NOT going to dither if your plug-in is processing at 64-bit and my DAW-processing buss (that is, project settings) is at 64-bit too, right? I know for a fact that some of Airwindows' VSTs work at 80-bit but not all of them, I guess.
Practically all of them at this point, and yeah my stuff also dithers to 64 bit doubles if that's what your buss is. Even more than with the float, this is just anal-retentive ultra-fussiness: I would know if I wasn't doing it. The noise levels are insanely small to do that, requiring the long doubles. If you said you heard that dither, I would never stop laughing

Remember this is gilding the lily, trying to push for particular tonalities: if you ever sincerely argued for how CDs sound way better than silly old vinyl records, you probably don't even LIKE the tonalities we're shooting for here. It is a fascinating journey, but sort of excessive
Old 9th February 2019
  #645
A quick, and possibly foolish, question for chrisj: It is not possible to undo the effects of truncation, on a truncated audio file is it?

I had always presumed not, and it has been a constant thorn in my side ever since my most valued recording had been truncated, in the process of word length reduction after editing on Sonic Solutions in 1995. It was 2 years later that I heard for myself the horrible effect that truncation had on otherwise excellent recordings, particularly of the type I did (large acoustic ensembles—choirs, orchestras in good acoustics). I then asked the engineer if he had truncated my master and he said something like "sure—why add noise??".

What I was hearing as the effect of truncation in direct comparison to the untouched master was that it coarsened the texture of the sound, reduced image focus and partially eliminated the sense of space. I would never have attributed this to truncation if I had not, by the most amazing coincidence, been reading an article John Atkinson of Stereophile magazine had written about accidentally applying truncation to a recording of his that he was mastering on Sonic Solutions. The effects he noticed were, point for point, exactly what I had identified on my own recording just two hours before in comparing it with the master to see if the ticks I was hearing (which I later found out were mis-clocking) were on the master I had sent. They weren't, and also the master had all the qualities I had just thought perhaps I had been kidding myself in thinking were on my recordings.

The next day I phoned the engineer, discovered he had never done anything but truncate all recordings that went through his establishment and, of course he no longer had my master—his 2GB hard drive which cost around $12,000 when he bought it around 1992 if I recall—pretty much had to be erased after every session to make room for the next project.

This recording, truncation notwithstanding, was still used by Bruce Swedien in his ribbon mic lectures as an example of good string recording. All I have of the original is small fragments.

Anyway, I'd like to think in this day of reverb removal and adjusting pitch on individual instruments in a stereo mix the undoing the effects of truncation might to some extent be possible.
Old 9th February 2019
  #646
Quote:
Originally Posted by morfi View Post
(@FabienTDR, who has been very insightful in this thread, has just only recently had his Tokyo Dawn Labs' brand of plug-in process at full 64-bit as requested by his customers, as his first thoughts were that 64-bit processing was unnecessary and overkill.
Wait, I was specifically talking about 64bit I/O. NOT about processing. We always did 64bit processing or more when ever needed (or cheap enough to do it anyway).

What we added was the VST2 specific extension allowing hosts to send and receive buffers of "double" precision numbers (i.e. 64bit), in addition to the common block of "float" (32bit floating point numbers). With I/O, 32bit is still very generous. Of course the noise is higher when analysing 32bit IO plugin vs 64bit IO, if the measurement tool covers a range of 180dB or so. And if you enjoy tweaking physical things such as air pressure, below atomic scales (!), for whatever reason.

Question is, how relevant is it? In my experience, it isn't and doesn't affect the function of the plugin at all.

AAX and AU still purely use 32bit I/O to date. This obviously can't be much of a bottleneck.

Higher processing precision is something completely different and under full control of the developer. He can use 256bit math if needed, or 512bit, whatever. This area isn't particularly difficult or relevant in my experience. In nearly all cases, the necessity for such a hilarious precision relates to weak algorithm design.

Common 32bit floating point I/O practically has the precision of normalized 24bit fixed point. This is ~144 dB of dynamic range, generously oversized for audio. Humanity made incredibly successfully records using systems with maybe 60dB of available dynamic range. A ~15849 times higher noise floor than any kid has access to today! A ~15849 times lower noise floor than the Beatles had available.

Last edited by FabienTDR; 9th February 2019 at 06:54 PM..
Old 9th February 2019
  #647
@Russell Dawkins very sorry to hear that story! It's shameful really. And very much looking forward to hearing @chrisj or @FabienTDR answer on the question: "can truncation distortion be identified (other than by ear) and remove/undone"? I guess it cannot...

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina.
Old 9th February 2019
  #648
Quote:
Originally Posted by FabienTDR View Post
Wait, I was specifically talking about 64bit I/O. NOT about processing. We always did 64bit processing or more when ever needed (or cheap enough to do it anyway).
Yes @FabienTDR; thank you for your clarification and sorry for my mistake. Indeed I got confused for a minute between 64-bit processing and 64-bit bussing.

So, if I understood you correctly, what you are saying here is that 32-bit is a more-than-good-enough precision to deal with regarding the actual DAW project settings and the resulting mixing/mastered files and is completely apart from the developer's plug-ins's own processing precision, am I correct in that assumption?

IIRC you claimed in another thread here at GS that TDL's plug-ins originally had 32-bit I/O but you went to 64-bit I/O for the VST 2 format due to the many user-requests (me being probable one of those!) Now would you as a user/mixing engineer still keep on working under 32-bit inside your host/DAW and bouncing 32-bit files?

And more importantly: if the TDL plug-ins always processed at 64-bit but then went to output a 32-bit word-length buss to the host, how is that stream of 64-bits transformed into a 32-bit word and why wouldn't it be "healthier" and cleaner for a 64-bit-processed stream of audio to flow thru the host's buss at the very same bit-depth?

I'm really trying to learn a bit more here and definitely not trying to taunt or challenge anybody! Thank you in advanced.

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 9th February 2019
  #649
Quote:
Originally Posted by chrisj View Post
Indeed not, before going into 32 bit processing plugins, because those would have to be dithering after their processing before outputting 32 bit. Trying to dither first is useless.
Firstly, thank you so much @chrisj for your most quick answer.

Secondly: sorry but I still don't get it.

My host's internal buss is working at 64-bit, so I'm streaming a buffer of 64-bit audio into an old x86 plug-in that will output a 32-bit stream (as can be easily measured with Stilwell's Bitter) so I can presume that, whatever the internal precision the DPS inside the plug-in may implement, it will likely interpret and receive only a 32-bit audio stream at its input (since it also outputs a 32-bit audio stream). So what's going on there? Isn't truncation taking place? Should I not dither before going into an inferior, smaller bit-depth bussing?

If I can brief some of what's been said here in the past few, exciting pages, I would say @FabienTDR would say "no, you shouldn't dither because it's not possible to dither in the floating-point domain" and @chrisj would say "yes it is".

The same dilemma could be framed by asking "if Airwindows plug-ins internal processing is most of the times done at 80-bit precision, how does the audio-stream later turn into a 64-bit or 32-bit precision audio buffer for going out the plug-in into the host? How was it done BEFORE 'DitherFloat' and floating-point-dithering existed?

Yes I understand this is not something a mixing engineer should pull out his/her hair for, but I still would like to know your advised best practice

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 9th February 2019
  #650
Quote:
Originally Posted by morfi View Post
If the TDL plug-ins always processed at 64-bit but then went to output a 32-bit word-length buss to the host, how is that stream of 64-bits transformed into a 32-bit word and why wouldn't it be "healthier" and cleaner for a 64-bit-processed stream of audio to flow thru the host's buss at the very same bit-depth?
It gets truncated.

Sure, avoiding this truncation is maybe purer, but is largely irrelevant at this point. Nobody gets "sick".

Floating point truncation is sufficiently complex to turn truncation of any music signal (anything except the lab sine) practical self-dithering. i.e. creates its own noise floor, without producing any measurable structure. It also happens several thousand times below our threshold of audibility. You could repeat this process several thousand times and still not measure or hear any problem beyond a simple increase of the noise floor.

Your own presence also affects the trajectory of the moon, question is, how much is it worth taking it into consideration when going out for shopping?

The only reason why processing sometimes requires greater internal precision is recursion. i.e. Algorithms reusing previous results. These can quickly accumulate gazillions or little errors, in the worst case, manifesting in the form of new partials appearing in the spectrum. That's because they repeat exactly the same operation (and errors) countless times, often infinitely.

When processing audio with a plugin, one rarely repeats the exact same operation for a gazillion times. All what happens is a simple, generously oversized super hi res truncation. One atom taken away from from a football, per kick. How long can the game last?

(don't take my analogies too seriously, just trying to give an idea of the scales we discuss)

It's easy, really. Measure it, find a real problem. I haven't seen too many documented problems in this sector. Maybe something similar to this could help: Good dither practices, what are yours?

Last edited by FabienTDR; 10th February 2019 at 02:10 PM..
Old 9th February 2019
  #651
@FabienTDR really clear and straight-forward answer, not to mention quick. Thank you enormously for this.

This all goes to make me wonder if I should still configure my sessions in REAPER at 64-bit...!
Old 9th February 2019
  #652
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by morfi View Post
Firstly, thank you so much @chrisj for your most quick answer.

Secondly: sorry but I still don't get it.

My host's internal buss is working at 64-bit, so I'm streaming a buffer of 64-bit audio into an old x86 plug-in that will output a 32-bit stream (as can be easily measured with Stilwell's Bitter) so I can presume that, whatever the internal precision the DPS inside the plug-in may implement, it will likely interpret and receive only a 32-bit audio stream at its input (since it also outputs a 32-bit audio stream). So what's going on there? Isn't truncation taking place? Should I not dither before going into an inferior, smaller bit-depth bussing?
*blink*

*blinkblink*

I stand corrected. And plead 'insignificance' because I was wrong, and you were right: yes, the input buffer on a 32-bit (buss) plugin is also a float, yes you can dither into the input buss even when that won't affect being able to dither the output buss, yes this is a kind of valid act relating to handling of the word length. You were right, I was wrong, yes you can use my DitherFloat to dither into the input of the 32-bit-only plugin.

The ONLY point me and FabienTDR agree on here is this: it doesn't freakin' matter. As the developer of the 32-bit-float dither, I intended it to be used for saving 32-bit-float files out of an otherwise double precision stream that you'd want to preserve as fully as possible. It's gleeful overkill and the concept itself is there (and put out via Unlicense to formally make it public domain) so that plugin devs can do likewise from running a MUCH longer internal buss. My whole 'purest' line was an exploration of finding sonic differences in said much longer internal busses, and much like hearing the wow/flutter of vinyl records, some people will relate to these improvements and some just won't be geared to them at all and will find it pointless.

I'd add this: though technically you can dither into a 32-bit-buss plug in a 64 bit chain, it's not gonna help much when the output is also 32 bit. I'm not sure to what extent the output float will simply undo whatever you gained in linearity rendering the 'tweak' useless. I AM sure that you shouldn't be able to hear a roughly 25-26 bit dithering-vs-truncation on input data alone, when the output buss is also 32 bit float. And remember, you might be thinking 'but if it's a compressor?'. But if it's a compressor, it's bringing up quieter stuff which is at a different exponent: so the WORST you can get out of any input condition no matter how much you compress it is 25-26 bit. The WORST it could be. And then the output will go to float directly. I just don't see how you'd get any benefit at all: if you want double precision on your buss use double precision plugins, even Fabien is making that possible.

Me and him agree on almost nothing but agree on this: though it is technically correct to dither into a conversion to float, w.r.t 32 bit plugins, we beg of you please don't, and if you do, don't tell people how much better it sounds and that they must do it. If nothing else, the undithered conversion to float on the output will bury any benefit you gained, never mind if the whole thing runs internally on floats
Old 9th February 2019
  #653
Another in-depth and revealing answer. Thank you!

Quote:
Originally Posted by chrisj View Post
As the developer of the 32-bit-float dither, I intended it to be used for saving 32-bit-float files out of an otherwise double precision stream that you'd want to preserve as fully as possible.
Well, my whole chain is a double-precision stream so why not use DitherFloat myself, being a mixing/mastering engineer, not a plug-in developer. For instance, when bouncing off 64-bits master to 32-bit for Spotify. Or glueing internal 64-bit-precision edited takes into a brand new 32-bit file for further processing outside my double-precision host (i.e. going from REAPER to iZotope RX and back).

Yes I understand it's not the end of the world if I do or if I don't. Let me know when I'm pushing you too hard on these questions

Quote:
Originally Posted by chrisj View Post
if you want double precision on your buss use double precision plugins, even Fabien is making that possible.
Do I want double-precision on my buss? I'm starting to wonder myself now and pondering between the benefits for the end-user and the complications of going back-and-forth between doubles and floats inside plug-ins, external editor, temporary-files, etc.

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 10th February 2019
  #654
Lives for gear
 

Quote:
Originally Posted by nkf View Post
Do I get this right now? FabianTDR says dithering from 32 floating point to 24 bit (fixed) makes no sense, while Bob Olhsson reports that Paul Frindle worked on dithering floating point data? I go with a MADI card into a Yamaha DM2000 mixer from Nuendo and Cubase and their 64 bit FP mixing engines. Does it now makes sense to dither the outputs going to the DM2000 inputs, which are 24 bit wide, or not?
Morfi asked me to join in on this thread.

The oxford plugins did indeed dither their outputs even when running host floating point.
The reason for this is that the intended dynamic range of the plugins was 143dB - that was the base noise level of 24bit fixed point. Some plugins also had an option to dither at 16bits for CD etc..

When going from 32bit float to 24bit fixed there is a small harmonic error which the dither also corrected..

Ok to start from the beginning to summarise this whole thing:

The 'certainty' associated with numerical digital signals is an error - which means that all digital signals require dither to represent real world signal. I.e real world signal is a continuum without discrete numerical steps.
Dither randomises the 'steps' in the digital data format in order to remove the 'certainty' and therefore remove the harmonic distortion it causes, turning all of the unwanted 'certainty' into random noise. I.e. perfect signal + noise.
Whilst 'uncertainty' (noise) acting like dither can come from any source (ADC, Microphones and ambient noise), changing the levels and processing in the digital data domain can remove it, or create new sources of truncation.
As such changing anything at all to do with the signal - even just changing the level - effectively creates a new signal that potentially requires re-dithering in order to avoid harmonic distortion.
Since dithering every single operation in the digital domain is an onerous task - instead we run internally at the highest possible precision in order to render such errors irrelevant (i.e. 48bit in old processors, 32bit float and 64bit double precision float in modern processors). We are assuming that the errors are so low they don't matter.
We then apply dither specifically to final outputs from the processing where they may get truncated by being reduced to 24bits or 16bits fixed point data - in order to avoid the risk of distortion due to the truncation. Hence the dither on the Oxford plugins and our DSM application.

Ok so far so good. But what if the data is stored or rendered as floating point within the DAW? How is this different?

First of all we have to consider what floating point data really is?
It is simply a mantissa and a scaling exponent, so that every data sample value in the signal stream can be represented at the same mantissa precision however large or small the numerical data happens to be. This means that each and every sample can be placed in the waveform at the full mantissa precision - not just the largest ones
In a nutshell it means that however large or small your signal is boosted or reduced to (within the allowed range) it can be recovered again by rescaling the signal. I.e you can reduce your signal by loads E.g -80dB and recover it again intact by bumping it back up 80dB again - with no appreciable loss of accuracy.

This is in stark contrast to fixed point data, where such an operation would cause a large loss of precision, because smaller sample values occupy proportionally less precision over the fixed value range.

So if the DAW is passing 32bit float, saving a file at 32bit float too will mean that nothing has changed and no extra loss of precision or truncation error is introduced - indicating that no extra dither is required.

If the DAW is running and bussing at 64bit float - and then the result is rendered to 32bit float, some precision will be lost because you have a smaller mantissa. You have a new signal and some extra distortion may occur. Therefore theoretically dither should be added prior to data truncation to remove it.
However unlike fixed point data - the new 32bit floating file will exhibit the same error however loud or soft the file happens to be. So files recorded at low level will not exhibit greater errors. I.e. the sample precsion and thus errors are not level dependent.

Ok - so how bad is the loss of precision from 64 to 32bit float under real term signal conditions?
Well the new 32bit float result (at any legal scaling range) will give an equivalent error at around -140dB below for peak sample values. Lesser sample values will exhibit the same error but are scaled to lower levels - and represent lower signal levels and therefore be accordingly less significant. So the effective distortion will scale with the sample values in an advantageous way - with each sample represented by the same mantissa accuracy.

What this means is that (unlike fixed point files) if the 32bit float file is recorded at say -40dB, it can still be boosted back to 0dB after the event without appreciable loss of sample value precision.

So you might consider that numerical error equivalent to around -140dB for full level sample values - scaling down proportionally with smaller sample values, is not so grave - and adding dither to the 64bit float signal before truncating to 32bit float may not be worth the effort :-)

The chances of you hearing the difference are vanishingly small..

I hope this makes sense.

Last edited by Paul Frindle; 10th February 2019 at 04:57 AM..
Old 10th February 2019
  #655
Lives for gear
 

The people who think truncation from 32 to 24 bits isn't audible, should try dropping a 24 bit internal processing plugin into a fp daw. Alternatively go monitor shopping.

Last edited by Timesaver800W; 10th February 2019 at 02:58 PM..
Old 10th February 2019
  #656
Lives for gear
 
Deckdaddy's Avatar
Quote:
Originally Posted by Timesaver800W View Post
The people who think truncation from 32 to 24 bits isn't audible, should try dropping a 24 bit internal processing plugin into a fp daw. Alternatively go monitor shopping.
And treat their room more lol. I have been really fascinated with dither after discovering how audible in my current studio. It’s definitely a difference if I have a 24 bit dither on my monitoring bus from my DAW or not and telling on a reverb plugin in my DAW fed to my converters to my mixing console.
Old 11th February 2019
  #657
Quote:
Originally Posted by Timesaver800W View Post
The people who think truncation from 32 to 24 bits isn't audible, should try dropping a 24 bit internal processing plugin into a fp daw. Alternatively go monitor shopping.
A 24-bit fixed format source, converted to 32-bit float, without processing, converted back to 24-bit fixed, yields exactly the same data.

The precision of 32bit floating point is practically the same as 24bit floating point. These two formats have been designed to work well in pair. There are a few exceptions related to "Not a Number" numbers represented by floating point, such a various infinities and other nerd stuff. These can't be converted to 24bit fixed without losses (of course).

With very few exceptions, the "24bit fixed" version and its (normalized) "32bit floating point" original practically carry the same data. 32bit floating point is just a more flexible, a more level independent version of 24bit fixed.


In doubt, please post a problem you've found. Simply extract the difference between the original and its exported/reimported 24 bit version, flip polarity on one channel and render/listen. Upload the results here.

Last edited by FabienTDR; 11th February 2019 at 01:19 AM..
Old 11th February 2019
  #658
Airwindows
 
chrisj's Avatar
Quote:
Originally Posted by Paul Frindle View Post
Morfi asked me to join in on this thread.

The oxford plugins did indeed dither their outputs even when running host floating point.
The reason for this is that the intended dynamic range of the plugins was 143dB - that was the base noise level of 24bit fixed point. Some plugins also had an option to dither at 16bits for CD etc..

When going from 32bit float to 24bit fixed there is a small harmonic error which the dither also corrected..
Thank you so I'd like to ask, most specifically:

Did you scale the dither by the exponent (so that for any area of sustained mantissa the dither accurately linearizes it)? Or do you mean that you picked a dither level, perhaps for 24 bit, and used that?
Old 11th February 2019
  #659
Thank you so much @Paul Frindle for chiming in. Your kind input is very valuable to everybody reading and I guess we seem to be coming to some sort of definitive conclusion here.

What I'm left wondering right now is how cumulative this seemingly-petty truncation distortion can get, if indeed it can.

In other words: Fabien and Chris and Paul have all made it clear that the actual truncation error that occurs when going from 80/64-bit into (undithered...) 32-bit is so small that it's insignificant in real life. Now what if your signal goes into this type of truncation a number of times (indeed not gazillions but rather a dozen times) inside your mix by coming in and out of 32-bit bussing plugins, external editors, and the lot? Is it still harmless and impossible to measure?

Thank you to everybody who's contributed so far.

Lic. Ezequiel Morfi | TITANIO
Buenos Aires, Argentina
Old 11th February 2019
  #660
Lives for gear
Quote:
Originally Posted by Bob Olhsson View Post
All good questions!

I've begun mixing into other tracks at 32 bit floating point and then I play the track through a dither plug-in. Kazrog's masterDither seems to be good and it has no latency unlike the various dynamics plug-ins that include 24 bit dither.
Hi Bob... wonderful info as usual and always a pleasure and education to read your posts. So at the risk of making you repeat yourself, do I have this correct?

In protools for example, you would be fine to use a 32 bit floating point and then dither with a plugin last in chain before sending any individual tracks out to analog processing. You would also dither again before bouncing the track on a master fader irrespective of sample rate etc. I'm figuring you would not dither if simply 'committing' a track in protools by pressing commit button. Do I understand ur logic?

By the way, I obtained a solid state EMT 140 in great condition. Wow!
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