Topic: Tracking with Cool Edit Pro 2.0

[mattmiller]

I'm tracking out a show using my normal method, which is to use F8 to insert cues in CEP 2.0, merge the cue list, and then batch save the cue list.  I just noticed that a few of the "tracks" are adopting slightly different starting points from the previous cue's end point.  See attached screencap, with color-coding pointing to the anomalies.  Why is it doing this?  All the other cues seem to be fine, and I'm sure they were placed properly with "snap to ruler (fine)" turned on.

[flipp]

since CD time is HH:MM:SS:ff with ff being frames and there are 75 frames per second; if one file ends at HH:MM:SS:74, the next file would start at the next frame which would be HH:MM:S(S+1):00

since the only splits you have problems with all end at the 74th frame, the next file would start at S(S+1):00

all looks good; if you're worried, save the file then run it through trader'slittlehelper and check for sector boundary errors - you shouldn't find any

[mattmiller]

But why don't the others start one frame after the previous track ends?

[flipp]

that I haven't a clue about - just guessing it may have something to do with the way CEP is written and how it recognizes frames

if traderslittlehelper or another program that checks for sector boundary errors indicates a problem then I would worry about it; otherwise, if no SBEs indicated write it off as a programming quirk of CEP

[mattmiller]

TLH claims to have generated "fixed" versions of ALL of the files.  Does that necessarily mean that they contained SBEs?  I'm skeptical, because the cues were placed on 1/75th second frames, and TLH doesn't say anything about checking for SBEs.  It behaved almost like it's programmed just to automatically make a new set of files that are SBE-free regardless of whether the original files needed to be fixed.

[flipp]

Try opening your original cue sheet in CDWave or Feurio. IIRC one of the more recent versions of CDW can tell you if there are SB problems and Feurio can open cue sheets and indicate in the lower right window (forget what it's called as I haven't used anything but Samplitude in Windows for a long time) if there are any SB anomalies.

[mattmiller]

Does it matter that I tracked the show at 24/48, generated the split files, and THEN batch-processed the resampling/dithering of the files to 16/44.1?  These resulting 16/44.1 files are the ones which were fed into TLH and apparently had to "fixed".

[mattmiller]

Anyone?

I'm starting to wonder if I'm not doing things in the smartest way possible.  My goal with every recording (made at 24/48) is to produce:

1.  A set of 24/48 WAV files
2.  A set of 16/44.1 WAV files
3.  A set of 16/44.1 FLAC files

To achieve this, I'm doing the following:

1.  Opening the raw 24/48 WAV file in Cool Edit Pro 2.0
2.  Making all edits (normalize, fade in beginning, fade out end, and usually nothing else)
3.  Insert cues (snapped to the ruler) at my desired track boundaries
4.  Merge the cues (the screenshot above is after merging them)
5.  Batch saving the cues (which gives me my 24/48 WAV files)
6.  File > Batch File Convert -- to produce my set of 16/44.1 WAV files from the individual 24/48 files
7.  16/44.1 FLAC file creation with TLH

So I'm still trying to figure out why the merged cues look the way they do (i.e., most of the tracks begin at the exact same frame that the previous track ends, but a few do not).  And why are my 16/44.1 WAV files needing to be fixed by TLH for SBEs?  Should I be dithering and resampling to 16/44.1 before tracking it?

[junkyardt]

surely this will not be the answer you're looking for, but i'd never even considered tracking in CEP. i always do the work i want to do in CEP or Vegas, save as one big file, then do tracking separately in CD Wave, and i've never had a problem.

[mattmiller]

CD Wave only works with 16-bit files.

Edit to add that maybe it does work with 24-bit files.  I downloaded it from http://www.etree.org/cdwave.html, which is apparently way out-of-date.  Downloading a newer version now...

[dorrcoq]

It definitely works with 24 bit files.

[mattmiller]

It definitely works with 24 bit files.

Yeah, I've got that working.  But how do I avoid separately tracking the 24-bit and 16-bit versions?  I only want to do it once.

[junkyardt]

It definitely works with 24 bit files.

Yeah, I've got that working.  But how do I avoid separately tracking the 24-bit and 16-bit versions?  I only want to do it once.

if the files are exactly the same except for the 16/24 difference, wouldn't the cue file you save for the 1st one load for the 2nd?

[flipp]

Save the splits as a cue file. Then when you want to burn a disc you only have to change the path the cue points to - either 16 or 24 bit - to get a CD or DVD disc.

[dorrcoq]

Or, instead of dithering and downsampling your big 24 bit file to 16 bit, split it into tracks and then batch process downsample the individual tracks.

[mattmiller]

Or, instead of dithering and downsampling your big 24 bit file to 16 bit, split it into tracks and then batch process downsample the individual tracks.

That's what I've been doing, and how I would like to do it.  But it seems that this is the source of my sector boundary errors.  SHOULD processing them this way introduce SBEs?

[dorrcoq]

Yeah, quite possibly.  I always automatically run them through Traders Little Helper or FLAC Frontend (aligned on sector boundaries) first to make FLAC files, and then if I want the 16 bit WAV files I just decode the FLAC's, which should leave a prefect set of files.