Major Sync issues

[Marc Wielage]

The issue we still have though is that we have done a lot of tests and if we take the last one which was 25 clapperboards (seperate takes) takes 1 2 & 3 were 1 frame out when we came to match picture. This was done by syncing the r3d & the pix mov via timecode and match framing. I know this is an easy fix in post, but it would be better to get it right at our end. We then had 22 takes rock solid. Nothing changed and the 25 takes were done within a 5 minute period.

I have a question:

If you feed sound to the Epic, then take the R3D file, debayer it through RedcineXPro it to the same format as the Pix, then load up both files into your editing programs, are the files identical?

In other words, can you determine where the error is happening? Is the Pix wrong and the Epic is right, or is the Pix right and the Epic is wrong?

Me personally, if it were 1 frame, I wouldn't care in post and I'd just tell the assistant editor to fix it. The key for me would be, the Pix file has to be 100% identical to the Epic file. Without that, all bets are off.

If the Epic file is 1 frame out of sync with the Pix file, then you could potentially have a massive problem with the conform. What I think is happening is, you have a non-referenced timecode phase issue where at certain times, the timecode number slips over to the next frame. I have seen this happened with two non-genlocked cameras, particularly in 3D situations.

Also, are you basing sync on numbers on a timecode slate? Shutter speed (angle) can affect how the pickup "sees" the timecode number, so certain numbers may be interpreted differently on two cameras, side by side. This was -- and is -- frequently a problem in film post, and is one reason why we use the clap as "real" sync, and only use slate numbers to get us close. The clap is real-world sync, held as an absolute.

I'd also be curious to see what would happen in an all-23.98 situation. I've only done shoots and post sessions with 23.98 material, so there's always the possibility that something is a little off in a 25.00 world.

[Simon N]

In some earlier tests the method we used was to transcode the r3d's via redcine to dnxhd36. Due to the time it took to transcode, we did not do exhaustive tests but it appeared that the transcoded files from red cine & the r3d's matched.

I am thinking it is some sort of phase issue as there are takes in the test that are fine and others are not. I have made a short video demonstrating my exact workflow and the resulting clips sync together and compared. If anyone wants to look and tell me where I am going wrong
http://www.youtube.com/watch?v=fygyx...ature=youtu.be

I'm not an engineer, however I am wondering if it is something within the camera relative to 23.976 because at the most stable setting we can achieve, camera sending timecode via the sdi then our fail rate is between 1 & 3 in 25 slates. to my non engineer mind, if there is something strange referencing 23.976 (or 24fps for that matter) then the fail rate seems proportional to that.

There is another user in the Redcine X forum having similar issues at 25fps, though not identical they have flagged up the fact their timebase is 25fps

Any thoughts GREATLY appreciated as we start shooting at 8pm this evening !

[Simon N]

I have just tested at 23.976: I still get mismatched frames with identical timecodes throught the tests except when I generate timecode to the pix through the SDI, i.e I have sent timecode from the Pix to the camera, different margins of error per clip. I have sent timecode via LTC to the pix from the camera, again some clips in sync others out, but when I test generating timecode at the camera by jam syncing the camera to an external timecode then sending timecode to the PIX down the SDI, I do not get any inconsistencies in the results.

My only concern about looking into the 23.976 too deeply is that I did 15 tests via sdi timecode, and whilst all were accurate, the previous test at 25fps yielded 1 error out of 25 so my sample of 15 may not have been big enough to make a definitive judgement.

We start night shoots in a coupld of hours so am running out of time to test further.

[Greg M]

well, I would try what I suggested earlier. Use the 788 as the master clock only and just use the pair of PIX recorders as recorders only with only an SDI input.
This is the way we work and have not had issues.

[Shane Kelly]

Simon, I just did a test with the epic and pix at 25fps timebase. shot 19 clips, all were in sync.
here's my settings:
pix:
video input: SDI
file resolution/Rate: 1080p25
codec: prores422HQ
input Psf detect: AUto

TIMECODE/SYNC
Timecode mode: Freerun
Drop Frame enable: off
sync out: 1080p25
Timecode BNC: Timecode output
autorecord hold off: 0sec

File start TC offset -2 frames

On the epic.
gpio menu
Camera input: sync in
camera output: general purpose out
sync mode: genlock

under project/settings/timecode I have "timecode source" : external

I'm using the red sync cable to jam the camera from the pix. SdI cable runs back from the camera to the pix.
The differences that I can see compared to your video are in order of appearance in your video:
you have camera output set to sync out, I have it set to general purpose out
on the pix, you have file resolution/rate set to same as video input, I have set this up as 1080p25.
I'm recording prores instead of avid although this shouldn't matter.


My suggestion would be to first turn off the sync out on the camera, then set your resolution on the pix to 1080p25.
Good Luck!

[Simon N]

well, I would try what I suggested earlier. Use the 788 as the master clock only and just use the pair of PIX recorders as recorders only with only an SDI input.
This is the way we work and have not had issues.

That's what we will try later onl.. the only piece of kit I don't have access to to test is the 788. Did you see my video and if so did anything strike you as odd?

[Simon N]

Thanks Shane.

I have just done 10 clips and had 1 error. This is the first time I have achieved this sort of consistency using the pix to drive the timecode directly. I am going to try and do 30 tests but I start shooting in an hour. I'll report back

[Simon N]

this time 30 clips.... 2 errors in the 30. Vast improvement. Thanks for help so far. Will be testing again whilst waiting for it to go dark - vampires & all that type of stuff. Any further thoughts appreciated. Will report back re 788 success rate.

[Dave Winder]

Possibly a bad cable?
I assume you have one on each camera?

Just so we are clear, is the problem a visual match with the slate or have you tried actually syncing in post?

Have you selected jam sync in the menu?
Do you have the green sync indicator in camera?

The SYNC icon has nothing at all to do with timecode, it indicates that the sensor timing is synced to a Genlock signal. Whether or not the camera has been jam synced on this boot is shown by the TC icon being green.

The symptoms the OP is complaining about, are from the external audio recorder. As a test, if you like, run audio out from your mixer and into the camera as scratch track. You will see that it is always lined up and the external audio track wavers around.

[Christopher Mills]

If your project needs to have matching synch on all recording devices, there is a common way to do this, but it will involve 2 additonal pieces of hardware (and a 3rd one would be better)
Get 2 Ambient Lockit boxes, or 2 Dencke SB3 (Or SB-t) boxes , jam them to the 788 TC twice a day (or get a Denecke gr-2 for a production master clock, and jam the 788 and the lockit boxes to it).. Then put them full time feeding the camera's TC input..
this works well, and is very stable.

If you need very high accuracy,this is better than jamming the cameras and removing the box.... in theory a studio set up could use multiple TC feeds to the cameras and audio recorder from a *SINGLE* TC master source...
let the Pix recorders read the SDI embedded tc..