I have something in common with Bob, sort of...8)
I have alway been the dumbest person in the room
cheers
Wiz
PS here is my take (to prove my point above).
1. Dither when you are reducing bit depth and you are not sure if its being applied by something within the program you are using (I used to use Airwindows Dither)
2. If you are going in and out of your DAW to hardware, apply dither in the plug in slot prior to the IO plug in. (again I used Airwindwos Dither when I had an extensive outboard setup)
Then test both of the above to see if you can hear any difference...
Then either keep doing it, or not bother, except... bother... you know... or don't
We should never have ever had to have this discussion. This should all be taken care of by the developers of everything we use.
Also, in the grand scheme of things, it's really not that big of a sonic deal....really....millions of other things have a greater impact on the end
result of a recorded song...but...you should know and understand this stuff (except you really shouldn't the f)(*#ing designers should have taken care of it...)
I like what you're saying here, and it's not bad advice.
But I have to point out a problem with "the f)(*#ing designers should have taken care of it". I guess, for doing audio on a computer, that means, for instance, CoreAudio and other digital audio systems at the driver level—the part of the code that hands off float input to a 24-bit DAC. And also any process that saves a file that's not float.
And—though I think the world would run fine on TPDF—I suppose people better have the choice of dither types, so it would be up to things like CoreAudio to support all the form of dither a person might want to use, or a way for third party dither to be installed. Ditto for the DAW's file saving.
And, in general, typical plugins that process audio in floating point wouldn't deal with dither. It would be just dedicated dither plugins as well as plugins that do another master/final-type proessing (Ozone, etc.)...and if you want to use their flavors of dither, then you have to be able to turn off dither for the file saving or the CoreAudio outputs...
What I'm getting at is that it's not so simple. Yes, the developers could just hardwire of floating point conversions and the world would survive. But of the same people who think 24-bit dither is a hugely important deal, some are gong to want the dither they want. CoreAudio does not know whether the buffers are effectively dithered 24-bit riding on float32, for instance, and can even be routing some that's dithered and some that's not. So even if that were built in, you'd still want to be able to turn it off, and those people woujld still have to understand the gorely details of truncations and dither.
So I think you have be be more specific about what you're calling for. You say, "this should all be taken care of", that we shouldn't ever have to discuss this. But unless we, as an industry, pick one thing and say that's just the way it's going to be, live with the decision...then we have to discuss it.
If you've followed what I said before, then you might understand that I'd lose no sleep whether the choice was to always TPDF dither truncations to 24-bit or don't bother (because I contend that it's not possible to tell the difference). So I'm not advocating something here, just pointing out it's not so simple. Dither is not complicated because developers are idiots. It's complicated because there is more than one solution, and the industry hasn't stood up and said, "we'd be fine with one solution, pick what's usually best and implement it it for us, for the sake of simplicity".
Ah, imagine a world...without threads discussing dither...