Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Automatically syncing audio with Red footage

Well, of course. But are you gonna tell 60 people, on-set, that they have to stand around and wait for that to happen it it isn't? Or just keep shooting and fix it later?

Absolutely not. But that's not my workflow. With my workflow suited to my situation I address the points you first brought up. I get sync that I'm happy with and I keep all the metadata including the R3Ds. I wouldn't recommend this workflow if there were audio drift issues.

As per the original question. Yes fcpx can do this job.

Rick.
 
Auto-syncing works in 2 circumstances: If camera audio is frame accurate, or, if it isn't, you're willing to roll the dice on work that, hopefully, no one checks (or cares about) for frame accuracy.

And that's why I never trust auto-syncing - because camera audio is, usually, in my experience, wrong.
 
Hey Richard, do you have a link to that tutorial (or to the thread you posted in). I just tried it and it definitely did not work the way I'd hope. Just made a 5 hours long clip with a lot of black frame. Similarly, what's the difference between making a multicam clip (sync by audio) and just making one giant Syncronize Audio compound clip and cutting out all the clips you need? In either case, you're left with one big file that you have to scrub through and cut/paste/trim into the timeline. The functionality of auto-syncing is really compromised by it not making independent clips (something which should definitely be addressed in a future version of FCPX)… Or am I missing something? Also, I do think it's in bad taste to not allow the user to "sync via timecode" explicitly.

Conversely, when you sync in of RCXp, it doesn't get stored in the RMD as a synced clip? That means it's really only useful for transcoded files, which seems less than ideal… But I'm trying to figure out the lesser of two evils. Use synced 4k prores files out of RCXp still seems like the easiest/fastest/best way to go and we've had real-time native r3d editing capabilities since CS5.5.

Generally how I do my audio is -- button mic directly on camera for scratch in mic1, mixed reference audio from the sound guy (via cable, or wireless if going handheld/steadicam) in mic2, and finally timecode jamming (ideally with locket box, but if the audio guy doesn't have one, then directly jamming to the camera every battery change.) Yet even with all of this, I still have to revert to a manual sync and/or manually divide to get independent and synced clips, OR I have to transcode (which wastes storage space, time, and bakes in the image). I feel like I'm missing something… or the NLEs are. I have three levels of redundancy, and have to use all three (including the oldest method of manually syncing), because they have to be linked on a clip-by-clip basis… It's kind of haggard.
 
Well, of course. But are you gonna tell 60 people, on-set, that they have to stand around and wait for that to happen if it isn't? Or just keep shooting and fix it later?
Typically, if I'm working as the mixer on set, I coordinate with the assistant camera operator and we get the camera locked and jammed to external code in the first five minutes the camera is on the mount. There may be 60 people on the set, but the two of us usually get it done in 5 minutes or less, and it's good to go for the entire day. Zero sync problems, 100% synced, zero delays on set or in post.

It's often sad but true that 5 minutes of work on the set will save you hours​ of work in post. The question is which costs you more money.
 
No question about it saving tons of time, but I've seen enough audio latency, and TC drift, to know that camera audio is usually (as in, almost always) 1-3 frames off, at least. And a good assistant editor can/should be able to sync a day's worth of rushes in under 2 hours, or half that on a one-camera shoot (depending on good slating, obviously).

On the 2-camera Alexa-shot ABC promo I did last week - every single clip with in-camera audio was off by 1 to 3 frames. Both cameras. Every single one. Got worse as the 15 hour day progressed. I wouldn't dream of auto-syncing that and handing it over to production.

Seems we might be talking about two different things here. TC is one thing but matching waveforms is quite another. Unless you are doing 15 hour takes, I don't see how you are going to get audio sample drift between your external sound recorder and your reference track. Am I missing something here? If you are matching audio wave forms from the camera with those from second synch sound - sample at what, maybe 48,000 times per second or so, how is one going to drift from the other when the software algorithmically matches them?
 
If you are matching audio wave forms from the camera with those from second synch sound - sample at what, maybe 48,000 times per second or so, how is one going to drift from the other when the software algorithmically matches them?

Because the audio that the camera recorded was 1-3 frames off. The audio of the slate sticks banging together was 1-3 frames ahead of the video of the sticks banging together. And that is what the software would be using to sync - something that's consistently 1-3 frames off.

On the shoots where I both DIT and sync, I just tell everyone to not bother with matching TC, sending audio to the camera, lock-it boxes etc. If you're fast and efficient at manually syncing in the NLE, you don't need any of it. All you need is the sticks.

And hey - it's actually right, and someone is actually checking every clip! What a concept!
 
Seems we might be talking about two different things here. TC is one thing but matching waveforms is quite another. Unless you are doing 15 hour takes, I don't see how you are going to get audio sample drift between your external sound recorder and your reference track. Am I missing something here? If you are matching audio wave forms from the camera with those from second synch sound - sample at what, maybe 48,000 times per second or so, how is one going to drift from the other when the software algorithmically matches them?
They'll drift because of timecode phase. This is why if you're in a multicamera situation, you're better off using genlock and timecode jam on each camera, using external timecode/sync boxes like the Denecke SB-T or the Ambient Lockit. Do that, jam to master timecode from the sound department every 6 hours, and you'll have sample-accurate lock all day long.

Because the audio that the camera recorded was 1-3 frames off. The audio of the slate sticks banging together was 1-3 frames ahead of the video of the sticks banging together. And that is what the software would be using to sync - something that's consistently 1-3 frames off.
It doesn't have to be. Check it once at the beginning of the day, and tell the sound department "give us X frames of delay to make sure it's right in camera," and that'll solve the problem. Otherwise, one offset should be good all day for syncing purposes. This is a trivial problem, one I've dealt with for many, many years. And we typically just synced with slate only.
 
They'll drift because of timecode phase. This is why if you're in a multicamera situation, you're better off using genlock and timecode jam on each camera, using external timecode/sync boxes like the Denecke SB-T or the Ambient Lockit. Do that, jam to master timecode from the sound department every 6 hours, and you'll have sample-accurate lock all day long.


Check it once at the beginning of the day, and tell the sound department "give us X frames of delay to make sure it's right in camera," and that'll solve the problem.


Problem being, of course, that the amount is variable (1-3 frames). Your "x amount" could just give you the same problem in the other direction (1-3 frames behind, instead of ahead).
 
The tutorials are somewhere here but the site has changed so it might take some digging. All your metadata has to be correct which is explained in the tutorials. I'll have a look for the exact one and add the link if I can find it again.

http://wemakemoviespost.com
 
Let's be clear about what we are debating here. As I acknowledged right up front, synching with time code is a different issue. And, unless all cameras and sound recorders are jammed to one accurate, master clock, yes TC can drift. But that wasn't at all what I was saying; I was talking about matching audio wave forms with each other.

Now, if I am understanding what is being said, the claim is that audio and video - on the same camera - will drift 1-3 frames in a relatively short take. In other words, if I take my footage into RCX, the camera audio and video might not match. Do I have that right? Because, I have to say that on any file based camera I have ever used, I cannot recall ever having seen the on-board audio drift from the video. And certainly not on my Scarlet. I am interested to know what camera(s) I might expect that to occur with.

My my experience has been that on-board reference audio is synched to video, so the process of matching second sound is not only frame accurate, it is sample accurate. Maybe I have just been lucky? :huh:
 
Auto-syncing works in 2 circumstances: If camera audio is frame accurate, or, if it isn't, you're willing to roll the dice on work that, hopefully, no one checks (or cares about) for frame accuracy.

And that's why I never trust auto-syncing - because camera audio is, usually, in my experience, wrong.

i must really not understand what you are saying. First, I really am not sure why you need to assure completely accurate audio synch on set. If you have good audio (per your sound guy) and good video, and you have everything slated, don't you just move on and synch sound in post? If your NLE can match your reference audio from the camera with the second source audio, as FCPX can, then great - quick and easy. Worst case, if something is wrong - usually bad reference audio - you can do it the old fashioned way- via the slate. Again, am I missing something?
 
So can one batch sync in FCPX to the R3D's then xml to Premiere or FCP7?
 
Looks like a good way to sync audio is to record in camera sound in addition to your master track. Then the waveforms can be matched and put together.

Has anyone been using this method?
 
Back
Top