Major Sync issues

[Simon N]

When I place the epic clip on top of the pix clip they are then sync together using timecode. At present we are getting most slates to sync with each other. However we are getting maybe 2 takes out of 30 that even though the timecodes match the pictures do not. The remedy is to slip the r3d back 1 frame but this is not a viable long term solution.

[Matt Mayer]

Wow, quite a bit of good information here. It sounds like Simon is on a good track with all your help.

Remember that the PIX Sync and TC generator is essentially an Ambient Lockit built into the PIX.

It looks like Shane's workflow nails the recommended operating procedure, there isn't much else to add there.

[Matt Mayer]

When I place the epic clip on top of the pix clip they are then sync together using timecode. At present we are getting most slates to sync with each other. However we are getting maybe 2 takes out of 30 that even though the timecodes match the pictures do not. The remedy is to slip the r3d back 1 frame but this is not a viable long term solution.

Interesting.

The only other method I can think of to check sync would be to get a smart slate and connect it in reader mode to the TC output of the PIX. Shoot the slate with a fairly high shutter--to get rid of LED smear--and compare TC displayed with file timecode on both devices. That might get you closer to understanding which device is a frame off.

Two notes:

1) If you use a Dencke TS-3, set it for +1 frame mode. Denecke slates don't display a timecode frame until all 80 TC bits have been read--Ambient Slates will display the frame as soon as it reads it in the TC word.
2) You will have to take into account the processing delay of the picture from imager to SDI out. This is the same reason why you have to slip the PIX video two frames relative to the R3D files to begin with.

[Patrick Tresch]

I had to put -3 Frames in the file start TC offset of the Pix to get perfect synch. R3D/PIXfiles.

Now, when I shoot HDRx the Camera looses Synch(RED color) and Gen... Any one experience this issue?
Pat

[Tim Sutherland]

Sounds like the problem is you're comparing the time code in the camera to visual reference on the slate. As far as I know, the slate isn't getting genlock, only time code, right? So the visual time code on the slate may be half a frame off and look one frame off, etc. sounds like a phase issue with the scrolling numbers.

Did you try this with actual sound instead of slates and picture only? Do 30 clips of a load close sound like a clap or slate stick hits, then listen to the sound with picture and see if it works.

As said before, numbers on the slate are to get you in the ballpark, the hit is what really matters. Does it sound correct? If its really a frame out you will probably notice.

Testing with visual time code only is not a real world test, since that's never going un your movie, they always cut that part out. That's why I'm suggesting a real sound test, to see if it works how it has to in the production.

If the epic and pix recordings march, it could be that your user error is in the type of test being performed, that it is not a realistic expectation. Especially if clips go out one frame and then come back in, that doesn't make any sense. Also try over a few hours, 5 minutes is a very short time determining if there is a time ode drift somewhere.

Tim

[Shane Kelly]

I had to put -3 Frames in the file start TC offset of the Pix to get perfect synch. R3D/PIXfiles.

Now, when I shoot HDRx the Camera looses Synch(RED color) and Gen... Any one experience this issue?
Pat

That make sense as the pix is getting its video signal over sdi which has a delay. I have mine set at -2 frames.
I'll have to test the hdrx issue.

[Dave Winder]

Sensor sync is not supported when in HDRx.

[Patrick Tresch]

Sensor sync is not supported when in HDRx.

Thanks for your input Dave,

I'm using the Genlock synch and not the sensor Synch. Is there any other solution to have Synch in HDRx mode?

Pat

[Dave Winder]

Patrick, sorry, but unfortunately no.

[Simon N]

The issue is possilbly being caused by the camera not liking a contstant sync into it via lockit boxes. jamming the camera and leaving it to free run has produced realtively stable results not perfect but getting better.