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 :)

1 frame offset between slate and cam TC

Sean, the SB-3 only supplies timecode, correct? The Epic does not derive sensor timing from timecode. So the sensor timing is asynchronous to the update of your slate's display. If you were to use a sync source that supplied genlock and then used the sensor sync->genlock selection you would see the TC in R3D match the slate all the time.

Is this where the problem lies with the Pix240 recorders and if so will it be the same issue with the proxy module announced at NAB ?

I lost a whole night shoot last year due to genlock/sync issues - which was rectified in a later build. So is the definitive advice now to use genlock to sync as this is the advice I took last year that screwed me up?
 
I'm on a shoot now with two Epics, both running firmware 4.0.10, and both connected to Lockit boxes. Master clock is a SD-744T, which they re-jam twice a day. When I auto-sync shots in Resolve, they are sometimes 1, sometimes 2 frames off, and sometimes perfect. Not a consistent offset. Is this a known problem, or should I be contacting RED?
The Lockit boxes should do it provided you're also using genlock. If it is off, then my advice would be to have the assistant editor check clap sync and make sure it's absolutely perfect. This takes 10 seconds per shot, jumping ahead in the timeline -- literally an hour to check hundreds of takes.

I don't advise syncing within Resolve -- I think it works better within your editing program, because of the need to export OMF's for the final mix. If it's just for dailies, my tactic is to just send the camera a mono mix and use the audio embedded with the image. That's also a perfect reference for whoever is syncing back at the editor's room. You have three ways to sync: sound from camera files, timecode on audio (matched to picture), and/or timecode slate. All three are nice to have.
 
TC is a strange thing, invented by Aaton long long time ago.

Not that it's important in the least, but time code as we know it and use it was developed by EECO in the late 1960's, and adopted and standardized by SMPTE later on. Aaton did come up with an optical "time code on film" system in the 1980s that was used for both sound synching and frame identification, but that doesn't mean they "invented time code."
 
You have three ways to sync: sound from camera files, timecode on audio (matched to picture), and/or timecode slate. All three are nice to have.

And in my (and probably your) experience, neither timecode on audio nor timecode slates are particularly accurate, with the slates being the less accurate. But all need to be hand checked if proper sync is to be ensured. And all are less accurate than banging sticks...
 
And in my (and probably your) experience, neither timecode on audio nor timecode slates are particularly accurate, with the slates being the less accurate. But all need to be hand checked if proper sync is to be ensured. And all are less accurate than banging sticks...

Agreed. Timecode gets us close in an automated fashion, but the every take is verified by eye and ear and slipped accordingly.

Michael
 
Thanks for the tips guys.
Marc, what's wrong with syncing in Resolve? I don't have much experience with OMF, but is it harder to export one if the audio was synced before coming into Avid? And if you're cutting in Premiere or FCP, there is no timecode auto-sync feature, so that's a big plus for Resolve.

When making dailies on set, I also would prefer to record a mono mix on camera, but if the film's budget doesn't include wireless hops, then it's pretty quick to sync in Resolve, and I think the editors appreciate that too.
 
Back
Top