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

[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")