-
timecode differences between long and short clips made from the same recording
I am working on a tv-show with 3 XDCAM camera’s whose timecode are connected and identical. All camera’s record continuously for about 30 minutes (XDCAM PAL, 50 MB/sec). I use to import the three clips with XDCAM Transfer and put them into a multiclip.
Since a few episodes there is an annoying sync problem: in the beginning the three angles are exactly in sync, but after 30 minutes there is a difference of 3 frames. I never saw this before.
I tried capturing through a Decklink card to see if the problem goes away; but it didn’t.
So I thought, there must be problem with the recordings (perhaps the internal clock of one of the camera’s), as I don’t see how timecode data can be altered during file transfer.But now something very weird occurs: when I capture just the very last part of the recording (through SDI), where I would expect the sync difference to be the largest, instead I find that the three angles are NOT out of sync at all!
And when I compare the timecode of these small clips to those of the large clip, I find there is indeed a three frame difference between them.
It is not an incident – I could replicate it. It seems to happen with certain recordings, not with others.I have no clue what is going on. How can it happen?
OS 10.6.3
FCP 7.0.2
2x3GHz Quad Core
5GB -
9 Replies
-
Sounds easy enough.
There are some added or dropped frames in some of the angles.
Could be bitrot…Only way to find out is to have a very good look at the material.
Bouke
https://www.videotoolshed.com/
smart tools for video pros -
“Bitrot”?
Anyway, I turned on the character generator on the XDCAM player and I can see now that at certain points the TC on the xdcam is jumping one frame ahead.
So, probably not a FCP issue, but rather a camera that has a problem keeping track of the timecode forced upon it?
-
[Jaap Verdenius] “”Bitrot”?”
als betonrot, maar dan digitaal…
Are you sure the TC is jumping but NOT the video?
I can’t imagine the TC jump, as TC is saved in two ways:
The XML contains starting TC (probably used for QT TC on QT wrapped files)
And it’s saved in each GOP header.
(If you shot SD it’s each frame.)
This is probably where the player gets it’s info.Now if the TC jumps / stalls, make sure it’s not the video also!
If you are sure your video is correct, the fix is easy.
In FCP, use ‘change timecode’ to add a fresh TC track (of course with the same numbers!)hth,
Bouke
https://www.videotoolshed.com/
smart tools for video pros -
Yes only the TC is jumping, not the video. Really. I can see it clearly on the XDCAM deck.
But this jump is not noticed as a TC break by FCP.
I just took the recordings to a colleague with a Media Composer – exactly the same thing there!I think what happens is the master camera is running faster than the other ones, who (in order to stay locked) skip one frame of TC. So one camera produces 15,000 frames in 10 minutes, the other one 14,998 – but after these 10 minutes they run exactly the same TC, thanks to the TC jump.
And the fix for this is not that easy, because these camera’s don’t produce the same amount of frames within one time interval. You can’t solve that with a new TC track, you can only compensate making various multiclips with different sync points, that are sync only during a part of the recording.
-
Aha.
Now we’re getting somewhere.
You have shot with one master cam and had the other cams TC slaved, but not genlocked?(insert wise remark about ‘lesson learned’ here)
Then my theory goes. FCP only reads the first tc and calculates the rest.
No way of altering that in a simple way, as QT cannot have TC breaks.
(you could however stretch the TC track, extract the TC in QT pro, trim two frames off the end, copy it back in with “add to selection and scale”)But if the actual frames are off due to differences in running time,
you have found the solution…Bouke
https://www.videotoolshed.com/
smart tools for video pros -
Well I didn’t shoot this – it’s a different company.
How can a camera be “slaved but not genlocked”?
-
‘slaved’ means the TC is in external, and accepting incoming LTC
(timecode)‘genlocked’ means the cam is locked to an external reference signal, and MUST use that clock(reference signal, aka black burst)
The latter obviously did not happen.
So, fix is easy but time consuming, blame the shooting company and ask, in a good traditional Dutch way, for more money 🙂
Bouke
https://www.videotoolshed.com/
smart tools for video pros -
Bouke,
Assuming that you are right, can you also explain why this problem surfaced after seven years, or to be more precise: after the switch from Digibeta to XDCAM? Because I have no reason to think that they changed their methods or recording – probably things have always been slave-but-not-genlocked.
I know it’s their problem, but I’m just curious.Thanks,
Jaap
-
[Jaap Verdenius] “Assuming that you are right,”
Nope, i AM right. (Unless i’m wrong, happens less 🙂
Cause the XDcams cost roughly 1/3 or less of a digibeta cam?
Really, no idea. Things break down and/or don’t work as expected / advertised.
Ask the shooters, it’s their problem, not ours…Bouke
https://www.videotoolshed.com/
smart tools for video pros
Reply to this Discussion! Login or Sign Up