24-bit workflow question

[Brian Skalinder]

Okay, so...I believe CEP converts to 32bf in its temp files during editing, then dithers back down to the file's native bit-depth after completing processing.  I don't know of a way to change CEP from 32bf temp files to 24b.  But Wavelab supports the option of defining the temp / working file bit-depth (16, 24, or 32).  Which spurs my question.  There are three scenarios we might use when working with 24b files (there may be others, but these are the ones I thought of and are most applicable, I think):

First Scenario (s/w up-convert/dither)

<1> the user allows the s/w to control up-conversion at the time the edits are made, i.e. the s/w up-converts to 32bf during editing (in the temp / working file) and dithers back down to 24b upon completing each operation (all transparent to the user)
<2> no user-initiated dither performed

This strikes me as problematic in that if I apply multiple edits to the same section of the waveform, I'm basically upconverting/dithering repeatedly.

Second Scenario (user up-convert/dither)

<1> the user applies an up-conversion to 32bf to the entire recording
<2> the user performs editing
<3> the user dithers the entire file from 32bf down to 24b only after completing all edits

I think this is the way to go - take advantage of the 32bf and then dither only once.  But perhaps the process of upconverting (i.e. inventing data points) and then dithering is unnecessary?

Third Scenario (no conversion/no dither)

<1> the user sets the s/w to use 24b temp files
<2> the user performs editing
<3> no s/w or user-initated dithering performed

Seems like we ought to take advantage of 32bf for editing?

I've found a few threads on this topic, but not one that comes to any sort of consensus, as far as I can tell.  From a practical perspective, which is the preferred workflow?  I think it depends on what I'm doing...

Standard Editing
I think for my standard editing - fades at sets' start/end *only*, it won't make a noticeable difference which scenario I use, so I'd probably default to the First or Third Scenarios.  For edits applicable to only very small portions of the file, no point in upconverting the entire file to 32bf only to dither back down to 24b.  Might as well only upconvert to 32bf for the affected areas, or leave it at 24b outright.

Intensive Editing
I think if I want to do intensive editing to the entire waveform, like applying gain (i.e. normalizing), compression, or dither/resample to 16/44.1, the Second Scenario makes the most sense to me.  Also, the Second Scenario prevents multiple upconversion/dithering from 24b <--> 32bf as I perform multiple edits (e.g. compress, then normalize, then dither/resample to 16/44).

Am I missing something big?  Do I have it all utterly and hopelessly wrong?  Or am I mostly on-track?

[dklein]

whoa boy...Brian, you are one thorough dude.  Here's a few things to consider.

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).

First Scenario (s/w up-convert/dither)

<1> the user allows the s/w to control up-conversion at the time the edits are made, i.e. the s/w up-converts to 32bf during editing (in the temp / working file) and dithers back down to 24b upon completing each operation (all transparent to the user)
<2> no user-initiated dither performed

This strikes me as problematic in that if I apply multiple edits to the same section of the waveform, I'm basically upconverting/dithering repeatedly.

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.
You may be thinking about what happens when editing a 16 bit file - in that case yes, it does dither down with each operation.  This too can be avoided by going into settings, data and checking the box that says 'auto-convert all data to 32 bit upon opening'.  But I digress...when editing 24 bit you automatically stay in 32bf so no worries about repeated converting and dithering.

Second Scenario (user up-convert/dither)

<1> the user applies an up-conversion to 32bf to the entire recording
<2> the user performs editing
<3> the user dithers the entire file from 32bf down to 24b only after completing all edits

I think this is the way to go - take advantage of the 32bf and then dither only once.  But perhaps the process of upconverting (i.e. inventing data points) and then dithering is unnecessary?

Yes, this 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.

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.

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.

Third Scenario (no conversion/no dither)

<1> the user sets the s/w to use 24b temp files
<2> the user performs editing
<3> no s/w or user-initated dithering performed

Seems like we ought to take advantage of 32bf for editing?

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.     CEP keeps it all in 32 bf until you tell it to do otherwise.

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).

Standard Editing
I think for my standard editing - fades at sets' start/end *only*, it won't make a noticeable difference which scenario I use, so I'd probably default to the First or Third Scenarios.  For edits applicable to only very small portions of the file, no point in upconverting the entire file to 32bf only to dither back down to 24b.  Might as well only upconvert to 32bf for the affected areas, or leave it at 24b outright.

Intensive Editing
I think if I want to do intensive editing to the entire waveform, like applying gain (i.e. normalizing), compression, or dither/resample to 16/44.1, the Second Scenario makes the most sense to me.  Also, the Second Scenario prevents multiple upconversion/dithering from 24b <--> 32bf as I perform multiple edits (e.g. compress, then normalize, then dither/resample to 16/44).

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.

When doing Intensive Editing I'd follow the workflow I described, which is basically...
1) start with 24 bit file, opens in CEP as 32 bf
2) process
3) use favorite plugin to reduce bit depth/dither
4) truncate and save

phew!

[Brian Skalinder]

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...

[it-goes-to-eleven]

Thanks for posting your concerns, Brian.  I've been wondering too.  Looking forward to the dither shootout!

[dklein]

The dither functions do not know which parts may be in 24 or 32.  It will be applied to everything.  I suppose you could choose to only dither your editted 32bf sections and then truncate the whole thing, leaving the 24 bit sections in their original form and the 32 bf sections nicely dithered down to 24.  I think the sonic price of dither is quite when finishing in the 24 bit domain but I haven't proven that to myself.  I find that there's so much ambient noise in a live concert recording that it's not worth worrying about!  If I were to do some listening tests I'd prolly want to start with some clean studio material vs. one of my recordings.  I'm curious if you agree and what you find with your own tests.

Regarding 'invented' data - when you're getting values in 32bf there isn't anything extra there...other than a more precise value (kinda like carrying extra decimal points).  Maybe it's just semantics and we're saying the same thing.  On the other hand, upping the sampling rate would definitely introduce new data as samples are created to fill in the extras required.

[it-goes-to-eleven]

The dither functions do not know which parts may be in 24 or 32.

It would be fairly simple for an application to keep track.  So there is some hope that some will get it right..

I find that there's so much ambient noise in a live concert recording that it's not worth worrying about!

One of the venues I record at (The Ark) is sometimes quieter than my basement (where I try and do noise floor tests). Performers often comment on how quiet it is.

[Matt Quinn]

hi guys-

any suggestions for specific plug ins to use to dither in CEP 2.0?

Thanks!

[Brian Skalinder]

any suggestions for specific plug ins to use to dither in CEP 2.0?

Dither comp here, if you want to listen to a few options.  I like MegaBitMax (MBIT+ in the iZotope Ozone plugin), but it'll set you back $249 or so MSRP.  FWIW, I like Samplitude SE better for editing than CEP/Audition - object oriented editing, sounds great, fast, handles recordings > 2GB, etc. - and it's cheap at $50.

[live2496]

Brian,
Going back to your first post...

The way samplitude does it is like your scenario #2. Files are converted to 32-bit float. Dither is only applied when the word length is reduced. You can apply whatever processing you wish and no dither is applied while the audio is in float format.

Since version 6, 24-bit files are supported natively. In that case I don't think they convert to float unless you bounce.

16-bit files are converted to float within samplitude. I think there is a checkbox option somewhere to do all processing in 16-bit resolution. It's not overly obvious on how to do that and they don't recommend it of course.