|
| quote: | Originally posted by Derivative
You would only use dither when you truncate bits so it doesn't matter. Dithering is not an alternate to truncating bits. It is a process you employ when you have to truncate bits (i.e. rendering down from 32bit float to 16 bit so that it is playable as CD audio) and the reason you would employ it is to add non cyclical noise to the recording to mask the quantisation error that occurs when you suddenly throw away 16 bits worth of dynamic resolution. |
You're 100% right on concept, just not using the accepted definition of truncate. Truncation literally means you just drop the extra bits. Look it up. In math, truncating a decimal means you just keep the integer part and throw away the decimal, i.e. take the floor even if the value is closer to the ceiling. In audio, it means you just pretend that all the extra bits are zero and slice 'em off.
I'm just nit picking over the definition, that's all. I never said you were wrong. 
-
Halo: good point. In 16-bit or 24-bit you're dealing with integers, and 32-bit is floating-point, that's why most sequencers will explicitly say "32 bit (floating point)" in the list of bit rates.
You're still propagating the same patently false nonsense about losing bits though. It just doesn't work that way. Good digital devices never use any fewer bits when attenuating the signal, they just change the reference level that corresponds to the signal maximum. Before the DAC, you change the signal reference. After the DAC, you alter an op amp.
You're also wrong about roundoff error. Take the number "4", which in the digital domain is 100 or 0x4. You can amplify that by a factor of 3, to get 12, which is perfectly represented as 1100b or 0xC. You haven't introduced any error whatsoever, and it goes without saying that you can also divide by 3 without error if your original number was 12.
In fact, integer multiplication in the digital domain is guaranteed to never introduce any error unless you overflow (i.e. go above 0 dB). Integer division might introduce an error, but not necessarily. It's only in floating-point math where you might multiply two perfectly accurate numbers and end up with an inaccurate one ("0.4" is not perfectly representable, for example). In practice, though, the error is so small that it won't make a difference. 0.4 comes out as 0.400000000002 or something like that.
Converting from floating point back to integer is an issue, and that's what the dithering algorithms in software are for. UV22HR does a great job of making the change almost completely transparent. Waves IDR does it pretty well too.
___________________
My party schedule:
2009-02-21 - DJ Attention @ I'm So Popular
2009-06-18 - DJ Annoying @ People Need To Know Where I'll Be
2012-11-32 - DJ Insufferable ɸ Or At Least the Stalkers I Complain About
2048-06-66 - Spastic & Whocares ¶ Although I'm Actually Flattered
9999-45-81 - Tweaker Gimp ☼ I Probably Won't Even Go To This But I Have To Make Sure I Fill Up All The Available Space Here
|