correct for drift in recordings

[dobro]

What do I need to know about this? How reliable is it? Does its reliability depend on the soundcard?

Every time I effect an existing track with an external unit Cool automatically corrects for drift on the new track.

[lpdeluxe]

As I understand it, this function is for sound cards that don't lock onto the incoming word clock. If you use ADAT lightpipe (for example), or have a separate word clock synch cable, you shouldn't need to use it. I use lightpipe and have left the box for "Correct for Drift in Recording" unticked for several years now with no problems.

The manual doesn't say much about it (I am referring to the Adobe Audition 1.5 manual), only "syncronizes the master audio playback (generally, the first Out device listed in the session -- the one on Track 1) and the record device of the waveform being created. If the true sample rates on the cards differ enough that the recording would have drifted out of synch if both were played back at exactly the same sample rate, then the recording is corrected by resampling to make it the proper length. This option only works with new record tracks, not with recording on top of existing waveforms, or punch-ins." A note added below that summarizes my first paragraph.

[dobro]

Yeah, I read that in the help. But like you say, it doesn't seem to say much.

See, I don't trust it. How does Cool know what the latency of my soundcard is?

[lpdeluxe]

I don't think that's what it says: instead it says that CEP can tell what the incoming sample rate (which may or may not be related to the latency) is, and can resample it to match what the recording is set to. Latency is actually a whole set of other issues. I posted my method of determining latency in another forum for you yesterday.

The "Correct for Drift", in other words, does the correcting at the source, rather than trying to calculate how far off it will get. Let's say that your sampling rate is set at 1000 samples/sec (ridiculous, I know, but bear with me) and the incoming rate is 1500 samples/sec. This will throw the new track off 1 second every 2 seconds. The "latency" fix would be to delay the existing track that one second; the CEP "Correct for Drift" would resample the incoming track to 1000 samples/sec and synch it up that way.