David - thanks for the very thorough reply. But I'm still wondering about the First Scenario...
CEP/Audition opens up a 24 bit file as 32 bit float but just 'zero fills' the missing data. There is no 'up-conversion' per se. If you do the analysis before any processing you'll find the actual bit depth is still 24. (highlight a section and click analyze, statistics and look at the value in the 'actual bit depth' box).
Before processing a file, you can prove this:
Open the 24 bit file (it'll open as a 32 bf). Then go file, save as and you'll find an options button in the dialog box - here you can set the format and whether or not to use dither. If you save as 24 bit type1 and uncheck the 'enable dithering' box you get a file identical to the original (bitwise that is).
Yup, I did the file compare via that process, just didn't post about it.
Thanks for the confirmation, glad to hear I'm understanding it correctly.
When editing a 24 bit file in CEP it opens in 32bf as you noticed. After your first process you'll find that your file now has an actual bit depth of 32 bf (analyze, statistics). It does not revert back to 24 until you save it or reduce bit depth deliberately. It remains in 32bf for all subsequent operations.
Ah, I missed this in my testing because I saved the file prior to checking the actual bit depth. I just edited a small section of a 24b file in CEP. Upon running the statistics analysis to identify the actual bit depth (before saving), I found <a> the edited section is 32bf actual, <b> the rest of the file (unedited) is still 24b actual. So...that begs the question: given that the file now contains data at both 24b actual and 32bf actual bit-depth, how does the dither process function? Are dither algorithms smart enough to dither only the edited section that's 32b actual, and truncate the actual 24b sections with zero-fill?
You may be thinking about what happens when editing a 16 bit file - in that case yes, it does dither down with each operation.
Yes, that's exactly what I was thinking. Thanks for the clarification.
Yes, this [Second Scenario] is essentially what happens when you use CEP/Audition. As mentioned, no data points are 'invented' during upconversion when we're talking about bit depth increasing.
Except for the new samples in the edited sections of the file, which CEP has processed in true 32bf, right? See my comment above re now having both a 24b actual and 32bf actual bit depth in the file.
How and when to drop back down to 24 bit? You can do that at least 3 ways
1) use the internal default dither (on the 'save as' dialog box)
2) use internal dither available with edit, convert sample type and then you can choose a few more options such as dither type
3) use a plugin (i.e. waves L2 or IDR).
I use method 3 which I can explain. After all processing, use the plugin to reduce bit depth and dither whichever way you like. Now you have a 32 bf file that only has an actual bit depth of 24 (verified with the analyze statistics method above). So next we want to truncate the 32 bf file to 24. This is done by using the options in the save as dialog box and setting to 24 bit type1, no dither.
Yup, that makes sense. I'm in the process of trying out some different dither algorithms, mainly the native CEP function, Apogee UV22HR, Waves IDR, Waves L2 / IDR w/ noise shaping (but all compression turned off), and MegaBitMax (dither + noise shaping, compression turned off) via the Izotope Ozone plugin bundle. I must say, the difference between MBM and the other dither schemes in the
24-96 dither shootout was nothing short of stunning. But...I want to hear how the different schemes sound for my specific taping / editing purposes.
Note that this method doesn't work if you want to drop to 16 bit. For that you still use the plugin to reduce bit depth to 16 but then you have to go edit, convert sample type and select 16 bit and uncheck 'enable dithering'. Then you save the file (you'll notice the options in the save as box are now greyed out since your file is already at 16 bit.
Makes complete sense. So much so, in fact, I'm not even gonna bother testing this one myself! (Hey, even control freaks have to just let it go, sometimes.)
Yes, and this is one of those things that seems really stupid about Wavelab. Everybody fixes the 'file too large' issue by setting temp files to 16 or 24 bit. That strikes me as a waste of perfectly good detail. 
That's what I thought, as well. So I'm not alone.
In fact, I generally start by saving a copy of the file as 32 bf when I'm working with it because that way a *.pk file is created which allows CEP to open it up immediately (which doesn't happen with 24 bit file because of the required conversion to 32).
Makes sense. Might as well generate the PK file and not mess around with the slower file loads on subsequent openings of the file.
When you're doing Standard Editing it would depend if you're ending up at 24 or 16. For 16, obviously you have to dither. For 24, I would just skip dithering - no point in processing the whole file just to get a smoother fade. That's all you'll accomplish with dither, while adding noise to all the other parts.
Yeah, that's what I figured. Thanks for the confirmation.
So I guess out of all of this, my only remaining question is the one I posted previously in this same post, and I'll repeat here so you don't have to go find it:
Given that the file now contains data at both 24b actual and 32bf actual bit-depth (after editing select portions of the file), how does the dither process function? Are dither algorithms smart enough to dither only the edited section that's 32b actual, and truncate the (zero-filled to 32bf) actual 24b sections?
I *think* you answer the question here:
For 24, I would just skip dithering - no point in processing the whole file just to get a smoother fade. That's all you'll accomplish with dither, while adding noise to all the other parts.
So if I understand correctly, what you're saying here is that the dither algorithms will apply dither to the entire file - both actual 32bf portions, and 24b actual portions padded with zeroes - thereby adding unnecessary noise to the 24b actual portions. In other words, the algorithms aren't smart enough to differentiate between actual 32bf and pseudo 32bf (i.e. actual 24b with zero-pad), and dither only the actual 32bf sections. Well...why the hell not?!?
Alright, so if I'm doing simple fades, just truncate the actual 32bf - they're just fades, after all. But if I'm doing substantial edits, I'm better off dithering. Of course, it can't be that simple: I sometimes perform significant edits to large portions of the file, but not the entire file. In that case, I wonder whether I'd be better of truncating or dithering. I believe in this case, dithering: I suspect the added noise from dithering the actual 24b (unedited) portions of the file will sound better than truncating the actual 32bf (edited) sections of the file.
This is fun! Now for my own dither shootout...
Topic: 24-bit workflow question (Read 7076 times)