Topic: Dither/resampling/temp file tests in Wavelab

[dmonterisi]

Note, this was formerly part of page 3 of this thread, decided to split the discussion:

http://taperssection.com/index.php?topic=47914.30

ok, well, being the complete geek that I am, I just ran a little experiment.  I took a 24/96 track and converted it to 2 16/44 tracks using 2 different methods:

-split first in cd wav and then resampled to 44.1khz, then dithered to 16 bit

-resampled in wavelab then dithered then split in cdwav

the purpose of this was to determine the effects of running batch processes on a group of tracked out 24/96 files to create 16/44 files.  I believed that doing so would create files that would not be identical, would not line up when back together in wavelab and would have sector boundary errors.  It turns out that all 3 are true.

here's what i did:

-opened up 24/96 track in cd wav, split in the middle and saved the 2 resulting 24/96 wavs
-saved the cue sheet
-opened the original 24/96 track in wavelab
-resampled to 44.1 khz
-dithered to 16 bit using uv22hr (saving as new file)
-opened the resulting 16/44 track in cd wav
-opened cdwav cue sheet to insure that cut would be at the exact same spot
-saved the 2 resulting 16/44 wavs in a new folder
-opened up the split 24/96 files in wavelab
-resampled each to 44.1
-dithered each to 16bit using the same uv22hr algorithm and the same "save as new file" method
-moved the resulting 16/44 files to the same folder as the other 16/44 split wavs
-compared the files using shntool cmp function
-checked the files using the shntool len function
-opened the first files in wave and inserted the second half of the file at the end using the edit>insert audio file>at end function and zoomed in to the splice point to see whether the wavs matched up.

results:

-the corresponding tracks (comparing the 2 tracks that are the first half of the original track against each other )are identical in size
-using the shntool cmp function to compare the corresponding, the tracks are not identical. 
-using the shntool len function illustrated that the files that were split first, then resampled, then dithered had sector boundary errors in between the two tracks, while the tracks that were resampled > dithered > split did not have sbe's
-opening the tracks in wavelab and inserting the second half of the track at the end: the files that were split, then resampled, then dithered, did not line up when the tracks were reassmbled.  the tracks that were resampled, then dithered then tracked lined up perfectly.

take this fwiw, but it just proves that i'm a bigger geek than any of you.

[Ray76]

thanks for that work Damon. I was going to do something similar but you beat me to it.

I wish I could establish an efficient workflow for this...Does the "align on sector boundaries" tool in flac frontend work at all??

[dmonterisi]

don't know about that function, i've never had to use it...but the bigger problem than the sbe's is that the tracks don't line up, which could cause pops at the track boundaries.  and if you were to use the pad function in shntool to fix the sbe's, i'm not sure what it would do to the files on account of them not lining up properly.

[F.O.Bean]

damon, so when you did this, did you have your temp image to 24-bit or 16-bit

[dmonterisi]

temp file was set to 16 bit.

[F.O.Bean]

you dont think having it set to 24 or 32 bit is necessary and adds and detail and accuracy to the processing?

[Cooker]

whoa, reading this thread made me very worrisome. i used to use wavelab batch processing to resample all the time (now i usually just split the wav in two and resample that way)

i'll have to go upstairs and do some tests on my own.

big +T Damon.

[dmonterisi]

you dont think having it set to 24 or 32 bit is necessary and adds and detail and accuracy to the processing?

i don't think it's likely to affect anything for simply adding fades, resampling and dithering.  if i was using some of the intensive plugins, i guess it could be different, but i don't really know what affect the temp float file would have.  I'd be curious if anyone had info on that.  i tried to look a while back but steinberg's website is about as user friendly as wavelab...

[Ray76]

so what would be a proper workflow for using wavelab???

given the file size limitation....

i prefer to use wavelab for the UV22 algorithm......i sometimes add gain but rarely(the 722 metering has made for more recordings that are perfect db level-wise) im at a loss now.

how do i dither a file greater than 2g???is it possible with wavelab>??maybe im doing something wrong...

[dmonterisi]

in light of Bean's question I ran a few more tests this morning.  These are by no means scientific and 1 test result does not prove anything.  just meant to try and work to the bottom of some of these questions and get some discussion on them.

I took the same 24/96 wav that i was working with above and did the following

-with the temp file size set to 16 bit temp file (Options > Preferences > File in wavelab), I resampled from 96khz to 44.1 khz using wavelab's convert sample rate function (Process > Convert Sample Rate) [as an aside, i believe some people are using plugins for converting sample rate, but since not everyone has these, i decided to use the native wavelab function)].  I then dithered to 16 bit using the UV22HR plugin set to process whole file, create new specific file.

-did the same resampling and dithering operation using 24bit temp file

-did the same resampling and dithering operation using 32 bit float file

-compared the resulting waves by inspecting the waveform, using wavelab's "compare audio file" function and listening.

results:

-the waves look identical on visual inspection.  this is obviously somewhat meaningless, but i wanted to see if there somehow would be drastic differences in the visual waveform and there are not.

-using the compare utility yeilded the most interesting results.  files processed under 16 bit temp file and 24 bit temp file were identical to each other.  there were 81 differences between the file processed under 16/24 bit temp file and the file processed under 32 bit float.  wavelab dropped markers at 10 points in the wavs (maybe the 10 biggest differences?), but i could not readily see the difference between them when zooming in.  there may have been a slight slight difference in one peak, but i could not even tell if the zoom on the 2 files was at the exact same level.  really would be an extremely extremely subtle difference, imo, if there is anything.

-no difference in audio characteristics, but this is completely meaningless as i'm listening on pc speakers.

again, this is all fwiw, meant to foster discussion to see if we can reach some reasoned consensus on the best way to be processing these large files.  ie, whether the slight, subtle differences between processing at 16bit float v. 32 bit temp float justifies all the subsequent problems related to working with 2 gig files.  fwiw, i am able to work with 2 gig 24/96 files opened up next to each other in wavelab and resampled and dithered as a whole.  this negates a lot of the problems that people have in processing these files, if you chose to operate below 32 bit temp float.

[Ray76]

thats the answer I was looking for. Thanks man.

+T Damon.

my prayers are answered. I appreciate your work on this.

[dmonterisi]

no problem ray, i'm running another couple of tests right now to verify a workflow that i have used in the past and will post in a little while (this one will take a little longer).

also, i should note in the resampling/dithering tests above, when resampling, the sample rate conversion process took the following amount of time:

16 bit temp: 12s 796ms
24bit temp: 12s 823ms
32bit float temp: 33s 321ms

the dithering times were roughly equal (within 1 sec of each other), but i could not write them down as the window closed, they were about 12 s each for all 3 settings.  again, fwiw.

[Ray76]

no problem ray, i'm running another couple of tests right now to verify a workflow that i have used in the past and will post in a little while (this one will take a little longer).

also, i should note in the resampling/dithering tests above, when resampling, the sample rate conversion process took the following amount of time:

16 bit temp: 12s 796ms
24bit temp: 12s 823ms
32bit float temp: 33s 321ms

the dithering times were roughly equal (within 1 sec of each other), but i could not write them down as the window closed, they were about 12 s each for all 3 settings.  again, fwiw.

thatd be awesome man. if I had a workflow that was accurate with SBEs  and tracks lining up that utilized wavelab, thatd be great. im too dumb with that sort of thing to figure it out. im sure others are anxious to see the results too.

[dklein]

This post got split while I was replying so here's a copy of my reply from the original...

why do you say that it should be set to 32bit float temp files?  that creates all sorts of problems.  change that setting to 16 or 24 and you shouldn't have problems resampling entire sets. 

If it's just cuts, then no, but if there's any processing going on it should happen at the highest possible resolution and stay at that resolution until the very end.

cut and pasted from Wavelab help

This pop-up allows you to select a resolution for the temporary files that WaveLab creates when you work. You can choose between 16 bit, 24 bit and 32 bit float files. Some general guidelines:
- If you ever plan to export your files in 24 or 32 bit format, use this resolution or a higher one for your temporary files as well.
- Even if you only work with 16 bit files, selecting 24 bit for your temporary files can improve audio quality slightly.
- For less critical applications where speed and disk space are crucial factors, use 16 bit temporary files.

i do not think you should dither/resample after cutting them to tracks, i believe that will lead to all sorts of errors with the files not lining up and sbe's.

I agree

using the shntool cmp function to compare the corresponding, the tracks are not identical. 

I think this will always happen because dither incorporates a random component of noise.  You can run the same thing twice and it won't be identical.

the files that were split first, then resampled, then dithered had sector boundary errors in between the two tracks

That's because of the order of operations:

1. opened up the split 24/96 files in wavelab
2. resampled each to 44.1


CDWave will split in 1/75th second intervals, even at 96k.  Then you resample to 44.1 - the resampling algorithm has to change the timing and it's not landing on exactly the same spot as you'd want it to for a 44.1k

The math - 44,100 / 75 = 588 samples per sector to be red book compliant
your 96k file:  96,000 / 75 = 1280  (meaning CDWave will track in blocks of 1280 samples when using a 96k file)

Now resample a '1280 sample' block back from 96k to 44.1k
=1280*(44.1/96) = 588

So far, so good BUT in order to land back at 588 samples, you need to be extremely accurate about your sample rate conversion and I believe that sort of accuracy isn't in place.  At some point, you might end up with 589 samples.  I believe this is exclusively dependent on the SRC engine (nothing to do with dither).
Are your SBE's in the neighbourhood of 1 sample out by chance?

the bigger problem than the sbe's is that the tracks don't line up, which could cause pops at the track boundaries

Probably just the result of the two points above - random dither and SRC issues.

fwiw, whether I'm doing 16 or 24 bit, I always process the entire file as a single item and then track/split with CDWave.  I can use the same cue sheet for 16 and 24 bit files - just change the name of the file with a text editor. 
When editing, temp files are set at 32 bit (although I use CEP/Audition for everything but authoring DVD-A).  I've never run into a 'file too large' error - CEP just keeps rolling out the temp files as required.  And for 24 bit stuff going to DVD-A, I don't even split it.  I just feed the whole file and cue sheet into a Wavelab montage to make the DVD-A.

take this fwiw, but it just proves that i'm a bigger geek than any of you.

You're in good company my friend 
+t for the investigative work

[dmonterisi]

why do you say that it should be set to 32bit float temp files?  that creates all sorts of problems.  change that setting to 16 or 24 and you shouldn't have problems resampling entire sets. 

If it's just cuts, then no, but if there's any processing going on it should happen at the highest possible resolution and stay at that resolution until the very end.

cut and pasted from Wavelab help

This pop-up allows you to select a resolution for the temporary files that WaveLab creates when you work. You can choose between 16 bit, 24 bit and 32 bit float files. Some general guidelines:
- If you ever plan to export your files in 24 or 32 bit format, use this resolution or a higher one for your temporary files as well.
- Even if you only work with 16 bit files, selecting 24 bit for your temporary files can improve audio quality slightly.
- For less critical applications where speed and disk space are crucial factors, use 16 bit temporary files.

ok, i agree that from a theoretical perspective, it's most certainly best to say "any processing should happen at the highest possible resolution and stay at that resolution until the very end".  however, we have to work within limitations.  I believe that wavelab was not really designed for processing of full sets.  i think the goal was to be working with much smaller chunks of data.  so, given the fact that is is as important to work with full sets of music here in order to deal with 24/96 file sizes and to avoid boundary errors, something has to be sacrificed.  and that's why i wanted to run tests to see if i could determine the difference between working at 16, 24 and 32 bit temp files.  the interesting result to me is that the files processed at 16 and 24bit temp file sizes are in fact identical.  theoretically, there shouldn't be a need to work at 32 bit float for resampling and dithering.  24bit temp files should be sufficient to preserve the data at its best.  given that there is absolutely no difference in the resulting wavs when processed at 16bit and 24bit, that (to me at least) counsels in favor of using a 16 bit temp file so that the largest files can still be manipulated with wavelab, thus allowing processing of full 24/96 sets. 

i do not think you should dither/resample after cutting them to tracks, i believe that will lead to all sorts of errors with the files not lining up and sbe's.

I agree

using the shntool cmp function to compare the corresponding, the tracks are not identical. 

I think this will always happen because dither incorporates a random component of noise.  You can run the same thing twice and it won't be identical.

this i'm not sure i agree with.  it's my understanding that computers are not actually capable of doing anything randomly.  even a random component of noise is the result of an algorithm that tries to approximate randomness.  so if you had the exact same wave file and dithered it the exact same way under the same settings, the resulting file should be identical.  see the results i posted where files dithered under 16 bit and 24bit temp files were identical (i just realized your post may have been typed before i posted the results of that comp?)

the files that were split first, then resampled, then dithered had sector boundary errors in between the two tracks

That's because of the order of operations:

1. opened up the split 24/96 files in wavelab
2. resampled each to 44.1


CDWave will split in 1/75th second intervals, even at 96k.  Then you resample to 44.1 - the resampling algorithm has to change the timing and it's not landing on exactly the same spot as you'd want it to for a 44.1k

The math - 44,100 / 75 = 588 samples per sector to be red book compliant
your 96k file:  96,000 / 75 = 1280  (meaning CDWave will track in blocks of 1280 samples when using a 96k file)

Now resample a '1280 sample' block back from 96k to 44.1k
=1280*(44.1/96) = 588

So far, so good BUT in order to land back at 588 samples, you need to be extremely accurate about your sample rate conversion and I believe that sort of accuracy isn't in place.  At some point, you might end up with 589 samples.  I believe this is exclusively dependent on the SRC engine (nothing to do with dither).
Are your SBE's in the neighbourhood of 1 sample out by chance?

i don't know if they are 1 sample out, i only ran the len utility in shntool, it didn't get quite that specific.  i do not know the math behind these things as well as you, so a lot of that is lost on me.

the bigger problem than the sbe's is that the tracks don't line up, which could cause pops at the track boundaries

Probably just the result of the two points above - random dither and SRC issues.

fwiw, whether I'm doing 16 or 24 bit, I always process the entire file as a single item and then track/split with CDWave.  I can use the same cue sheet for 16 and 24 bit files - just change the name of the file with a text editor. 
When editing, temp files are set at 32 bit (although I use CEP/Audition for everything but authoring DVD-A).  I've never run into a 'file too large' error - CEP just keeps rolling out the temp files as required.  And for 24 bit stuff going to DVD-A, I don't even split it.  I just feed the whole file and cue sheet into a Wavelab montage to make the DVD-A.

i have never used CEP (is that the precursor to audition?), but i do have audition and i don't use it because 1. I'm not as familiar as i am with wavelab and 2. everything takes 3 times as long to accomplish.  resmapling a set can take 25 minutes.  fuck that.

take this fwiw, but it just proves that i'm a bigger geek than any of you.

You're in good company my friend 
+t for the investigative work

  T back at ya.