Topic: Matrix Time Drift -- How Much Is Too Much

[mattmiller]

I'm processing my first two-recorder matrix recording and am following the procedure outlined for Cool Edit Pro.  Namely, I've converted my time scale into samples, noted the sample numbers of an event at the beginning and end of both sources, subtracted them to get the number of samples between events for each source, and calculated the percentage by which I need to shrink the longer source.  The result:  Over approximately an hour, my two sources (HD-P2 MIC, R-09HR SBD) differ by about 1000 samples, or about 0.02 seconds at 48k per second.  The factor by which I need to multiply the longer (HD-P2) source is 0.99999392265.

1.  Is this even worth correcting?  I haven't tried yet, but maybe a factor can't even be defined to that many decimal places.  And, it seems the error in visually lining up the sources is going to dwarf the error in the two clocks.
2.  Is this likely to be consistent on other recordings using these two units -- i.e., do I need do the math every time?  I believe I've read that once you know your factor, you just apply it every time.

[faninor]

I'm no expert but I've played around with mixing my own two-recorder experiments.

1.
1000 samples seems a rather large amount to be off (so is 500 on either end if you line the recordings up near the middle). I would expect some real bad phasing unless you're applying a low pass filter to one source. If you don't correct it somehow it's probably not worth doing a matrix.

I think you're right that Cool Edit Pro doesn't give you nearly that many decimal places though. I've always been curious myself if, when the drift is just 1000 samples over 1 hour, would it be cleaner to use some tool that would simply remove 1000 of the samples evenly spaced throughout the slower source so that they line up without putting the recording through any complicated processing to interpolate new samples. I wonder if such a tool exists?

Also I've found Sony Vegas to be a very quick and easy tool compared to Cool Edit Pro for getting rid of drift between two sources.

2.
In my experience the amount of drift might vary. At minimum confirm that they really are matching up if you don't redo the math.

[page]

I'm processing my first two-recorder matrix recording and am following the procedure outlined for Cool Edit Pro.  Namely, I've converted my time scale into samples, noted the sample numbers of an event at the beginning and end of both sources, subtracted them to get the number of samples between events for each source, and calculated the percentage by which I need to shrink the longer source.  The result:  Over approximately an hour, my two sources (HD-P2 MIC, R-09HR SBD) differ by about 1000 samples, or about 0.02 seconds at 48k per second.  The factor by which I need to multiply the longer (HD-P2) source is 0.99999392265.

1.  Is this even worth correcting?  I haven't tried yet, but maybe a factor can't even be defined to that many decimal places.  And, it seems the error in visually lining up the sources is going to dwarf the error in the two clocks.
2.  Is this likely to be consistent on other recordings using these two units -- i.e., do I need do the math every time?  I believe I've read that once you know your factor, you just apply it every time.

1) Yes. I've recorded 2 hrs on units before with differences that amount to about that and I could hear a difference in drum beats at the end. Started to notice it around 48 or 49 minutes in that something was strange. Skipped to the end and laughed.

2) Yes, those two specific units should always be off by that amount pending something going wrong with the clock. Replace it with the same model but different physical unit and you get a different time, but those two specific units shouldn't change.

I'm no expert but I've played around with mixing my own two-recorder experiments.

1.
1000 samples seems a rather large amount to be off (so is 500 on either end if you line the recordings up near the middle). I would expect some real bad phasing unless you're applying a low pass filter to one source. If you don't correct it somehow it's probably not worth doing a matrix.

I think you're right that Cool Edit Pro doesn't give you nearly that many decimal places though. I've always been curious myself if, when the drift is just 1000 samples over 1 hour, would it be cleaner to use some tool that would simply remove 1000 of the samples evenly spaced throughout the slower source so that they line up without putting the recording through any complicated processing to interpolate new samples. I wonder if such a tool exists?

I think 1000 samples per hour is average to low. I've seen as much as 10k an hr and as little as about 750. Each units clock is different, which is why syncing during the recording is the best practice if thats an option, baring that, doing the speed math is the next best thing. Audacity handles 7 or 8 decimal places if you have trouble getting CEP to work.

Always do the math. I agree, if you don't correct it, it's not worth doing.

(edit for second reply)

[mattmiller]

I'm doing something backwards here.  Or at least the results are backwards.  Here's my math:

Mic source point A = sample #17,835,732
Mic source point B = sample #189,621,177
Span = 171,785,445 samples

SBD source point A = sample #15,387,235
SBD source point B = sample #187,171,636
Span = 171,784,401 samples

Mic source therefore spans 1,044 more samples and needs to shrink to match the SBD source.  171,784,401 divided by 171,785,445 is 0.99999392265.  So I opened the Mic source in Cool Edit Pro and used Effects > Time/Pitch > Stretch, put in 99.999392265 as the "ratio" (which sounds more like a percentage to me, but its default "ratio" is 100 for "no change").  I made sure to check the Time Stretch (Preserve Pitch) mode and left all the other defaults.  The result is that the file has GROWN in size by approximately the number of samples that I was trying to shrink it.  I think the actual number was in the 1100s, and then when I went back and looked at the settings in the Stretch window it had chopped the "ratio" down to just 99.999 instead of the full 9 decimal places.  I'm assuming that's the source of the difference in the magnitude of the stretch, but why did it expand instead of shrink?  And is 99.999 good enough?  If the end result is that I'm off around 100 samples over an hour is that something to worry about?

[page]

I'm doing something backwards here.  Or at least the results are backwards.  Here's my math:

Mic source point A = sample #17,835,732
Mic source point B = sample #189,621,177
Span = 171,785,445 samples

SBD source point A = sample #15,387,235
SBD source point B = sample #187,171,636
Span = 171,784,401 samples

Mic source therefore spans 1,044 more samples and needs to shrink to match the SBD source.  171,784,401 divided by 171,785,445 is 0.99999392265.  So I opened the Mic source in Cool Edit Pro and used Effects > Time/Pitch > Stretch, put in 99.999392265 as the "ratio" (which sounds more like a percentage to me, but its default "ratio" is 100 for "no change").  I made sure to check the Time Stretch (Preserve Pitch) mode and left all the other defaults.  The result is that the file has GROWN in size by approximately the number of samples that I was trying to shrink it.  I think the actual number was in the 1100s, and then when I went back and looked at the settings in the Stretch window it had chopped the "ratio" down to just 99.999 instead of the full 9 decimal places.  I'm assuming that's the source of the difference in the magnitude of the stretch, but why did it expand instead of shrink?  And is 99.999 good enough?  If the end result is that I'm off around 100 samples over an hour is that something to worry about?

Yeah, don't do 99, do 1.0000whatever for shrinking (99 would be used to grow the shorter source). you want to speed it up by X percent, where 1 is no change and anything above that is "faster".

When you do it, listen very very carefully two the sources seperately at the very end, like the last 30 seconds, and then listen to the mixed source. If it's off, you'll know.

[runonce]

Is the preserve pitch setting necessary...?

My impression is that the sources AREN'T truly the same pitch...just close enough to make it hard to hear... at least to the average listener.

The playback clock is the constant...the recording's rate is the variable...

Isnt this situation an extreme example of the "wrong sample rate in the header"...?

Playing a 48 at 96 sounds like chipmunks...playing a 48 at 48.002 might not be very noticeable, until an hour has passed...and you are out of sync...

Making any sense here? (sorry not truly addressing the post)

[Shadow_7]

If the clocks differ, I would think that preserving the pitch would  be counter productive.  Not that the adjustment is large enough to change the pitch (significantly).

My math is a bit different, but I've done it by a lot of trial and error (and minimal math).  By comparing the wave shapes in audacity and zooming in a lot.  My Korg MR-1000 seems to differ between left and right channels.  Or at least the converted results via audiogate.  It's the same device so it always starts in sync at 0 to 0.  Basically 0.0006 seconds per hour difference between channels.  Roughly.  Trial and error says speed 1.00000013 compensates for it mostly to 30 minutes.  A hair high, but short of adding another digit, close enough.  As I wonder what the FPU accuracy is limited to on a 32 bit CPU and with sox? 

It does make a difference, maybe not on short clips aligned on a per clip basis.  But for anything extracted from say 20 minutes into an half hour session and lasting longer than five minutes, fairly significant.  Mainly when mixed.  Which will happen at the point of reproduction if you're not using headphones.  Low stuff will drift out of phase and cancel itself out.  So bass, drums, timpani, tuba, will seem less significant in the mix.  And everything will sound a bit muddy even if the source wasn't.  It doesn't sound like that on headphones, unless you hit the mono button on a headphone preamp.  Higher frequencies seem to be relatively immune for some reason, probably because I didn't take a pure science approach to the math.  And the mic elements were spaced. 

I do wonder if the drift rate drifts depending on battery strength.  But I would assume that it's mostly fixed / device dependent.

[mattmiller]

Yeah, don't do 99, do 1.0000whatever for shrinking (99 would be used to grow the shorter source). you want to speed it up by X percent, where 1 is no change and anything above that is "faster".

That's what I figured.  I was thinking I was compressing the waveform to some some smaller percentage, when in fact I'm "speeding up" the sample frequency, resulting in the desired shrinkage.

Is the preserve pitch setting necessary...?  My impression is that the sources AREN'T truly the same pitch...just close enough to make it hard to hear... at least to the average listener.

If the clocks differ, I would think that preserving the pitch would  be counter productive.  Not that the adjustment is large enough to change the pitch (significantly).

I did this because it was recommended to do so in the tutorial I was following (in another thread).  I think it was describing the process for Audition, which I was able to follow pretty much exactly for my old version of Cool Edit Pro.  The choices are Time Stretch (preserves pitch), Pitch Shift (preserves tempo), and Resample (preserves neither).  So the "Resample" is the appropriate choice here?

[Yane]

My experience with the Cool Edit and later Adobe Audition time stretching algorithm was negative, it simply sounded bad. In a situation like yours, I ended up correcting the drift for each song -- like you, I figured out the relative clock speeds, then I  computed the  offset needed at the middle of each tune and applied it to that segment of the audio, easy to to non-destructively in CE. The amount of drift in a few minutes of audio wasn't noticeable. As to how much drift is acceptable, it's not a problem unless it's a problem: a few milliseconds of offset will result in comb filtering -- try introducing offsets and listen to the results to learn what it sounds like.   I assume you allowed for the offset resulting from the different distances to the microphones?

[ghellquist]

There are som bad items of news here.

-- the ear can hear a difference of a few milliseconds. The effect is a smearing of the stereo image. Running at 44100 samples per second, a few milliseconds might be perhaps 100 samples. 1000 is definitely enough to be a problem in my world. Remember that in a stereo array the two mics may be less than one millisecond apart and still give an acceptable stereo image.  ( 340 meters / second means 1millisecobnd equals 0,34 meters or slightly above a foot for the non-SI people).

-- the drift between two non-synched recorders will have a varying drift over time and between days. Most important aspect is probably temperature.  And this will change over time, as will the drift. And both boxes will most probalby not have exactly the same temperature change around the crystal oscillator where it matters.

// Gunnar

[stevetoney]

All math aside, what people have not mentioned in this post is that once any software correction is done, the question of how much is too much shift gets answered when you listen to the end result.  If the sources aren't matched well and they drift apart enough that you hear a reverb-y like sound in the mixdown, then the drift is too much.  If you don't hear it, then it's OK. 

That said, my experience was that 1 millisecond of difference between the sources was on the upper end of my personal threshold of what was acceptable...2 milliseconds was WAY noticeable.

[page]

the drift between two non-synched recorders will have a varying drift over time and between days. Most important aspect is probably temperature.  And this will change over time, as will the drift. And both boxes will most probalby not have exactly the same temperature change around the crystal oscillator where it matters.

Interesting, thanks for the heads up, didn't know that.

All math aside, what people have not mentioned in this post is that once any software correction is done, the question of how much is too much shift gets answered when you listen to the end result.  If the sources aren't matched well and they drift apart enough that you hear a reverb-y like sound in the mixdown, then the drift is too much.  If you don't hear it, then it's OK. 

Agreed, I noticed it first in a shift in stereo image (due to phase cancelation), and then finally reverb.

[Shadow_7]

In sox it's speed, tempo, and pitch.  speed compresses or expands the whole.  pitch shifts the frequencies.  tempo adds or subtracts content to make it longer or shorter.  Not that I'm up on the particulars of the inner workings.

I already do a 1.00011 speed adjustment to match the recording rate of my camcorder.  So it looks like I might be doing a 1.00011013 left channel and 1.00011003 right channel adjustment on my Korg MR-1000.  I couldn't get close enough by adjusting the speed of only one channel.  And I didn't really want to add a time shift in trimming of the content to compensate.  And it does look like that's the max number of digits that actually have an affect.

It does seem to vary for me.  1.00000011-ish for Tuba Christmas last year.  1.00000013-ish for Memorial day this year.  I noticed it mostly in a non-existent low end.  And others comments that my recordings were dull / nothing special.  I've been researching and drooling over a couple dozen pairs of microphones trying to resolve my low end issue.  Turns out that it's more of a sync / speed issue.  Although there are mics with better low end than my STO-2's.

[junkyardt]

spend your time churning through complicated math to do it in CEP if you insist, but there are other programs that make this process much more intuitive and easy, with no math necessary. i churn out near-flawless matrixes in Sony Vegas in 10-15 minutes or less now that i know how to do it right.

[mattmiller]

spend your time churning through complicated math to do it in CEP if you insist, but there are other programs that make this process much more intuitive and easy, with no math necessary. i churn out near-flawless matrixes in Sony Vegas in 10-15 minutes or less now that i know how to do it right.

The math isn't complicated.  Recording A is x minutes long and recording B is y minutes long.  Adjust one so that it matches the other in length, and then line them up.  Among the questions being raised here is whether the clock differences are constant throughout the recording or from one night's recording to another.  Vegas doesn't address that any better than CEP.

On a related topic that I don't think deserves it's own thread (correct me if I'm wrong)...

How does the addition work with the digital scale?   (I searched but couldn't find anything using my chosen keywords).  I normalized each of my sources to -6 dB.  If I mix them without touching either of them, what will the peak amplitude of the resulting file be (assuming two -6 dB peaks overlap)?  And if I increase one of them to -3 dB and reduce one of them to -8 dB?

[mattmiller]

How does the addition work with the digital scale?   (I searched but couldn't find anything using my chosen keywords).  I normalized each of my sources to -6 dB.  If I mix them without touching either of them, what will the peak amplitude of the resulting file be (assuming two -6 dB peaks overlap)?  And if I increase one of them to -3 dB and reduce one of them to -8 dB?

I found half the answer elsewhere.  Two sources at -6 dBFS should sum to 0 since -6 dBFS is 50% of full scale.  But how does the rest of the scale work?  Would -9 dBFS and -3 dBFS also sum precisely to 0?

[junkyardt]

The math isn't complicated.  Recording A is x minutes long and recording B is y minutes long.  Adjust one so that it matches the other in length, and then line them up.  Among the questions being raised here is whether the clock differences are constant throughout the recording or from one night's recording to another.  Vegas doesn't address that any better than CEP.

the math isn't complicated? all that gobbledygook up there with a bunch of numbers out to the 8th decimal point sure seems overly complicated to me. saying 'Vegas doesn't address the clock issue any better than CEP' is missing the point. your clock issue is only relevant if you're doing it the trial and error way, where you punch in a number, process it, line them up and see how it turned out, hoping you picked the right number. i've tried it that way, it's tedious, takes forever and is ultimately inaccurate. with Vegas you don't have to approach it that way at all. you can literally drag a bar that represents the stretch factor left and right and hear the results of the sync in real time, and when it's sync'ed properly you just let go of the bar and you're done.

[Shadow_7]

I looks like sox is the culprit for injecting my time shift.  Or at least part of it.  I used it to trim a segment out of a FIXED stereo wav file and trim was the only operation performed.  And plop plop fizz fizz, there's that shift again.  Perfect phase shift on a 2 minute 40 second clip.  Perhaps that's why audiogate added the option to output mono files.  It might just be time to use that option.  Back to the drawing board I guess.  Sox might not be the only causality, but it's looking to be an obvious one.  Time to find a new audio editor.  I rather liked the scriptability of sox.  Where's that sndfile thingy...  Could just be a 32 bit thing, as in CPU, not media file.

Part of my trial and error is repeatability.  It's common to the device, therefor common to all media captured on the device.  Once I guess right, I should never need to guess again.  Baring slight adjustments.  Just script and go.  Let it do it's thing on auto pilot while I sleep.  But in my case I have a perma sync point, 0 at 0 so I only need to compensate in one direction.  And now that I know of the issue, I can just take shorter sessions and avoid most of the drift for 20+ minutes of longer sessions.  If it's even the hardware, which I'm not certain of at this point.

[mattmiller]

the math isn't complicated? all that gobbledygook up there with a bunch of numbers out to the 8th decimal point sure seems overly complicated to me. saying 'Vegas doesn't address the clock issue any better than CEP' is missing the point. your clock issue is only relevant if you're doing it the trial and error way, where you punch in a number, process it, line them up and see how it turned out, hoping you picked the right number. i've tried it that way, it's tedious, takes forever and is ultimately inaccurate. with Vegas you don't have to approach it that way at all. you can literally drag a bar that represents the stretch factor left and right and hear the results of the sync in real time, and when it's sync'ed properly you just let go of the bar and you're done.

It's first grade math.  Measure the length of two objects and divide them.  Then multiply one of them by the result.  If object one was exactly half the length of object two, you wouldn't think that dividing 1 by 2 and getting 0.5 as a conversion factor was hard math (multiply object two by 0.5 and it's magically the same length of object one).  Measuring the length of two things that are really really close to each other in length, such that the conversion factor is something really really close to 1, is the same calculation.  Don't let a bunch of decimal places mislead you into thinking it's hard math.  Divide 6 by 11 and you get a bunch of decimal places, but any first grader knows how to do it.  I trust the math to sync the beginnings and the ends of the recording more than I trust my eyes to "see" it in Vegas.  But ultimately, both result in the same problem.  The stretch is linear in both CEP and Vegas (assuming you're only dragging end points).  What is being suggested here (I think) by some people who understand this stuff way more than I do is that the clocks aren't consistent, and therefore the recordings aren't diverging linearly throughout the recording, so even if you line up the beginning and end, there could be a spot 10 minutes in where source A is 1 ms ahead of source B, and 22 minutes in source B might be 1 ms ahead of source A.  And this is why some people subscribe the theory that the only way to make sure it's in sync throughout is to sync the beginnings and ends of much smaller chunks and then join them together.  Personally, that's more work than I'm willing to put into it if I can't hear the small amounts of drift.  And if I CAN hear the small amounts of drift on the interior of the recording, then I'm going to either bow out of the matrix business or get a 4-channel recorder (which I really don't think is logical for me because I rarely am in a situation where the SBD and my mics are close enough to run to the same recorder).

[junkyardt]

I trust the math to sync the beginnings and the ends of the recording more than I trust my eyes to "see" it in Vegas.  But ultimately, both result in the same problem.  The stretch is linear in both CEP and Vegas (assuming you're only dragging end points).  What is being suggested here (I think) by some people who understand this stuff way more than I do is that the clocks aren't consistent, and therefore the recordings aren't diverging linearly throughout the recording, so even if you line up the beginning and end, there could be a spot 10 minutes in where source A is 1 ms ahead of source B, and 22 minutes in source B might be 1 ms ahead of source A.  And this is why some people subscribe the theory that the only way to make sure it's in sync throughout is to sync the beginnings and ends of much smaller chunks and then join them together.  Personally, that's more work than I'm willing to put into it if I can't hear the small amounts of drift.  And if I CAN hear the small amounts of drift on the interior of the recording, then I'm going to either bow out of the matrix business or get a 4-channel recorder (which I really don't think is logical for me because I rarely am in a situation where the SBD and my mics are close enough to run to the same recorder).

first of all, as for trusting the math, why would you trust it? all you have is calculations you've come up with on your own which have human error involved. the only way i would trust the math is if i could somehow get clock/speed specifications direct from the manufacturers. as it is, there's human error involved in trying to create accurate calculations. in other words (i'm assuming this is the way you're doing it, this is how i tried it at first) you try to pick the identical spot in time (just before someone yells on the recording, for instance) to begin and end each recording. then, in theory, if you pick the exact same spot in time for the beginning and end of each recording, the difference in time lengths for the two recordings will represent only the drift, and nothing more. but ultimately, you're human, so you can't do this perfectly. thus, any difference in the lengths will represent not only the drift, but also your error in picking the right start and stop points, and so using these lengths as a basis for a calculation will result in a flawed calculation. not sure what you mean by 'seeing' it in Vegas as being unreliable. you're not seeing it, you're hearing it. you actually hear the recordings go in and out of sync as you stretch. isn't the 'sound' of how well it's sync'ed or not ultimately what we're after here (lack of echo, etc.)? so if you have a way to adjust that sound directly and intuitively, with instant feedback about what effect your adjustments are having, why would you still insist on doing it in a far more indirect way?

as for your other concern about recordings going in and out of sync within the same recording...i think this is creating a problem to worry about where there really isn't one. i've done probably 10 or 15 matrixes and have never encountered this (at least noticeably). once they are in sync, the whole thing is basically in sync from start to finish (at least with my 2 recorders.)

[dmonkey]

I've been using Vegas lately to stretch and align, and generally I'm pleased...but is there an easy way to jump to the end of a WAV file to stretch? Maybe I'm just an idiot, but I find it tedious to zoom all the way in and figure out how much to stretch by, then scroll all the way to the end of the file to actually grab and stretch. It works, but it's just a little time consuming. And it's all trial-and-error too.   

[faninor]

Hey man, my degree is in mathematics. The math to calculate the "drift factor" is incredibly simple and easy to derive just knowing what you need to do. You need to think a little bit past your first grade math to see what the real problem here is.

Here's a practical situation.

Source 1 - 1 hr exactly @ 48kHz (a total of 172,800,000 samples)
Source 2 - also recorded at 48kHz, but let's say the first sample of each matches perfectly, and the last sample of source 1 matches up to the 172,801,000 sample of source 2. So they drift by 1,000 samples exactly in the hour (source 1's concept of an hour).

To resample source 2 to be exactly 172,800,000 samples as well you'll need to use a factor of 172800000/172801000.

Here's the first lot of digits of that fraction:
0.99999421299645256682542346398458

From here it is a precision problem
If you correct with a factor of 0.9999942, source 2 will end up with 172,799,998 samples total. After correction there is a 2 sample drift which is definitely acceptable.

Using a factor of 0.999994, source 2 will end up with 172,799,963 samples total. Overshot the mark by 37 samples, but that's still pretty good.

Using a factor of 0.99999, source 2 will end up with 172,799,272 samples. Now you've overshot it by 722 samples which is nearly as bad as before you started, not to mention you've thrown out all the original data in source 2 and interpolated completely new samples.

I don't remember how many digits CEP gives you to work with, but in my experience it is not enough for the level of precision needed if you're trying to fully sync long recordings.

This is why I recommend Sony Vegas:

a. it has "stretch event" functionality (ctr + click/drag the beginning or end of a track -- no need to even determine the number of samples by which the two sources drift).
b. it has non-destructive editing the whole way through, you only need to resample and render to a new file AFTER you've perfectly matched the two sources.

dmonkey, just cut off the ends while aligning your sources (anything you don't need to see), and then restore them after you're done stretching.

1. match up an event early in the recordings, and make a split here on both sources.
2. match up an event late in the recordings (yes, move one of the files in the timeline), and make a split here on both sources.
3. stretch one file to match the other
4. at the start and end of each recording, pull them back out to restore the segments that had been cut while aligning

I do think simply dropping 1000 samples evenly spaced throughout the long source may also be a viable method, as long as the pitch difference between the two sources is small enough to be imperceptible. Has anyone tried this?

[dmonkey]

Aaaah...I hadn't thought of "trimming" one end or the other then restoring. I forget that it's non-destructive. Very cool. Thanks!

You lost me a bit on the splitting thing. I guess I'm confused about why the splitting when you can view the waveform on screen to align. So you split at both ends and then pull one back to eliminate the gap? Hmmm...I'm going to have to try this to understand.

[faninor]

Hmm maybe I should make a little tutorial with pictures if this seems helpful? Basically I was just describing how I trim the ends - I make a split in the track (and discard the half I don't need to see) at or near the event that I'm syncing between the two sources when discarding the ends, so it is easy to find that spot while aligning.

As for the problem of possible variable drift, fast and easy to deal with that in Vegas to. Just align the first few minutes and repeat.

I can't tell you how many hours this has saved me (resampling in Cool Edit Pro with an old computer can be slow)

[page]

Btw, audacity is relatively simple to do this in as well and has maybe 8 or 9 decimal places of precision. Morst did a tutorial on it elsewhere, but it doesn't visually stretch them, gotta use the math.

I do think simply dropping 1000 samples evenly spaced throughout the long source may also be a viable method, as long as the pitch difference between the two sources is small enough to be imperceptible. Has anyone tried this?

I agreed with your post until I got to the bitter end.

Chopping sucks. Carry on. 

[admkrk]

i'm use a system more like junkyardt. aside from the math being simple or complex, using math also assumes the exact same start and end place in both sources. i visually get them close then go by ear from there adjusting track by track as needed. sometimes stretching, sometimes simply spitting and moving the new start all depending on how it sounds. if one of the sources dropped a few samples 1/4 way through it will end up sounding worse if you stretch the whole thing.

is it tedious and time consuming? yes, but i trust my ears more than i do a calculator.

[faninor]

I agreed with your post until I got to the bitter end.

Chopping sucks. Carry on. 

I've never tried it that way -- just always been curious about it in situations where the speed difference is so extremely small that correcting the pitch isn't a real concern. Pitch is the only concern I can think of -- I certainly don't think any of us could notice if 1 sample is removed. Anything else to worry about?

[Shadow_7]

In my case I am using a two channel field recorder and the two channels drift relative to each other.  Most of which appears to be a flaw in the conversion software.  In audacity it's something like 0.000003 % speed change on the right channel to align at about 1 hour.  After converting with sndfile-resample.  Significantly worse after converting with sox.  But I'm not about to sit in front of this thing to type a couple numbers and push enter every 108 minutes.  That's so last season of lost. 

So I have the number and doing the math lets me script it, and run it retroactively against all previously recorded content 50+ hours worth, while I sleep, or go fishing.  Unfortunately without the adjustment every 30 minutes or so +/- 20 minutes it drifts completely out of phase.  I never knew to check that both channels were in perfect alignment because it was never bad enough to reach a state of reverb between the two channels to present itself as a sync issue.  Even though I've recorded 2 hour plus tracks on several occasions.  It's always manifested as a virtually non-existent low end, which up until now I've assumed was my microphones, not my field recorder and/or content processing.

Fortunately, or unfortunately I've recorded in high sample rates, so getting a 44.1kHz or 48kHz result with adjustments can be done while not having to invent content.  Unfortunately that's a lot of data which takes a long time to load up in an editor to find a sync point in the first place and a long time to do the conversion / resampling to distributable formats.  I like my mics, I like my field recorder, so those aren't going to change anytime soon.  And I've been recording with them for over two years.  So I have a LOT of content that needs to be reprocessed.  Tis the burden of a data packrat I suppose.

[page]

I agreed with your post until I got to the bitter end.

Chopping sucks. Carry on. 

I've never tried it that way -- just always been curious about it in situations where the speed difference is so extremely small that correcting the pitch isn't a real concern. Pitch is the only concern I can think of -- I certainly don't think any of us could notice if 1 sample is removed. Anything else to worry about?

I'm against it for two reasons:

I've never heard a great chop job, and second, I've tried it myself and it took more effort by the end and it still wasn't great by the end of some long songs.

[runonce]

Im skeptical about Vegas routine...without knowing what the stretch is really doing...I hate not knowing.

I like the math approach...

A  few tangential thoughts...

I think we are addressing a situation where there are 3 clocks involved.

1 - recorder A

2 - recorder B

3 - playback device

If there is any difference between 1 and 2 - it will result in a different pitch when played on 3 - correct?

I wonder we were able to use two discrete clocks during playback - would the sources be the same pitch?

Is there anyway to determine a given recording's "absolute" sample rate? (rather than the generic "44.1")

[junkyardt]

Im skeptical about Vegas routine...without knowing what the stretch is really doing...I hate not knowing.

I like the math approach...

  as far as i knew, you're stretching it either way. i mean, the math is just a way to determine how much to stretch by, correct? and what do you mean 'you don't know what it's really doing'? it's fairly simple, all it's doing is speeding up or slowing down the recording. you can have it change pitch if you want it to, but you're in control of that in Vegas. if you don't want it to change pitch, it won't.

[runonce]

Im skeptical about Vegas routine...without knowing what the stretch is really doing...I hate not knowing.

I like the math approach...

  as far as i knew, you're stretching it either way. i mean, the math is just a way to determine how much to stretch by, correct? and what do you mean 'you don't know what it's really doing'? it's fairly simple, all it's doing is speeding up or slowing down the recording. you can have it change pitch if you want it to, but you're in control of that in Vegas. if you don't want it to change pitch, it won't.

"Stretching" is just the name of the function...what does it =technically= do? Is it a resample routine?

Someone else asked - how do we find the correction factor when the recordings arent the same length? (presuming two recorders started and stopped at different times.)

Is there a way to determine how many samples are contained in X seconds of music?

[ghellquist]

I think we are addressing a situation where there are 3 clocks involved.
1 - recorder A
2 - recorder B
3 - playback device
If there is any difference between 1 and 2 - it will result in a different pitch when played on 3 - correct?
I wonder we were able to use two discrete clocks during playback - would the sources be the same pitch?
Is there anyway to determine a given recording's "absolute" sample rate? (rather than the generic "44.1")

First, you might be able to determine the exact sample rate if you have a very accurate signal of known pitch recorded. Remember though that the crystal oscillator in you recording box is very accurate already, so you have to know the reference pitch with even better accuracy.

Secondly, you could vary the speed of the two playbacks. That is basically what you do with the "stretch" algorithm in software. It could be done in hardware, playing out the two signals to an analog signal and then perhaps converting it back to digital again. Much simpler to use the software.

Gunnar

[ghellquist]

Is there a way to determine how many samples are contained in X seconds of music?

Simple, even I know that one. X times the sample rate.

// gunnar

[ghellquist]

How does the addition work with the digital scale?   (I searched but couldn't find anything using my chosen keywords).  I normalized each of my sources to -6 dB.  If I mix them without touching either of them, what will the peak amplitude of the resulting file be (assuming two -6 dB peaks overlap)?  And if I increase one of them to -3 dB and reduce one of them to -8 dB?

Before anything else, you have to decide on which kind of decibels we are talking. Generally we would talk "sound pressure level", but some of the decibel scales are "power related". There is an excellent article with not too much math:
http://www.engineeringtoolbox.com/adding-decibel-d_63.html

First, it depends on how the two signals are correlated to each other. If they are very similar, or exactly the same, adding two signals together will yield a 6dB increase. If the two signal are exactly opposite as in phase inverted, the signals will ge totally nulled, no output at all. Generally we calculate with unrelated signals to increase somewhere from 3 dB to 4,5 dB. In a matrixing situation the signals will be close but not exactly same so I would count on -4,5 dB.

Secondly the dB scale is logarithmic. A -3dB added to a -8dB will (when totally correlated) increase the signal to about -2dB (or slightly above that, something like -1,75dB).

Gunnar

[it-goes-to-eleven]

Part of my trial and error is repeatability.  It's common to the device, therefor common to all media captured on the device.  Once I guess right, I should never need to guess again.
...
My Korg MR-1000 seems to differ between left and right channels.  Or at least the converted results via audiogate.  It's the same device so it always starts in sync at 0 to 0.  Basically 0.0006 seconds per hour difference between channels.

Hardware drift tends to vary with temp.  So for most people here, there is no constant/linear fix.

Your case seems to be different than most - if it is software drift in audiogate.  If it is constant, they could easily fix their conversion software.  Or it might be a hardware problem.  It is not an issue you should have to fix.  Have you tried contacting Korg about it?

[Shadow_7]

In my case I think it's mostly software related.  And by software I mean in the part of the flow that is AFTER audiogate.  Audiogate can get me CLOSE to my end goal.  But I'm also compensating for an HD camcorder that runs at about a factor of 1.00011 faster.  About 20ms per 5 to 10 minutes.  My korgs channels seem to be drifting 1.00000003 per hour.  Just enough to reach perfect phase inversion between 30 minutes and 60 minutes.  And maintain it for an equivalent amount of time.  Hearing it "correct" is apparently a new thing for me.

I'm not sure if that's audiogate or not.  But it is enough to affect the low end perception of my mics.  Since most times I'm recording 2 hours continuous per session.  It also makes gui editors undesirable because you have to wait for that content to load.  And otherwise be there for each step of the process.  All I'm using audiogate for is to convert from 5.6 DSD to 32/192.  (was 24/96).  I'll likely skip that step in future sessions by just recording in 32/192 (or 24/192, not sure which it's actually doing).  And that all so I can do the audio equivalent of oversampling  to the desired result.  Since I know ahead of time that I'll be adjusting speed. 

Sox was injecting drift AFTER using sox to correct the drift.  So it's kicked to the curb.  Currently making some strides with sndfile-*, but you seem to have to break everything up into individual steps.  No amping, concating, compressing, or other stuff all in one step.  The drift portion currently looks something like:

  sndfile-resample -by 0.229687507 -c 0 temp_L2.wav temp_L3.wav
  sndfile-resample -by 0.229687500 -c 0 temp_R2.wav temp_R3.wav

The rough equivalent of 44.1kHz from 192kHz.  -c 0 takes forever, so I ran a few test runs with -c 4 and results were satisfactory.  0.000003 percent -ish in audacity's version of the process for speed on the right channel.  As far as I can tell, audacity does the same conversion as sndfile-resample.  And falls back to sox if sndfile isn't present.  I'm pretty sure I need to file a bug report against sox.  Not sure if I should against audiogate.  sndfile seems to satisfy at this point.  Albeit the slowest of all conversion software to date (in part to the highest possible settings).  I was using sox to make sure all edits landed on solid seconds to make CD tracks land on/near 1/75th of a second.  My stand alone CD player wont play a CD if it doesn't.  At least not a 700MB CD.  It didn't seem to mind when 650MB CDs were used and SBE or whatever the technical term is were not accurate.

I'm not too worried about pitch.  These adjustments are so small it's not likely to affect intonation and stuff.  Bad intonation is generally measured in beats per second.  We're talking about shifting one low frequency wave form one crest per hour.  If you're adjusting pitch on that scale factor, you're probably injecting more problems than might be solved.  Or at a minimum increasing the processing time needed to perform the process.

[mattmiller]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

[Shadow_7]

When you speed up a track, it's going to get shorter.  If it matched another track before being sped up, then the other track will be longer than the one that got altered.

-----

When you have two tracks that start at different times, you need to find TWO sync points common to BOTH tracks.  The further apart the better.  Consider one of the sync points your new 0 (ZERO).  Basically a two step process, make them run at the same speed (no drift), then trim each to same sync point / point in time.  Bear in mind that you'll likely need to re-find the sync point (zero) after resampling.  Could be simple math and automated.  Could be going through the ID stage a second time.  Which you should probably do to verify results anyway.

-----

I agree it's not something that I should have to do.  But in my case the drift is so small, and the tracks / hardware so closely related, that any variance in temperature will likely not produce a variance in clocks and drift large enough to be of concern.  And probably not that adjustable anyway depending on the decimal point accuracy of the CPU/FPU (and software) performing the conversion.

I've got a process now and it seems to work.  sndfile-resample is my friend.  And audacity his good buddy.  I still need to find an equivalent to sox's trim function, manually punching in the timestamps is a bit tedious IMO.  Resampling happens first and relatively blindly / on faith.  That way the gui only loads small and manageable files.  I'm loving the results so far.  Finally something put the Tuba player back into the brass quintet.  I've tried all scores of EQ and other tricks to limited success until I figured this one.  I even tried a few different mics which generally proved more problematic.  I've listened to these things many hundreds of times and it's bugged me every time, until now.  It's like I got a $500 or would it be $5,000 upgrade.  Since it looks like I wont need to try those $3K+ mics in an effort to keep my sanity.  At least not anytime soon.

I've still got to track down what's the root cause.  It shouldn't be the hardware as that would be problematic when it creates new files after every 12:41.2??.  Lot's of A/B-ing in my near future I guess, to see if audiogate and only audiogate satisfies.  I've generally left it to audiogate to convert from DSD to an editable format, and that's it / period / end of story.  Everything else is done in other software.  So I don't know if it's the device and/or audiogate that is the root cause (yet).  I do know that sox's trim function when pulling content from about an hour in injects drift where there is otherwise no drift.  Could just be my current version of sox.  Could be my old 32 bit laptop.  Could be something in the file formats.  Could be many things.  Korg can wait until I figure out what it is and what it is NOT.

[admkrk]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

things like silence and solos will use less space than say 6 guys going to town at the same time.

[junkyardt]

Shadow_7, are you like, on acid or something? I've tried to make some sense of your posts, but they seem to be little more than you rambling to yourself.

[it-goes-to-eleven]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

things like silence and solos will use less space than say 6 guys going to town at the same time.

NOT.

[mattmiller]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

things like silence and solos will use less space than say 6 guys going to town at the same time.

NOT.

That's what I was thinking -- 48,000 samples per second, each described by 24 bits, should be the same no matter what they're capturing.

[Shadow_7]

Shadow_7, are you like, on acid or something? I've tried to make some sense of your posts, but they seem to be little more than you rambling to yourself.

Is bash an acid?

http://home.earthlink.net/~shadow_7/korg_resync.sh

That's basically what I'm doing.  My two tracks on my two channel field recorder drift.  Just to enough to operate out of sync 80% of the time.  Perceived by me as no low end.  Not bad enough for reverb effects.  But bad enough for doing the equivalent of inverting the phase of a stereo image and publishing that as a commercial CD.  I don't know if that drift is artificial (software) or part of the hardware.  But it's there, and it's plagued me for over two years, which is how long I've been recording with this device.  I suppose it does sound a bit like I'm talking to myself.  I should probably quote more often than I do, which would probably help.  But as far as I know I'm speaking english.  Not that I was ever good in it in school.  Anyway that script seems to correct the data issues for me.  I could take some screen captures if that helps you to understand.  Or maybe some sound files would work?

BEFORE:
http://home.earthlink.net/~shadow_7/rnsm.mp3

AFTER:
http://home.earthlink.net/~shadow_7/rnsm3.mp3

No brasses, but there are bass drums and timpani to indicate what is most affected.

[admkrk]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

things like silence and solos will use less space than say 6 guys going to town at the same time.

NOT.

That's what I was thinking -- 48,000 samples per second, each described by 24 bits, should be the same no matter what they're capturing.

maybe i'm thinking of flacs, but i don't see why this should be much different. less information is still less information.

[nic]

maybe i'm thinking of flacs, but i don't see why this should be much different. less information is still less information.

you're thinking of flacs (or any compression scheme...)
with audio 1 second of silence has the exact same amount of data as 1 second of noise, assuming same bit depth and sample rate.

[mattmiller]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

things like silence and solos will use less space than say 6 guys going to town at the same time.

NOT.

That's what I was thinking -- 48,000 samples per second, each described by 24 bits, should be the same no matter what they're capturing.

maybe i'm thinking of flacs, but i don't see why this should be much different. less information is still less information.

FLACs are compressed.  Same as a JPEG image which is smaller or bigger depending on how many different colors are in the image.  Uncompressed WAV should, I think, dedicate the same space to every sample no matter what the sample contains.

[admkrk]

i stand corrected then.

tbh tho i never payed much attention to file size except for when it came to fitting on a disc.

[Shadow_7]

Basically sox yields this:

sox -v 2 DSF_0102_001.wav -v 2 DSF_0102_002.wav -v 2 DSF_0102_003.wav -v 2 DSF_0102_004.wav -v 2 DSF_0102_005.wav -r 44100 extract.wav trim 00:50:00 00:10:00



From the DSF's via audiogate 5.6 DSD to 32/192.

And the script (sndfile-resample) yields this:

[runonce]

Basically sox yields this:

sox -v 2 DSF_0102_001.wav -v 2 DSF_0102_002.wav -v 2 DSF_0102_003.wav -v 2 DSF_0102_004.wav -v 2 DSF_0102_005.wav -r 44100 extract.wav trim 00:50:00 00:10:00



From the DSF's via audiogate 5.6 DSD to 32/192.

And the script (sndfile-resample) yields this:

I think most of us would just load into audacity, split the stereo track into two channels and use the TimeShift tool to adjust one channel...still looks like the end result is a little off...

[mattmiller]

I've got two sets from Friday night mixed and I'm happy with the results.  I can't hear any drift, which is good enough for me.  But I just noticed that the two sets are awkwardly DIFFERENT in file size.  The mixdown of set 1 is 65 minutes long and is 1.47 GB (48/24).  The mixdown of set 2 is 55 minutes long but is only 929 MB.  So set 1 is only 18% longer but is 58% bigger in file size.  Both still say "48000  32 bit  Stereo" in CEP.  Is this possible?  Is there some sort of diagnostic I can use in CEP to find difference between the files?

I opened this session back up and redid the mixdown and now the longer set is more appropriately sized (around 1100 MB).  The only thing I did differently on the two sets originally was using "File > Save Mixdown As" for the "problem" set originally, while for set 2 I discovered the "Right-Click > Mix Down to File" route.  So this time, I used this right-click context menu on set 1 and got the appropriate file size for the mixdown.

So what is the difference between the two methods that results in "File > Save Mixdown As" yielding a bloated file size?

[Shadow_7]

I think most of us would just load into audacity, split the stereo track into two channels and use the TimeShift tool to adjust one channel...still looks like the end result is a little off...

Yes it looks that way on that particular waveform.  But everything 59 minutes 8 seconds and some change or sooner is less off.  Plus at 1+ hours in length, just loading it up in audacity is a five minute commitment.  And each global edit an equal commitment, hence the lost comment.  aka hatch and 108 minutes.

[admkrk]

I opened this session back up and redid the mixdown and now the longer set is more appropriately sized (around 1100 MB).  The only thing I did differently on the two sets originally was using "File > Save Mixdown As" for the "problem" set originally, while for set 2 I discovered the "Right-Click > Mix Down to File" route.  So this time, I used this right-click context menu on set 1 and got the appropriate file size for the mixdown.

So what is the difference between the two methods that results in "File > Save Mixdown As" yielding a bloated file size?

i'll go out on a limb and probly get shot down again but, the larger one might be adding peak data and such similar to saving a montage in wavelab while the smaller is just saving the wave.

[nic]

I opened this session back up and redid the mixdown and now the longer set is more appropriately sized (around 1100 MB).  The only thing I did differently on the two sets originally was using "File > Save Mixdown As" for the "problem" set originally, while for set 2 I discovered the "Right-Click > Mix Down to File" route.  So this time, I used this right-click context menu on set 1 and got the appropriate file size for the mixdown.

So what is the difference between the two methods that results in "File > Save Mixdown As" yielding a bloated file size?

i'll go out on a limb and probly get shot down again but, the larger one might be adding peak data and such similar to saving a montage in wavelab while the smaller is just saving the wave.

every program I have ever used that saved peak data - win, os x, linux, etc - did so in a separate file.
is it even part of the spec to save it in the actual audio file?

[runonce]

I opened this session back up and redid the mixdown and now the longer set is more appropriately sized (around 1100 MB).  The only thing I did differently on the two sets originally was using "File > Save Mixdown As" for the "problem" set originally, while for set 2 I discovered the "Right-Click > Mix Down to File" route.  So this time, I used this right-click context menu on set 1 and got the appropriate file size for the mixdown.

So what is the difference between the two methods that results in "File > Save Mixdown As" yielding a bloated file size?

i'll go out on a limb and probly get shot down again but, the larger one might be adding peak data and such similar to saving a montage in wavelab while the smaller is just saving the wave.

every program I have ever used that saved peak data - win, os x, linux, etc - did so in a separate file.
is it even part of the spec to save it in the actual audio file?

And isnt this info just text type info...? Doubt it would account for such a different file size...?

[admkrk]

that's why i added the montage part after i though more about it. the peak data is saved in a separate file but i'm not sure how the montage is saved. i'm going by the wording. save to file sounds like a wave file is being saved, while save mixdown as, sounds like it's adding the mix info as well.

plus i'm only guessing.

<edit> because i was writing during the last post
it could be saving pointers, markers, and references to to original waves if i'm right about the wording deal.

[runonce]

that's why i added the montage part after i though more about it. the peak data is saved in a separate file but i'm not sure how the montage is saved. i'm going by the wording. save to file sounds like a wave file is being saved, while save mixdown as, sounds like it's adding the mix info as well.

plus i'm only guessing.

<edit> because i was writing during the last post
it could be saving pointers, markers, and references to to original waves if i'm right about the wording deal.

I like that explanation...sounds like the save mixdown route assumes a work in progress...and save to file is the final rendering?

[runonce]

I think most of us would just load into audacity, split the stereo track into two channels and use the TimeShift tool to adjust one channel...still looks like the end result is a little off...

Yes it looks that way on that particular waveform.  But everything 59 minutes 8 seconds and some change or sooner is less off.  Plus at 1+ hours in length, just loading it up in audacity is a five minute commitment.  And each global edit an equal commitment, hence the lost comment.  aka hatch and 108 minutes.

You might want to explore the File > Edit Chains feature in Audacity. Looks like it allows you to apply a sequence of operations in one action.

[it-goes-to-eleven]

Too much time on my hands, it's ticking away with my sanity
I've got too much time on my hands, it's hard to believe such a calamity
I've got too much time on my hands and it's ticking away from me
Too much time on my hands, too much time on my hands
Too much time on my hands

[admkrk]

ticking away the moments that make up a dull day.   

[Shadow_7]

You might want to explore the File > Edit Chains feature in Audacity. Looks like it allows you to apply a sequence of operations in one action.

I might, but a lot of my edits don't lend themselves to that sort of chain.  i.e. Hard Limit depends on content (and mood).  Hard Limit + Amp + Trim is about all I normally do in audacity as far as edits go.  Everything else is more or less finding where the waveforms line up, or what the EQ looks like.  Maybe some noise removal if I'm using my cheap mics.  What would otherwise be chained is 1+ hours, sometimes close the 3 hours continuous audio and several GB in size.  So more command line tools are a better fit, after plugging in a few numbers after looking at the content in audacity.

-----

It looks like sndfile-resample isn't of much use for doing large timeshifts or speed modifications.  0.5 vs. 0.500000058 for that minor shift.  I think I've ruled out the Korg or audiogate though.  It looks like sox probably in combination with a stereo file and concat-ing several files/parts into a whole is the primary issue.  Using sndfile to do those singular tasks works better.  I've stuck sox back into the mono parts to alter speed and it does the job.  I'm liking the resampling that sndfile-resampling does at it's highest setting.  It's a major time suck, but kind of nice.  There is a minor time drift between it's lowest -c 4 and highest -c 0 settings of about 0.002 seconds.  But since all I'm doing is swapping korg audio for FH1 audio on a video, good enough.  The math even works out pretty simply.  Far less guessing / trial and error at this point.  Basically difference in the start of the camcorder segment between two sync points.  Over the length of time between those sync points.  Plus one for the speed amount number via sox.  Or 0.072/737.105 + 1 = 1.000097679 on the component I've been toying with.

[morst]

I've never tried it that way -- just always been curious about it in situations where the speed difference is so extremely small that correcting the pitch isn't a real concern. Pitch is the only concern I can think of -- I certainly don't think any of us could notice if 1 sample is removed. Anything else to worry about?

If two different clocks yield recordings of two different lengths, they will have correspondingly different pitch. Most likely, it will be too subtle to be heard with the ears though it could result in some phase shift, or beat frequency. Personally, if two signals are not within 15-20ms, I hear slap-back (delay), but below that it's pretty subtle. Unfortunately, unless the difference is microscopic, there is likely to be some phase shift audible, and that can definitely screw with bass definition and solidity

I think we are addressing a situation where there are 3 clocks involved.
1 - recorder A
2 - recorder B
3 - playback device

If there is any difference between 1 and 2 - it will result in a different pitch when played on 3 - correct?

I wonder we were able to use two discrete clocks during playback - would the sources be the same pitch?

Is there anyway to determine a given recording's "absolute" sample rate? (rather than the generic "44.1")

I think we can ignore clock #3 for our calculations. Once you set clocks 1 & 2 to remove drift, the only people who would notice the difference to clock 3 are those with micro-fine perfect pitch.

But you bring up an interesting point regarding two clocks. If you transferred your recordings into the computer via analog, then each recorder would play back its content at the proper relative clock speed (assuming temperature and other environmental factors are close enough to the same). This could theoretically eliminate the need to resample by calculation, but the drawback is that BOTH sources get resampled on transfer for this to occur.

If you wish to determine the exact drift for two devices, you can make a test signal. I built mine in audacity at 48kHz. I made 10 seconds of triangle wave at 480 Hz, then generated one hour of silence (172,800,000 samples) and followed that by 10 seconds of triangle wave at 480Hz. Once I had the file, I loaded it into one recorder, and hit play, while recording on the second deck. After the hour was complete, I loaded the new recording into the computer, and lined them up. It was very easy to tell the exact number of samples of drift, but it is not a clean ratio, by any "stretch" haha. My two main decks drift about 4.29 samples per second, which is over 15,000 samples per hour.

My next test should be to run this same signal again at different temperature levels, and see if it's close or how far off it gets with temp change.

Let's assume for a moment that this whole stretching business is just bad engineering and that the only true way to synch sources is by cutting and pasting. In order to cleanly remove drift, you'd have to cut and paste and adjust very small sections. In fact, as the section length decreases, your accuracy increases. If I recall the concept of calculus, this means that you may as well just make the section length (epsilon?) as small as possible, which just brings us back to the resample algorithm we're all discussing!!! Did I say that right? In plain English - I disagree with the notion that stretch/squash is less accurate than a chop-job. Exactly the reverse, in my opinion.

[kirk97132]

Here is a method that uses different sampling rates which give a more percise control over the lengths than AA3, CEP, WL etc.  It allows up to a .001 change in the sample rate.  You will need to Download the free version of R8Brain to use this.  I'll atach the worksheet which is an XLS file.  I had to zip the file since we cannot attach XLS files here.  Hope it helps, Kirk

[Husker Du]

Here is a method that uses different sampling rates which give a more percise control over the lengths than AA3, CEP, WL etc.  It allows up to a .001 change in the sample rate.  You will need to Download the free version of R8Brain to use this.  I'll atach the worksheet which is an XLS file.  I had to zip the file since we cannot attach XLS files here.  Hope it helps, Kirk

It's without question the best method that I know about, also.  It works flawlessly.

[Gutbucket]

Finally got around to figuring out how to fix drift in Samplitude. Too easy.  I'm using the Samp V10 Master edition, unsure if the same tool is available in SE or the other previous versions.

The function is termed Elastic Audio and can be applied directly at the object or at the track level.   There are various options for keeping or varying pitch, quantisizing to beat markers, playing processing overhead against quality etc.  You can shrink or stretch audio by entering start and stop values, the desired length, or by snapping to markers or other objects.  Values entered are whatever units you are working in: samples, hours:min:sec, etc.  I used the highest quality setting applied as 'real time effect' at track level.  It's instantaneous but eats a few CPU cycles to do its stuff when playing back.  Value not quite right? Just re-enter a new value.

I lined up the tracks on an early transient.  Moved to the end of the show and found another transient, switched units to samples and meaured the time offset between tracks then subtracted that value from the total length of the longer track.  Entered the new value for the track length.  Done.

The transients I used were within the begining and end points of the objects so technically my simple calculation is off slightly, but not significantly.  The time difference between mic pairs themselves, due to the microphone spacing, is far greater. 

[kirk97132]

^^^ thanks