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.

[dmonterisi]

Next test.  This was a verification of workflow that i had been using with 24/96 files in wavelab.  Here's what i was working with.  Built to Spill show from may, taped 140>722 @ 24/96 with 2 gig file splits.  Resulted in 2 files.  File 1 is 57mins, 40secs, file 2 is 52mins, 49 secs.  I opened up file number 1, then inserted file number 2 at the end using wavelab's edit > insert audio file > at end function.  files lined up properly.  attempted to process files in this fashion at 16bit temp, 24bit temp and 32 bit float temp settings.  results:

-with temp file set at 16 bit, was able to resample entire show from 96khz to 44.1 khz, creating a full set 24/44.1 file.  I did not attempt to save at this point, but that should not be a problem.  I then was able to dither the entire set to 16 bit using the UV22HR algorithm.  i was thus left with a 16/44 full set file that was saved directly using the "save as new file" option in the dither dialog.  at no point did wavelab choke on the 2 gig file size limit, despite the fact that the open window contained close to 4 gigs of data (2 gig file with 1.8 gig file inserted at end and the entire thing processed in place).

-with temp file set at 24bit, I was able to perform the same processes.  wavelab again did not choke on the 2 gig limit.

-with temp file set at 32 bit float, wavelab choked on the 2 gig limit and processing was abandoned.

-I again compared the files created under 16 bit and 24 bit temp files, and the entire sets were once again identical.

So, the important result to me is that wavelab will process consecutive 24/96 files that are loaded into the same window using the edit  > insert audio file > at end function, so long as you stay at 24bit temp files or 16 bit temp file.  it will not deal with 32 bit float files.  This suggests to me that the best workflow is the following:

-set wavelab at 24 bit temp files
-set 722 to 2 gig auto split
-open 2 gig first chunk
-insert next chunk using insert audio file function
-edit beginning and end of set to cut out crowd noise or whatever
-insert fades
-resample entire thing to 44.1
-dither entire thing to 16bit outputting directly to a new file
-track in cdwav

this obviously doesn't deal with creating 24/96 tracks, but to do that, all you need to do, is line up the wavs as above.  after adding fades, drop generic markers where you want the splits to be, then go with Tools > Auto Split > at markers...follow the prompts and save the individual files directly. 

[dmonterisi]

cross-post to slightly related thread, discussing the dithering options in wavelab and referring to the same set

[ford prefect]

Good thread, gotta re-read this one to absorb, but did want to comment on this question from Ray:

Does the "align on sector boundaries" tool in flac frontend work at all??

AFAIK it works fine.  However, you want to be very careful about which files you open and encode when using that option - never turn that option on if you are encoding 2 sets worth of files in 1 go!  If there is a SBE at the end of set 1, this option will shift the split by borrowing samples from the beginning of set 2.  This could be audible when it's done.  You are much better off encoding the sets in 2 separate batches if you want to use FLAC Frontend to remove SBE's.

My understanding is that SHNtool is the same way - when fixing SBE's, you should really do that 1 set at a time.  Let the software pad SBE's at the end of set 1 with zeroes rather than shifting from set 2.

-Brad

[Ray76]

Good thread, gotta re-read this one to absorb, but did want to comment on this question from Ray:

Does the "align on sector boundaries" tool in flac frontend work at all??

AFAIK it works fine.  However, you want to be very careful about which files you open and encode when using that option - never turn that option on if you are encoding 2 sets worth of files in 1 go!  If there is a SBE at the end of set 1, this option will shift the split by borrowing samples from the beginning of set 2.  This could be audible when it's done.  You are much better off encoding the sets in 2 separate batches if you want to use FLAC Frontend to remove SBE's.

My understanding is that SHNtool is the same way - when fixing SBE's, you should really do that 1 set at a time.  Let the software pad SBE's at the end of the set with zeroes rather than shifting from set 2.

-Brad

Thanks Brad. +T BTW...where does everyone buy the plugin that Damon Mentions???Ive seen a lot of folks mention it, but where is the best place to purchase it.?

[dmonterisi]

which plugin are you referring to, ray? 

[heath]

 

let me look at this tomorrow when my head is not somewhere else     

[dmonterisi]

sorry didn't mean to harsh your mellow brah

[heath]

sorry didn't mean to harsh your mellow brah

 

s'all good my headie brotha from anotha motha

[Ray76]

which plugin are you referring to, ray? 

the L1 maximizer

[dmonterisi]

which plugin are you referring to, ray? 

the L1 maximizer

i see...i have the Waves Gold plugins set and it was contained within that...there are a number of different plugin sets available and i believe they work in wavelab and the other audio applications.

[F.O.Bean]

this is kinda confusing this morning

[heath]

i see...i have the Waves Gold plugins set and it was contained within that...there are a number of different plugin sets available and i believe they work in wavelab and the other audio applications.

yup--waves gold will work in a number of other audio programs...basically anything that uses vst.

[heath]

this is kinda confusing this morning

welcome to the club.

[dmonterisi]

team pittsburgh strikes again.

[Ray76]

i see...i have the Waves Gold plugins set and it was contained within that...there are a number of different plugin sets available and i believe they work in wavelab and the other audio applications.

yup--waves gold will work in a number of other audio programs...basically anything that uses vst.

ahh..is there a suggested retailer?

[dmonterisi]

umm, it's pretty goddam expensive, Ray...can't say anything more than that.

[Ray76]

no more info needed Damon.  Thanks man.

[dmonterisi]

lol, here's the waves platinum bundle for a sweet $3150.00...hopefully, they include free shipping.

http://powermax.com/cgi-global/generate_css_temp.cgi?p=de-wpta

[heath]

waves is VERY expensive, but is a phenomenal package of plugins.  if you have the coin, it's worth it--if not, there's others that can do a similar job.  plugins have gotten WAY too expensive.  I'd almost rather buy an outboard processor to run my signal to for processing for possibly less money.

[Ray76]

lol, here's the waves platinum bundle for a sweet $3150.00...hopefully, they include free shipping.

http://powermax.com/cgi-global/generate_css_temp.cgi?p=de-wpta

DAMN! yeah, they can keep that.

[Kyle]

this obviously doesn't deal with creating 24/96 tracks, but to do that, all you need to do, is line up the wavs as above.  after adding fades, drop generic markers where you want the splits to be, then go with Tools > Auto Split > at markers...follow the prompts and save the individual files directly. 

I have CDWAV 1.94.5 and I was under the impression that it will handle 24/96 files, although I have not yet tried it. Is my informatoin incorrect? Thanks!

[Ray76]

this obviously doesn't deal with creating 24/96 tracks, but to do that, all you need to do, is line up the wavs as above.  after adding fades, drop generic markers where you want the splits to be, then go with Tools > Auto Split > at markers...follow the prompts and save the individual files directly. 

I have CDWAV 1.94.5 and I was under the impression that it will handle 24/96 files, although I have not yet tried it. Is my informatoin incorrect? Thanks!

yes it handles 24/96 and seemingly no limits on file size...

[dmonterisi]

this obviously doesn't deal with creating 24/96 tracks, but to do that, all you need to do, is line up the wavs as above.  after adding fades, drop generic markers where you want the splits to be, then go with Tools > Auto Split > at markers...follow the prompts and save the individual files directly. 

I have CDWAV 1.94.5 and I was under the impression that it will handle 24/96 files, although I have not yet tried it. Is my informatoin incorrect? Thanks!

yes, i believe that's fine...the reason i have been using wavelab to do the 24/96 splits is so that i can insert split files continuously without actually creating a 24/96 file larger than 2 gigs. what i mean is if i have an hour and a half set, the first hour (approx) would be the first 2 gig file and the last half hour would be a second file.  with this approach, you can open both in wavelab by inserting the second file through the edit > insert audio file > at end.  then sink track markers and create the 24/96 track files without actually having to create one long file or otherwise maniuplating multiple files through cd wav.  if all your 24/96 files are under 2 gigs, this isn't a concern, but it seems to me to be a good way of dealing with it.

[Kyle]

this obviously doesn't deal with creating 24/96 tracks, but to do that, all you need to do, is line up the wavs as above.  after adding fades, drop generic markers where you want the splits to be, then go with Tools > Auto Split > at markers...follow the prompts and save the individual files directly. 

I have CDWAV 1.94.5 and I was under the impression that it will handle 24/96 files, although I have not yet tried it. Is my informatoin incorrect? Thanks!

yes, i believe that's fine...the reason i have been using wavelab to do the 24/96 splits is so that i can insert split files continuously without actually creating a 24/96 file larger than 2 gigs. what i mean is if i have an hour and a half set, the first hour (approx) would be the first 2 gig file and the last half hour would be a second file.  with this approach, you can open both in wavelab by inserting the second file through the edit > insert audio file > at end.  then sink track markers and create the 24/96 track files without actually having to create one long file or otherwise maniuplating multiple files through cd wav.  if all your 24/96 files are under 2 gigs, this isn't a concern, but it seems to me to be a good way of dealing with it.

right-o. Thanks for the info. I like the idea of using Wavelab to split tracks - takes an additonal step out of the process. One other thing - this may have been covered - sorry if I missed it - does tracking in Wavelab create sbe's? I do not like using shntool. Thanks again and a big +t for the info!

[F.O.Bean]

fwiw kyle, the newest versions of flac frontend have the 'fix sbe' option and it has worked flawlessly for me the past year or so!

i dont believe 24-bit recordings have sbe's anyway tho kyle, only 16/44.1k stuff

[dmonterisi]

yep, bean's got it right, there are no sbe's with 24/96 files.  if you want to use wavelab for tracking 16/44 files, there is a way to do it, using cd splice markers instead of generic markers.  it's discussed in the other thread in this forum entitled "tracking in wavelab or something similar".  the flac frontend option to fix sbe's apparently is a good fix, but i also think the less manipulation of the file the better, so if you can cut them w/o sbe's, that's probably best.

edit to note: this is the thread i was referring to:

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

[Brian]

alright, Damon, I just read this.

like, heath,  i need to re-read this again later tonight   i'm still digesting the alcohol i drank last night, i'm still at work, and don't want to say something completely idiotic, like i know i am capable of doing

BTW - in short, i don't know why anyone would track the show first before resampling and dithering.  also it sounds like your computer can't handle 32-bit float editing.  Can you go into detail about your computer system. specs?  I personally would want that option if i was doing major editing or something like resampling and dither of high res files too.

[dmonterisi]

alright, Damon, I just read this.

like, heath,  i need to re-read this again later tonight   i'm still digesting the alcohol i drank last night, i'm still at work, and don't want to say something completely idiotic, like i know i am capable of doing

BTW - in short, i don't know why anyone would track the show first before resampling and dithering. 

i think the reason that people have been tracking then batch processing is for simplicity.  if you're goin to create 24/96 tracks, then it's simple to run a batch process on all the 24/96 individual tracks to create 16/44 tracks.  it also prevents having to manipulate the 2 gig files to a certain extent.

also it sounds like your computer can't handle 32-bit float editing.  Can you go into detail about your computer system. specs?  I personally would want that option if i was doing major editing or something like resampling and dither of high res files too.

 

i was able to accomplish 32 bit float ediiting on a single 24/96 track, but not when trying to resample 1:50 of 24/96 to 24/44.  it is a p4/2.0/1gig ram.  not ideal by modern standards for sure.  but it didn't seem to me that my computer couldn't handle 32 bit float.  midway through the resampling process, i got the dreaded "cannot create files larger than 2 gigabytes" message from wavelav.

what i'm curious about is why you say 32 bit float ediing is so important.  what about how 32 bit float editing is superior to say 24 bit temp files?  and i'm hoping that someone can share something more than "it is best to work at the highest resolution possible."  I agree that as a guiding principle, this is good advice, but I'm specifically curious as to what would make it so important that it would be worthwhile to chop up 24/96 sets into smaller files to allow 32 bit float manipulation.

[Brian]

yeah your computer is fine.  i misread.  like i said,  i'm a little tired right now

i can't really put it simply why 32-bit float point editing is better.  it has to do with the calculation of bits so that your computer doesn't have to guess. here....read this and try to wrap your head around it. i can't really myself

http://www.mactech.com:16080/articles/mactech/Vol.02/02.07/FloatPoint/

[dmonterisi]

http://www.mactech.com:16080/articles/mactech/Vol.02/02.07/FloatPoint/

 

here's the first two parts, give me a break.

"12 Kflops - Forth goes inSANE"

You might have noticed my frequent complaints about the slowness of the Apple 80-bit SANE routines and the non-availability of a reasonably fast 32 bit floating point package in Forth systems (and most other programming languages, for that matter, Fortran being the only exception).

The scaling that is necessary if you want to do rapid calculations in Forth (using integer arithmetic) is a nuisance, and it is almost impossible to implement general purpose mathematical routines without floating point. Since I needed to run this machine as fast as possible, I set out to write a set of single precision real arithmetic routines.

IEEE 32-bit real numbers

The number format that we are dealing with is the IEEE standard and defined as follows:

bit 31 (highest bit): sign (0 = positive)
bits 30Š23 : exponent (offset = 127)
bits 22Š0 : fraction part (23 bits with the 24th bit always =1)

That is, a real number has the form

(+/-)1.xxxŠxxx * 2yyy,

where the exponent yyy is obtained by subtracting 127 from the stored exponent; only the fraction part of the mantissa is stored because the integer part is always 1 by definition (otherwise, the fraction part will have to be shifted left and the exponent decreased until the integer part is =1; this is called normalization).

The highest exponent, 255, is reserved for special cases: with zero mantissa it designates positive/negative infinity, and with non-zero mantissa it is a 'no-number' (Not a Number or NaN). This latter case is used to mark the results of undefined or illegal operations, such as 0/0, infinity - infinity, square root (-x), etc. The type of 'non- numberness' is indicated by the value of the mantissa.

Floating point arithmetic is thouroughly treated in D. Knuth's 'The Art of Computer Programming', Vol.2. Taking this excellent book as a guidance, the job to write the single precision routines becomes manageable. We'll first consider addition.

[Brian]

so you are saying i should try to find a better explanation?

[dmonterisi]

i'm sure that's fine for people that are insane, but this sentence especially got me:

The highest exponent, 255, is reserved for special cases: with zero mantissa it designates positive/negative infinity, and with non-zero mantissa it is a 'no-number' (Not a Number or NaN).

do you think he made up the word mantissa??

[Brian]

when i get home i'll check my notes from last semester's pro tools class.  i know  we talked about this for a hot minute.  if all else fails, i'll just email my teacher tonight and he'll put in nice layman's terms for all of us

[Brian]

also mantissa = Mathematical Algorithms for Numerical Tasks In Space System Applications.

so, no, he didn't make it up.  but he's still a math dork  

[Kyle]

i dont believe 24-bit recordings have sbe's anyway tho kyle, only 16/44.1k stuff

yep, that's right - o yes

what day is it again?

[F.O.Bean]

i dont believe 24-bit recordings have sbe's anyway tho kyle, only 16/44.1k stuff

yep, that's right - o yes

what day is it again?

day? what? where?

[heath]

I'm extremely unfamiliar with Wavelab, so I'm not even going to risk looking like a fool stabbing at this.  I will start playing with the copy i just got and try to get a grasp on this though 

[MattD]

do you think he made up the word mantissa??

In math, it's the fractional part of a logarithm. However, I looked it up because that doesn't really apply to this conversation and found this:

The part of a floating point number which,
when multiplied by its radix raised to the power of its
exponent, gives its value. The mantissa may include the
number's sign or this may be considered to be a separate part.

[Ray76]

anyone come up with an efficient workflow yet??

wavelab 5 and cd wav preferred.

[dmonterisi]

anyone come up with an efficient workflow yet??

second half of this post should help: http://taperssection.com/index.php?topic=49027.msg634715#msg634715 unless you are looking for to get to a different end result or do not wish to work below 32bit float temp files...

[Ray76]

anyone come up with an efficient workflow yet??

second half of this post should help: http://taperssection.com/index.php?topic=49027.msg634715#msg634715 unless you are looking for to get to a different end result or do not wish to work below 32bit float temp files...

noted. thanks Man. +T I dont ever use the 32 bit float setting anyway.

Teddy

[Ray76]

-with temp file set at 24bit, I was able to perform the same processes.  wavelab again did not choke on the 2 gig limit.

-.  I was able to process the file..but cant save it. at least at 24 bit temp. setting. Trying to save now with 16 Bit temp files..So, I cant wrap my brain around this...what is the relation of the "temp" files to the final product...How does the temp file setting affect the file??I guess what Im trying to ask is what purpose do the temp files serve?

[dmonterisi]

ray-

you can't save the 24/96 full set files as a full set.  what you should do is just line up the files in wavelab using the insert audio file function, but don't save it.  then insert track markers while the wavs are open in the active window and run the auto split.  that way you'll get the 24/96 tracks saved individually.  you are essentially working on the 24/96 files without saving them as one long set.  after you save the 24/96 individual tracks, you can process down to 44.1 and then dither to 16bit and save directly as a new file.  this will save the entire thing as one long 16/44 track.  unfortunately, you cannot save the 24/96 material as one long set if it is over an hour.  does this help?

[Ray76]

ray-

you can't save the 24/96 full set files as a full set.  what you should do is just line up the files in wavelab using the insert audio file function, but don't save it.  then insert track markers while the wavs are open in the active window and run the auto split.  that way you'll get the 24/96 tracks saved individually.  you are essentially working on the 24/96 files without saving them as one long set.  after you save the 24/96 individual tracks, you can process down to 44.1 and then dither to 16bit and save directly as a new file.  this will save the entire thing as one long 16/44 track.  unfortunately, you cannot save the 24/96 material as one long set if it is over an hour.  does this help?

Yes It does, Damon, I appreciate it.  I was misreading earlier comments..I took it that if the temp file settings were lower that you could indeed save the entire thing..but that only applied to processing I guess. Thanks man. Again. +T

[dmonterisi]

no problem...it's a good workaround, but it's not perfect.

[Ray76]

Now I just have to figure out how to get the 7th show off the 744t. 

One more thing though..Do you do fade in and out or just one??

Teddy

[dmonterisi]

what i do is chop off the from the beginning and end what i don't want and then highlight the first two seconds and fade that in.  then highight the last 2 seconds and fade that out.

[Ray76]

what i do is chop off the from the beginning and end what i don't want and then highlight the first two seconds and fade that in.  then highight the last 2 seconds and fade that out.

you mean from the entire show..not track to track im assuming.?? Just curious, have a wilco show that had fades on all the tracks.

[dmonterisi]

yeah, i don't fade the tracks, just the beginning and end of each set.  i hate when i get shows with unnecessary fades.

[Ray76]

yeah, i don't fade the tracks, just the beginning and end of each set.  i hate when i get shows with unnecessary fades.

Thats what I thought. Preciate it.

[nickgregory]

alright this thread gave me a headache...mainly because I realize I have to change my workflow....thanks Damon for doing the testing...

I think Boswell said it best...with this 24 bit crap I feel like I am newb taper with his first DAT all over again

[nickgregory]

Alright, tried laying the tracks out in wavelab, dont like the interface as well as CDWAV for putting track marks out.  So I am thinking my process should be as follows:

24 bit
- Open first 24 bit file in CDWAV and track out
- Save tracks as "alternate 24 bit format"
- Save Cuesheet
- Repeat process for additonal 24 bit files (until show is complete)
- Take split files, join them in wavelab and save
- Add fade in/out to beg/end of show in wavelab
- Burn 24 bit DVD
- Flac 24 bit files

16 bit
- Open first 24 bit file (raw file from 722) in Wavelab and dither/resample
- Repeat processs for additional 24 bit files (until show is complete)
- Open resampled/dithered files in CDWAV and open the saved cuesheet (which should put the track marks at the same point in the file as the 24 bit copy)
- Save files
- Repeat process for additional 16/44.1 chunks until show is complete
- Take split files, join them in Wavelab and save
- Burn 16/44 CD
- FLAC 16 bit files

Now if I am correct in my process, this will yield no sector boundary issues....

will run it through tonight for my moe opening set from ABB and report back...

[scb]

see spark on the mac makes it so easy:

1. open all 24 bit files from 722/other recorder
2. create new 24 bit file and paste the other ones in, since it can handle files larger than 2 gigs
3. place track markers
4. export 24 bit tracks
5. resample 1 big file
6. export resampled tracks

now i don't mean to say pc's suck in this thread, but damn, windows needs an app that uses a larger file format like spark's wav64.  no nick, i'm not gonna write it

though i may write a simple app for mac/windows that'll join any kind of pcm data into 1 file.  shntool only joins 16/44.1.  it'd be nice to have a util that'll join something like 24/96 files

[nickgregory]

though i may write a simple app for mac/windows that'll join any kind of pcm data into 1 file.  shntool only joins 16/44.1.  it'd be nice to have a util that'll join something like 24/96 files

sounds great, let me know when you have it in place and I would be happy to help test

[MattD]

What error do you get when you try to use shntool to join 24/96 files? I have the source open now and am looking at the process_files_join routine.

[scb]

i hadn't tried.  but i got a PM a little while back from someone asking why xACT didn't join 24/96 files.  i'm assuming shntool doesn't, since xACT just calls shntool

[Rick]

16 bit
- Open first 24 bit file (raw file from 722) in Wavelab and dither/resample
- Repeat processs for additional 24 bit files (until show is complete)

Why not Join all the wavs 1st then dither/resample? If you do File > New > Wav and then Edit > Insert Audio Files you won't have a problem with file sizes. Then I track it in CDWave

[nickgregory]

16 bit
- Open first 24 bit file (raw file from 722) in Wavelab and dither/resample
- Repeat processs for additional 24 bit files (until show is complete)

Why not Join all the wavs 1st then dither/resample? If you do File > New > Wav and then Edit > Insert Audio Files you won't have a problem with file sizes. Then I track it in CDWave

the thing I lose there is that my saved "cue" file where I tracked out the 24 bit file will not work...

[mhibbs]

Alright, tried laying the tracks out in wavelab, dont like the interface as well as CDWAV for putting track marks out.  So I am thinking my process should be as follows:

24 bit
- Open first 24 bit file in CDWAV and track out
- Save tracks as "alternate 24 bit format"
- Save Cuesheet
- Repeat process for additonal 24 bit files (until show is complete)
- Take split files, join them in wavelab and save
- Add fade in/out to beg/end of show in wavelab
- Burn 24 bit DVD
- Flac 24 bit files

16 bit
- Open first 24 bit file (raw file from 722) in Wavelab and dither/resample
- Repeat processs for additional 24 bit files (until show is complete)
- Open resampled/dithered files in CDWAV and open the saved cuesheet (which should put the track marks at the same point in the file as the 24 bit copy)
- Save files
- Repeat process for additional 16/44.1 chunks until show is complete
- Take split files, join them in Wavelab and save
- Burn 16/44 CD
- FLAC 16 bit files

Now if I am correct in my process, this will yield no sector boundary issues....

will run it through tonight for my moe opening set from ABB and report back...

So Nick, did it work like you expected???

[nickgregory]

Alright, tried laying the tracks out in wavelab, dont like the interface as well as CDWAV for putting track marks out.  So I am thinking my process should be as follows:

24 bit
- Open first 24 bit file in CDWAV and track out
- Save tracks as "alternate 24 bit format"
- Save Cuesheet
- Repeat process for additonal 24 bit files (until show is complete)
- Take split files, join them in wavelab and save
- Add fade in/out to beg/end of show in wavelab
- Burn 24 bit DVD
- Flac 24 bit files

16 bit
- Open first 24 bit file (raw file from 722) in Wavelab and dither/resample
- Repeat processs for additional 24 bit files (until show is complete)
- Open resampled/dithered files in CDWAV and open the saved cuesheet (which should put the track marks at the same point in the file as the 24 bit copy)
- Save files
- Repeat process for additional 16/44.1 chunks until show is complete
- Take split files, join them in Wavelab and save
- Burn 16/44 CD
- FLAC 16 bit files

Now if I am correct in my process, this will yield no sector boundary issues....

will run it through tonight for my moe opening set from ABB and report back...

So Nick, did it work like you expected???

yup, no SBEs and relatively easy process to work through...

[mhibbs]

Cool...I'll try that then.  Interestingly it seems that Wavelab creates a SBE on every file it saves...at least that's been my experience.  Is there a way to fix that?

[Cooker]

Mitch, maybe drop a CD start marker at the beginning of the file and a CD stop marker at the end, then do an auto-split.

[mhibbs]

Well, being the geek that I also am, I came home and ran some similar tests.  I'll only explain the one I found most interesting, which I think throws a bit of a kink in Damon's findings.  Here's what I did.

1.  took a 24/96 source file (source.wav)
2.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test1.wav)
3.  closed everything, then re-opened source.wav
4.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test2.wav)
5.  opened dith_test1.wav and dith_test2.wav in Wavelab and used Analysis>Audio File Comparer to compare
RESULT:  The two files are identical. 
NEXT>>
6.  opened dith_test1.wav in Wavelab and resampled to 44.1 and "save as new file" called it (dith_resamp_test1.wav)
7.  opened dith_test2.wav in Wavelab and resampled to 44.1 and "save as new file" called it (dith_resamp_test2.wav)
8.  opened dith_resamp_test1.wav and dith_resamp_test2.wav in Wavelab and used Analysis>Audio File Comparer to compare
RESULT:  The two files are NOT IDENTICAL

From what I can tell, Wavelab does not identically resample the same file.  Every time you run it against a source file, save as a new file, then compare the outputs, you'll find differences.  The fact that this is the case makes it impossible to do a comparison where resampling is involved.

Moving on to a batch dither comparison on it's own.

1.  took track1.wav and track2.wav (24/96 tracks) and combined them in Wavelab and called it combine.wav
2.  dithered combine.wav in Wavelab using uv22hr and "save as new file" and called it combine_dith.wav
3.  used Wavelab batch process and uv22hr to dither track1.wav and track2.wav and "save as new file" and called them track1_dith.wav and track2_dith.wav
4.  used Wavelab to combine track1_dith.wav and track2_dith.wav and saved the new file calling it separate_dith.wav
5.  opened combine_dith.wav and separate_dith.wav in Wavelab and used Analysis>Audio File Comparer to compare
RESULT:  The two files are NOT IDENTICAL

Hmm.  Seems that applying the uv22hr dither algorithm to one big file vs. two small files does yeild different results when the two files are combined.  I had the Wavelab compare process create a delta file with markers.  Visually, it appears to be a flat line.  Listening to it yeilds dead silence.  Viewing it on the FFT meter shows noise at aprox -140db across the frequency range. 

What does this tell us?  Somethign to debate, but my inital thoughts are simply that the complicated math problem that is dither doesn't yeild identical results when the source files are different...which they fundamentally are (in a bits and bytes sort of way) in this situation.  To me, the more I think about it, that seems to make some logical sense.  Does it really matter or mean anything?  I could argue not, b/c there really is no basis for comparison.  Whether you do it in batch or as one file, you are processing the file and altering it resulting in a file that IS different from the 24/96 source.  True, they are different relative to each other, but both are different relative to the original source.

Moving on to the issue w/ the .wav not lining up when combined.  Personally I don't see it...mine appear to join fine when viewed at the smallest zoom possible in Wavelab.  Am I missing something here?  I very well may not know what I'm looking for.

And finally, the SBEs.  I didn't have to test it, b/c I know it to be true.  24/96 files dithered and resampled result in files w/ SBE's.  HOWEVER, I believe the issue resides in Wavelab itself, NOT the fact that this processing is done in batch.  In my experience, every 16/44.1 file saved in Wavelab has a SBE b/c by default Wavelab doesn't save the file on a CD defined sector boundry.  CDWav does, which is why we all use it to cut tracks.  As a result, the comparison we're talking about relative to SBEs is really a comparison of how Wavelab and CDWav save 16/44.1 files.  True, they are different, and Wavelab does screw it up.  I got an interesting PM about how to address this issue...

---------
markers.....make sure you do CD track start, CD Track splice markers(for the individual tracks) and cd track end...make sure you check "quantize to CD Frame" THEN do an autosplit.no more SBEs!

Teddy
---------

Doesn't seem possible to work Teddy's process into this since the files are already split.  The only way to really address the SBEs is w/ shntool fix.  It's essentially the same thing though, since it just adjusts the split relative to the next file from the first SBE to the last and pads the final file. 

So there you have it.  Feel free to shoot holes in my theory/testing, but it appears to me this is 6 one way, 1/2 a dozen the other unless there is more to the wavs not lining up when re-joined.  Which I agree in theory certainly seems possible if the dither/resample process alters the end of the first wav and the beginning of the second wav differently.  Any difference would seem to be way down at -140db and not audible.  But again, I didn't see it, and would love to see a pic of an example if Damon or someone else can grab one. 

Finally, and I'll shut up now.  After all of this, I would agree that the process Nick outlined makes the most sense and seems the "safest" and that is what I'll be doing from now on although I find this all very interesting from a  purely "academic" perspective.


Damon, guess we can be dork buddies.



mitch

[MattD]

1.  took a 24/96 source file (source.wav)
2.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test1.wav)
3.  closed everything, then re-opened source.wav
4.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test2.wav)
5.  opened dith_test1.wav and dith_test2.wav in Wavelab and used Analysis>Audio File Comparer to compare
RESULT:  The two files are identical. 

This result is surprising to me. Dithering should add random or shaped random noise to the audio (I know, pseudo-random in this case), and should be practically impossible to duplicate.

[Brian Skalinder]

1.  took a 24/96 source file (source.wav)
2.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test1.wav)
3.  closed everything, then re-opened source.wav
4.  dithered source.wav using Wavelab uv22hr and "save as new file" called it (dith_test2.wav)
5.  opened dith_test1.wav and dith_test2.wav in Wavelab and used Analysis>Audio File Comparer to compare
RESULT:  The two files are identical.

This result is surprising to me. Dithering should add random or shaped random noise to the audio (I know, pseudo-random in this case), and should be practically impossible to duplicate.

Likewise.  I performed a similar test with a couple different apps and dither/noise shaping algos:

Master File Format    :  24-bit, 44.1 kHz master file
Target File Format    :  16-bit, 44.1 kHz (no resample)
Application           :  Wavelab 5.00a (WL)
Application           :  Adobe Audition 1.5 (AA)
Application           :  Exact Audio Copy 0.95pb4 Wave Compare (EAC)
Dither / Noise Shaping:  AA Internal
Dither / Noise Shaping:  WL Internal
Dither / Noise Shaping:  WL UV22HR
Dither / Noise Shaping:  iZotope Ozone 3 MBIT+ (in both AA and WL)
Dither / Noise Shaping:  Steinberg Waves L2/IDR (in both AA and WL, *no* compresson - only dither/ns)

For each app/dither/noise shaping combination, I generated two separate 16-bit / 44.1 kHz target files from the same master file, and then compared those two target files against one another with EAC.. 

===============================
APP - DITHER - NS | RESULT
===============================
WL  - UV22HR - NA | IDENTICAL
WL  - L2/IDR - Y  | DIFFERENT
WL  - MBIT+  - Y  | DIFFERENT
WL  - INTERN - Y  | IDENTICAL
WL  - L2/IDR - N  | DIFFERENT
WL  - MBIT+  - N  | DIFFERENT
WL  - INTERN - N  | IDENTICAL
-------------------------------
AA  - L2/IDR - Y  | IDENTICAL
AA  - MBIT+  - Y  | DIFFERENT
AA  - INTERN - Y  | DIFFERENT
AA  - L2/IDR - N  | IDENTICAL
AA  - MBIT+  - N  | DIFFERENT
AA  - INTERN - N  | DIFFERENT

NOTES

[1]  The results suggest to me that the pseudo-random algos in UV22HR and WL Internal dither are not very, well...random.  Does it matter?  Dunno.

[2]  Why the very same Waves L2/IDR dither and noise shaping plug-in generates different files in Wavelab (suggesting a pseudo-random algo) and not in Adobe Audition (suggesting a non-pseudo random algo) has me stumped.  I haven't the foggiest idea what to make of this one.

[3]  Note that while the target files generated using Adobe Audition using L2/IDR *without* noise shaping are identical to one another, these target files are NOT identical to the files generated with the same application / plugin *with* noise shaping.

[F.O.Bean]

ok, since reading this, ive been taping for many years and have never used cue sheets, what the hell are they and what do they do? and how do you make them in cdwave

[F.O.Bean]

ok, since reading this, ive been taping for many years and have never used cue sheets, what the hell are they and what do they do? and how do you make them in cdwave

[Brian Skalinder]

and how do you make them [ cute sheets] in cdwave

File | Save Cue Sheet

[F.O.Bean]

and how do you make them [ cute sheets] in cdwave

File | Save Cue Sheet

do you do this before or after you save your tracks? and how is the cue sheet useful?

[Brian Skalinder]

do you do this before or after you save your tracks? and how is the cue sheet useful?

Either before, or after.  I save the cue sheet so if I realize after saving the files and closing CD-Wave that I've flubbed the tracking somehow, I can simply open up the file again, load the cue sheet, and make my adjustment.  Also, I save the cue sheet with my raw master so if I need to re-track in the future for any reason I can do so easily.

Edit to add:  It also allows me to track a single time for 24- and 16-bit.  Create cue sheet in 24-bit, then when tracking the 16-bit I just open up the cue sheet.

[F.O.Bean]

do you do this before or after you save your tracks? and how is the cue sheet useful?

Either before, or after.  I save the cue sheet so if I realize after saving the files and closing CD-Wave that I've flubbed the tracking somehow, I can simply open up the file again, load the cue sheet, and make my adjustment.  Also, I save the cue sheet with my raw master so if I need to re-track in the future for any reason I can do so easily.

Edit to add:  It also allows me to track a single time for 24- and 16-bit.  Create cue sheet in 24-bit, then when tracking the 16-bit I just open up the cue sheet.

so when you go to open a cue sheet, do you have to open the whole wav to or just the cue sheet im trying it right now FWIW

[F.O.Bean]

ok, so you can open just the cue sheet, now my next question is: once all my 24-bit tracks are track-marked, i save the cue sheet per set or per disc what do ya'll do?

oh and thanks brian, this was always a clueless subject for me since i always just did 16-bit

[Brian Skalinder]

so when you go to open a cue sheet, do you have to open the whole wav to or just the cue sheet im trying it right now FWIW

CD-Wave associates the cue sheet with a WAV file.  So if you open the cue sheet, CD-Wave will ask if you want to open the associated WAV file.  But you can also load a cue sheet into a WAV file other than the one with which it is associated.  I do the latter.  For example:

[01]  Open 24-bit WAV file
[02]  Track
[03]  Save 24-bit tracks
[04]  Save cue sheet (this sheet is now associated with the 24-bit file)
[05]  Dither 24-bit file in other editor to 16-bit and save 16-bit WAV file
[06]  Open 16-bit WAV in CD-Wave
[07]  Load cue sheet
[08]  Click "No" when CD-Wave asks if I want to open the associated 24-bit WAV file
[09]  Save 16-bit tracks

i save the cue sheet per set or per disc what do ya'll do?

I do the above for a recording that fits on a single 16-bit CD.  If it's longer than a single CD, I do [01-08] and then:

[09]  Rename the tracks from Txx to D1Txx and D2Txx such that all the D1 tracks fit on a single disc, same for the D2, etc.
[10]  Save 16-bit tracks
[11]  Save separate 16-bit cue sheet

[F.O.Bean]

so when you go to open a cue sheet, do you have to open the whole wav to or just the cue sheet im trying it right now FWIW

CD-Wave associates the cue sheet with a WAV file.  So if you open the cue sheet, CD-Wave will ask if you want to open the associated WAV file.  But you can also load a cue sheet into a WAV file other than the one with which it is associated.  I do the latter.  For example:

[01]  Open 24-bit WAV file
[02]  Track
[03]  Save 24-bit tracks
[04]  Save cue sheet (this sheet is now associated with the 24-bit file)
[05]  Dither 24-bit file in other editor to 16-bit and save 16-bit WAV file
[06]  Open 16-bit WAV in CD-Wave
[07]  Load cue sheet
[08]  Click "No" when CD-Wave asks if I want to open the associated 24-bit WAV file
[09]  Save 16-bit tracks

i save the cue sheet per set or per disc what do ya'll do?

I do the above for a recording that fits on a single 16-bit CD.  If it's longer than a single CD, I do [01-08] and then:

[09]  Rename the tracks from Txx to D1Txx and D2Txx such that all the D1 tracks fit on a single disc, same for the D2, etc.
[10]  Save 16-bit tracks
[11]  Save separate 16-bit cue sheet

+T Brian, thanks alot

i have one more question tho, since all of this batch-processing stuff came to light, shouldnt i resample/dither the master wavs to 16-bit THEN load the 16-bit files into cdwave, cut into tracks, save cue sheet, THEN re-open the master 24/96 files and use the cue sheet on them that way  then i could rename everything accordingly

does that make sense

this is all new and confusing to me, im sure after a few more shows i'll have it down like butta

[Brian Skalinder]

i have one more question tho, since all of this batch-processing stuff came to light, shouldnt i resample/dither the master wavs to 16-bit THEN load the 16-bit files into cdwave, cut into tracks, save cue sheet, THEN re-open the master 24/96 files and use the cue sheet on them that way  then i could rename everything accordingly

does that make sense

I don't follow.  Either way, you're tracking within one file (either 16- or 24-bit) and loading the cue sheet into the other.  I don't follow why it would matter whether you do 24-bit first, then 16-bit, or vice versa.

[F.O.Bean]

i have one more question tho, since all of this batch-processing stuff came to light, shouldnt i resample/dither the master wavs to 16-bit THEN load the 16-bit files into cdwave, cut into tracks, save cue sheet, THEN re-open the master 24/96 files and use the cue sheet on them that way  then i could rename everything accordingly

does that make sense

I don't follow.  Either way, you're tracking within one file (either 16- or 24-bit) and loading the cue sheet into the other.  I don't follow why it would matter whether you do 24-bit first, then 16-bit, or vice versa.

i gotcha now, it finally registered thanks alot brian, you da man

[Brian Skalinder]

i gotcha now, it finally registered thanks alot brian, you da man

Though I will add:  if you do the 16-bit tracking first (filenames d1txx, d2txx, etc.) and don't mind having your 24-bit files using those same names, then you'll save the renaming step [09].  I'm picky about my filenames - want my 24-bit one way, the 16-bit another...hence why I rename.

[F.O.Bean]

i gotcha now, it finally registered thanks alot brian, you da man

Though I will add:  if you do the 16-bit tracking first (filenames d1txx, d2txx, etc.) and don't mind having your 24-bit files using those same names, then you'll save the renaming step [09].  I'm picky about my filenames - want my 24-bit one way, the 16-bit another...hence why I rename.

i would liek them to be named differently as well, i have been naming them this way:

24-bit: moe2006-06-11_2496_t01
          moe2006-06-11_2496_t02

and 16-bit: moe2006-06-11.481.d1t01
                moe2006-06-11.481.d1t02

oh and FWIW, i rename everything in CKRename anyway so.... as long as i have a master cue sheet, that wont alter or affect anything right? say i have a 24-bit cuesheet for my 24-bit files, after the tracks are saved and my cue sheet is saved, i simply:

A. open the 16-bit file, and track out per set OR
B. open the 24-bit cue sheet and resave 

this is where im getting lost

[F.O.Bean]

actually, i think i got it brian, i just need a show to try it out on

[F.O.Bean]

ok so, when i try to load the first 2496 wav in wavelab and then edit>insert at end, when i try to save both files w/ 24-bit temp files, it chokes and gives me the 'file is larger than 2GB' error and stops saving both files as one long files

so my question is: if i switch to 16-bit temp files, are my files being downgraded when i save the 2496 files w/ 16-bit temp files or does that really matter

i think i can save both files as one if i use the 16-bit temp files thing, but i dont want my 2496 files downgraded at ALL, i want the 2496 quality i would love to use 24-bit or 32-bit temp files but......

i would think it woulnt matter if i used 16-bit temp files simply because no editing is really being done to the files but i want to make sure

damn i need to upgrade my 5.01b and shell out the $$ for wavelab 6.0 w/ the 4GB limit

thanks,
Bean

[F.O.Bean]

nope, it even choked on saving both 2496 files when i changed to 16-bit temp files

WTF how can i edit these shows unless i have wavelab 6.0

[dmonterisi]

Bean-

sorry if i wasn't clear.  you cannot save the 2 24/96 files as one big 24/96 files, but you should be able to resample/dither them into 1 file and then separately chop up the 24/96 files into individual files. 

with your temp file at 24bit, open up both 24/96 files in the active window (open the first, then insert audio file > at end).  with both in place, convert the sample rate to 44.1.  it shouldn't choke.  then dither, and choose "save to new file" option in the dither dialog.  that should save you one full set at 16/44 for the entire set together.  then just go back and undo the convert sample rate and you'll be back with your 24/96 files in the active window.  then start dropping markers where you want to do the 24/96 track breaks.  then use the tools>auto split function to save individual 24/96 tracks.

this should work.

[F.O.Bean]

Bean-

sorry if i wasn't clear.  you cannot save the 2 24/96 files as one big 24/96 files, but you should be able to resample/dither them into 1 file and then separately chop up the 24/96 files into individual files. 

with your temp file at 24bit, open up both 24/96 files in the active window (open the first, then insert audio file > at end).  with both in place, convert the sample rate to 44.1.  it shouldn't choke.  then dither, and choose "save to new file" option in the dither dialog.  that should save you one full set at 16/44 for the entire set together.  then just go back and undo the convert sample rate and you'll be back with your 24/96 files in the active window.  then start dropping markers where you want to do the 24/96 track breaks.  then use the tools>auto split function to save individual 24/96 tracks.

this should work.

thanks damon, HUGE +T

i am prolly gonna do the open>edit>insert at end w/ the 2496 files, then resample/dither those files, save the whole set/files at 16/44.1, track the 16/44 files and keep a cue sheet for the 16/44 files, and use them on the 2496 files wqould that work? actually it wont unless i have the whole 2496 files per set huh? i am new to the cue sheet thing, but after a few more 2496 shows, i should have it down

[dmonterisi]

don't think the cue sheet thing will work in wavelab...i don't think you can load cue sheets, but maybe i'm wroing and there's a way to import a cue sheet as wav markers, it would make things nice and easy.

[F.O.Bean]

Bean-

sorry if i wasn't clear.  you cannot save the 2 24/96 files as one big 24/96 files, but you should be able to resample/dither them into 1 file and then separately chop up the 24/96 files into individual files. 

with your temp file at 24bit, open up both 24/96 files in the active window (open the first, then insert audio file > at end).  with both in place, convert the sample rate to 44.1.  it shouldn't choke.  then dither, and choose "save to new file" option in the dither dialog.  that should save you one full set at 16/44 for the entire set together.  then just go back and undo the convert sample rate and you'll be back with your 24/96 files in the active window.  then start dropping markers where you want to do the 24/96 track breaks.  then use the tools>auto split function to save individual 24/96 tracks.

this should work.

couple questions damon, first: if i drop markers in wavelab wont there be SBE's actually, SBE's are only in 16/44 files huh?

secondly: if i drop markers in wavelab and then go to auto split function, if its an auto split, wont the split be where wavelab wants them every certain number of MB's does that make sense

couldnt i cut the 2496 files in cdwave FIRST, save the cue sheet, then resample/dither the WHOLE 2496 files that the 722 split to like you said to do w/ the open wav>edit>insert at end 16/44, open the 16/44 files in cdwave and use the cue sheet from the 2496 files that way id have my 2496 files split and tracked and saved/flac'd, i could save my 2 files per set and md5 my original 2496 files that the 722 split, theyd still be split exactly as they were from the 722 and then id have:

1. original wavs that the 722 split(burn them as data w/ an md5)
2. tracked/flac'd 2496 files
3. resampled/dither/flac'd 1644 files

thats w/ opening 2496 files in cdwave and splitting/saving cue sheet, that way my 2496 files are split and ready to flac, then open original 722 split files in wavelab, resample/dither to 16/44, use cue sheet from 2496 files i tracked in cdwave, save the 1644 files w/ the cue sheet from the 2496 ones, and that way like i said, id have the :

1. burn original 2496 wavs as data before i do an editing, id just rename them as moe2006-06-09_2496_1a, moe2006-06-09_2496_1b for thats et
2. track 2496 files in cdwave, only after i rejoin where the original cut was on the 722 in wavelab so that that track is now one file instead of being two where the 722 split them
3. resample/dither to 16/44 and use the cue sheet from the 2496 files and SAVE
4. FLAC the tracked 24/96 and 16/44 files

DONE

does that make sense or is that jibberish

eitehr way, thanks for your help damon/brian

i need to just shell the $$ out for wavelb 6.0 upgrade from 5.0 and id never have to worry about the stupid 2GB limit ever again

does samplitude have this limit i have samplitude 6.0 master FWIW

[F.O.Bean]

don't think the cue sheet thing will work in wavelab...i don't think you can load cue sheets, but maybe i'm wroing and there's a way to import a cue sheet as wav markers, it would make things nice and easy.

no, sorry i wasnt clear enuf, i would use the cue sheet in cdwave

[dmonterisi]

couple questions damon, first: if i drop markers in wavelab wont there be SBE's actually, SBE's are only in 16/44 files huh?

yeah, no sbe worries, they are only issues for 16/44 files.

secondly: if i drop markers in wavelab and then go to auto split function, if its an auto split, wont the split be where wavelab wants them every certain number of MB's does that make sense

no you go through in wavelab and drop markers first, and the use auto split and split on the markers.  in fact, you can use this as a way to split the 16/44 files in wavelab because there is a "cd audio" marker that you can drop where it will seek out 16/44 boundaries without sbe's.  i'm pretty sure (but not positive since i haven't tried it) that you can drop these kind of markers in a 24/96 file, split them as 24/96 files, then go back after its dithered/resampled and they'll still be there to split the files into individual 16/44 files.

couldnt i cut the 2496 files in cdwave FIRST, save the cue sheet, then resample/dither the WHOLE 2496 files that the 722 split to like you said to do w/ the open wav>edit>insert at end 16/44, open the 16/44 files in cdwave and use the cue sheet from the 2496 files that way id have my 2496 files split and tracked and saved/flac'd, i could save my 2 files per set and md5 my original 2496 files that the 722 split, theyd still be split exactly as they were from the 722 and then id have:

1. original wavs that the 722 split(burn them as data w/ an md5)
2. tracked/flac'd 2496 files
3. resampled/dither/flac'd 1644 files

thats w/ opening 2496 files in cdwave and splitting/saving cue sheet, that way my 2496 files are split and ready to flac, then open original 722 split files in wavelab, resample/dither to 16/44, use cue sheet from 2496 files i tracked in cdwave, save the 1644 files w/ the cue sheet from the 2496 ones, and that way like i said, id have the :

1. burn original 2496 wavs as data before i do an editing, id just rename them as moe2006-06-09_2496_1a, moe2006-06-09_2496_1b for thats et
2. track 2496 files in cdwave, only after i rejoin where the original cut was on the 722 in wavelab so that that track is now one file instead of being two where the 722 split them
3. resample/dither to 16/44 and use the cue sheet from the 2496 files and SAVE
4. FLAC the tracked 24/96 and 16/44 files

i think the problem with this is that since you can't open the 2 files back to back in cdwav, you won't be splitting all the 24/96 files, only the first 2 gig chunk.  then the last portion of the first 24/96 file wouldn't be split properly along with the second 24/96 file and the cue sheet would only be for a portion of the set.

DONE

does that make sense or is that jibberish

eitehr way, thanks for your help damon/brian

i need to just shell the $$ out for wavelb 6.0 upgrade from 5.0 and id never have to worry about the stupid 2GB limit ever again

does samplitude have this limit i have samplitude 6.0 master FWIW

once you get used to the workflow it's not that difficult...don't know how much wavelab 6 costs, but you could probably use that money for other things. 

[F.O.Bean]

couldnt i cut the 2496 files in cdwave FIRST, save the cue sheet, then resample/dither the WHOLE 2496 files that the 722 split to like you said to do w/ the open wav>edit>insert at end 16/44, open the 16/44 files in cdwave and use the cue sheet from the 2496 files that way id have my 2496 files split and tracked and saved/flac'd, i could save my 2 files per set and md5 my original 2496 files that the 722 split, theyd still be split exactly as they were from the 722 and then id have:

1. original wavs that the 722 split(burn them as data w/ an md5)
2. tracked/flac'd 2496 files
3. resampled/dither/flac'd 1644 files

thats w/ opening 2496 files in cdwave and splitting/saving cue sheet, that way my 2496 files are split and ready to flac, then open original 722 split files in wavelab, resample/dither to 16/44, use cue sheet from 2496 files i tracked in cdwave, save the 1644 files w/ the cue sheet from the 2496 ones, and that way like i said, id have the :

1. burn original 2496 wavs as data before i do an editing, id just rename them as moe2006-06-09_2496_1a, moe2006-06-09_2496_1b for thats et
2. track 2496 files in cdwave, only after i rejoin where the original cut was on the 722 in wavelab so that that track is now one file instead of being two where the 722 split them
3. resample/dither to 16/44 and use the cue sheet from the 2496 files and SAVE
4. FLAC the tracked 24/96 and 16/44 files

i think the problem with this is that since you can't open the 2 files back to back in cdwav, you won't be splitting all the 24/96 files, only the first 2 gig chunk.  then the last portion of the first 24/96 file wouldn't be split properly along with the second 24/96 file and the cue sheet would only be for a portion of the set.

well, id split the first 2496 wav in cdwave, then split the second 2496 2GB chunk in cdwave, rejoin the one track thats split into two files w/ the edit>insert at end in wavelab, resave the two tracks into one, then the 2496 set/tracks would be joined 100% seamlessly, right? that way my cue sheet would/should match up w/ my 1644 files, correct? id have my 2496 files saved/tracked/flac'd, then id just open origianl 722 cut wavs in wavelab and resample/dither/resave and use the cue sheet on the 16/441 files my cue sheets wouldnt line up if i did it this way because id have to open ALL of my tracked 2496 files once rejoined in wavelab and save the FINAL tracked 2496 files in cdwave and save that cue sheet, huh? damn this is getting confusing i gues sthe only way to figure this out is to try it can you open multiple files in cdwave and make a cue sheet? like once i tracked in cdwave, rejoined the one track thats two files in wavelab, save as a single file, then id have to reopn that in cdwave and resave for the cue sheet huh? anyway, now im just ramblng nonsense, im gonna play around w/ my 6/9 moe show and see what works for me tomorrow

am i making any sense? this is all so new to me....... i dont really wanna drop markers in wavelab but i will if its easier, i just wanna find a way to utilize cue sheets for a quicker/easier tracking setup and that way the markers/tracks would be EXACTLY the same in the 2496 AND the 1644 tracks

but really, i dont care if i have to track the 2496 and the 1644 files seperately w/ out a cue sheet, it would be nice tho and theyre not EXACTLY tracked the same, as long as the batch processing isnt done and the wavs arent altered like they are when batch processing, im a happoy 24-bit taper

FWIW tho, the two shows i did batch processing on, i heard no audible/weird clicks or pops inbetween track breaks but im a purist and wanna do thinsg correctly the first time

Bean

[RebelRebel]

if you drop "cd markers" the "quantitize to cd frame" option HAS to be checked to not get SBEs.