Syncing tracks from multiple sources

Alexbt

New member
Hey all,

So basically I was wondering if there have been any software advances in track syncing that I'm not aware of--here's the scenario:

Recorded a show with a line from the sound board onto my 2-track HI-MiniDisc recorder.
Also have the show as recorded with two mics from the back of house--were recorded onto a computer.

I have always lined these kinds of thing up by ear, but I've never worked with sources from a space this large--it's proving not very easy to line this up by ear or by sight.

Is there any software out these days that can analyze tracks and sync them automatically?

Aside from that, I'd love to hear any other ideas.
 
Is there any software out these days that can analyze tracks and sync them automatically?
I doubt there'd be anything that'd work that well in this instance because of the delay between the board sound and the back of room. Any auto-sync software that I could think of would have to know the amount of delay; if you knew that you'd probably be able to just do it yourself.

Which is the best way to do it anyway, IMHO. The key is to look for peaks with fast attack on the FOH tracks. If you're lucky, you have the drummer counting off the start of a song with his sticks (click1,click2,click3, play). The question there is whether it's loud enough to make it to the room mics. One great transient that usually makes it everywhere is if someone accidentally kicks the mic stand between songs :). If it's a tight band, find that power chord after a rest that the band hits as one. (remember, you can have your cues anywhere in the sound track, they don't necessarily have to be at the beginning.)

Once you have a reference spot, then it's a matter of figuring out the delay. Do you want the real delay of the room mics? If so, a rough calculation would be to take the estimated speed of sound (1130 feet/sec) and divide that into the distance from the primary sound source to the room mics. For example, if the mics were 50 feet back, then the delay time would be 50ft/1130ftsec, or 0.044 seconds, or 44 milliseconds. Push the room track back about 44ms and you'll probably be pretty close to the the real deal.

Not everybody wants/likes that delay; that's your call. You could just throw the room on top of the main feed with no delay, too. Kind of artificial, but sometimes preferable, depending entirely upon the room and track qualities.

G.
 
You will probably also have sample rate mismatch issues, ie, one sample clock from one device is ever so slightly faster than the other.
 
You will probably also have sample rate mismatch issues, ie, one sample clock from one device is ever so slightly faster than the other.
Assuming one clock was faster than the other, what would the artifacts be and how would one fix them?
 
In my experience with digital, drift is not that great of an issue, actually. I've done things like weddings, receptions and live music gigs where I've had to match up digital audio and video from multiple sources without the benefit of of timecode, house sync or anything like that.

The audio often came simultaneously from an FOH tap to laptop, multiple digital video camera audio tracks, ADAT and source MP3s, and the program lasted as long as a couple of hours (though there was usually a media break at 40 minutes in ADAT and one hour on the videotapes because of tape length restrictions.) I have had great success just using the audio and visual cues to line tracks up in Vegas, and never had a noticable problem with drift.

If one has an analog source they need to match up, yeah definitely drift can be a problem (not to mention wow and flutter), but in an all-digital production, unless one of the recording devices had a clock that was majorly off, any drift is usually limited to inhumanly small proportions.

G.
 
Yeah, someone had a thread last week about the same sort of thing where he had exactly that problem.

http://www.homerecording.com/bbs/showthread.php?t=262563
I'd give 3:2 odds that dgatwood nailed it in the first paragraph, that it's actually a 44.1/48 mismatch.

If that's not it, the clock on one of the recorders has to be waaay off, to the point of being unservicable. I have done probably a dozen or so different events similar to what I described in the last post, and frankly never had drift as a noticable issue (and you know how picky I can be about the tech stuff ;) ). For someone to encounter it in a 3-4 minute cut and have it be so aggregious that they can hear noticable drift in that time and noticable artifacting with a stretch function makes me think that something is actually either downright malfunctioning or configured wrong.

That said, assuming the problem is real for those reasons, the solution dgatwood describes is what I would concur with. It does require having software that lets you manually select odd sample rates, though. I'm suprised/impressed that Audacity has that ability.

G.
 
I'd give 3:2 odds that dgatwood nailed it in the first paragraph, that it's actually a 44.1/48 mismatch.

If that's not it, the clock on one of the recorders has to be waaay off, to the point of being unservicable. I have done probably a dozen or so different events similar to what I described in the last post, and frankly never had drift as a noticable issue (and you know how picky I can be about the tech stuff ;) ). For someone to encounter it in a 3-4 minute cut and have it be so aggregious that they can hear noticable drift in that time and noticable artifacting with a stretch function makes me think that something is actually either downright malfunctioning or configured wrong.

That said, assuming the problem is real for those reasons, the solution dgatwood describes is what I would concur with. It does require having software that lets you manually select odd sample rates, though. I'm suprised/impressed that Audacity has that ability.

G.

I don't know, man. My PC and drum machine don't agree on what's 120 BPM after about four minutes. And I'm pretty certain my laptop's built in sound card's clock is not very accurate at all.
 
I won't say that drift is an impossible problem, just that a) I have never had an issue with it under the pretty demanding circumstances I described, and b) if it were happening, it means IME that there's a bad clock somehwere along the line.

Some numbers:

Let's say we have a 3 minute (180 second) clip at 44.1k. let's say that that at the end of the 3 minutes it is a half-second off (plus or minus, for this discussion it's not important which way.) This equates to an error in sample rate of about 122 samples per second, or one sample for every 360 samples. That's a sample rate accuracy of one part in 360.

Sample rate clock accuracy is typically measured in *parts per million* (ppm). Quality clocks typically measure an accuracy error of under 100 ppm, with somehwere around 10-25ppm being not uncommon. The highest quality clocks used for measurement purposes typically rate closer to 1 or 2 ppm. On the low quality end, something like a Soundblaster Audigy or SB card can spec out to as poorly as 1000ppm.

There is a HUGE difference between 1 in 360 (~3 per 1000) and 25ppm. The former is about 111 times worse than that latter. Even with a Soundblaster-class interface, that would mean an error almost three times worse than even the worst sound card spec.

Let's turn it around the other way. In a very worst case scenario of a 1000ppm inaccuracy (1 sample in 1000). Over the same 3 minute run, that would be a drift of 0.18 seconds. OK, I admit that's pretty bad drift - certianly far more than I have ever expereinced, but I guess theoretically possible by the numbers.

But that's absolutely worst case, at least by the spec'd numbers. How about a quality converter that comes in at 25ppm? is equates to 1 sample in 40,000). This comes out to a drift of about 198 samples in three minutes, or less than a half a millisecond in three minutes (less than i/6th of a millisecond in one minute). A 10ppm clock would be 2 1/2 times better than that, even.

As far as your BPM readings, my question there would be how much they are calculated against your sound card clock and how much they are calculated in the software itself. The more it's done in software, the more CPU loading and interrupts will cause inaccuracy in the reading. I don't know the answer there in your case, but it is another possible factor to consider.

G.
 
Last edited:
I've got a bit of a project to compare some clocks, namely, the Focusrite Saffire, the PCMCIA SoundBlaster, and the laptop's soundcard's clock. If I remember, I'll post some results.

In the 120 BPM case I mentioned, that would have been the difference between the drum machine's clock and my old PC's internal soundcard clock.
 
I've got a bit of a project to compare some clocks, namely, the Focusrite Saffire, the PCMCIA SoundBlaster, and the laptop's soundcard's clock. If I remember, I'll post some results.
That would be an interesting post/thread! I'd also be curious at that time as to what your measurement methods actually were.

Here's a thread from a couple of years ago that is related and makes some interesting points along the way:

http://www.nitehawk.com/sm5bsz/linarch/linarch02-03/msg01002.html

G.
 
That would be an interesting post/thread! I'd also be curious at that time as to what your measurement methods actually were.

Here's a thread from a couple of years ago that is related and makes some interesting points along the way:

http://www.nitehawk.com/sm5bsz/linarch/linarch02-03/msg01002.html

G.

It's a byproduct of trying to calibrate StroboSoft. It finally occurred to me that the most accurate frequency standard I have sitting around the house is 60 Hz hum.

I do know that when I tune with the different interfaces, I get different answers.
 
The content here is musical theatre, and it's not rock, so it's often quite difficult to hear any of the percussion.

I'm thinking there must be an ever so slight clock difference... it's also possible I've got a phase problem.
 
The content here is musical theatre, and it's not rock, so it's often quite difficult to hear any of the percussion.
Finding *something* to use as a reference point shoud not be difficult. The swell of applause between acts, someone coughs in the audience, the theatre actor's boom of a long "O" sound or the over-annunciation of a "t" sound either in a speech or singing, a particularly dominant chord or accent in the score, etc. It doesn't matter what it is or where in the soundtrack it happens; whatever you can isolate and ID in both tracks as a point to line them up with each other.

The question is whether things stay in sync after that, and for how long. One thing that may help is to simply mark points in each soundtrack where there is a break in the sound or action; during set/scene changes just before the orchestra kicks in or just after it's done but before the first actor speaks, at a pause in the dialog in the middle of a scene, etc. Cut the clips at those points and use them as places where you can slightly re-adjust thes tracks' relative position to each other to bring things back in sync.

Or, better yet, follow the instructions that dgatwood gives in that thread that apl links to above.

If none of that seems to work for you, you might just have too much "room" in the room mics. Have you considered simply using the sound board recordings, and bringing up the room mics only for orchestral segments and audience applause?

G.
 
Back
Top