FCP / Logic Timecode problem

Hi. I'm working on a project with a sound designer. I've supplied my project with timecode on it @25 fps from FCP and he is working on the audio in Logic. He says the timecode is out of sync with his timecode in Logic, there's a lag that develops over time. He shared a screenshot which is half a frame out of sync and his timecode from Logic has an extra 2 digits, but I don't understand what these are or mean - for example:

My timecode says: 00:07:16:01 but his timecode says: 00:07:16:00.51  

Has anyone come across this issue? I'm searching but can't find a solution online. Thanks

There are various ways to display the same timecode. The SMPTE timecode standard mandates HH:MM:SS:FF, where FF = frame number. This is for both video cameras and audio recorders.

Audio recorders don't literally record frames, but samples. However the encoding and interpretation of timecode must be compatible across all devices. So the timecode metadata recorded by pro audio and video devices is HH:MM:SS:FF.

Both NLEs and DAW software can *display* that timecode in different formats. E.g, FCP can display it several ways, which is configured in FCP Settings (or Preferences)>General>Time Display. FCP resamples the audio and can display that in 1/80th subframe resolution.  But it's not recorded like that and it doesn't sync using that -- it is a calculated display from the HH:MM:SS:FF timecode metadata.

Likewise, pro audio recorders have various timecode display formats, but this is for display. It does not imply they are recording timecode metadata in some other format.

In the case  you gave, it appears the audio recorder is configured to display timecode in DD:HH:MM:SS.ss, where DD = days and ss = fractional seconds. This should not affect syncing by timecode, since the underlying timecode is HH:MM:SS:FF.

By default FCP displays HH:MM:SS:FF, where FF = frame number within the current second. The same clip in FCP can be displayed other ways, as seen in the menu FCP Settings (or Preferences)>General>Time Display. 

If it is drifting over time between the two devices, there are several possibilities:

1. Video is 23.98 or 24.0 fps and the standard rate conforming algorithm for a 25.0 fps timeline is the NLE will retime the 24 fps clip (audio and video) to run slightly faster. If there is other outboard audio which is not similarly retimed, they will drift apart. In that case consider using a timeline frame rate that matches the clip frame rate.

2. If the video is not the correct DF/NDF setting, it can drift apart from other media. 23.98, 24.0 and 25.0 are always NDF (Non-Drop-Frame), whereas 29.97 and 59.94 are usually DF (Drop Frame) but some cameras can be configured to record those as NDF. If you have 23.98 NDF and 59.94 DF, they will drift apart. There may be similar settings in some audio recorders, even though they record in samples. This isn't about the media recording rate but the rate and format of timecode metadata recording. Use a metadata inspection tool such as Invisor to examine each media file:   apps.apple.com/us/app/invisor-media-file...or/id442947586?mt=12

3. IF the time bases on the two devices are running at slightly different speeds. The timebase is generated from a quartz oscillator, and those can vary slightly, especially on cheaper devices. It's not unknown for two devices to drift apart a few seconds per day, which would become apparent as a lip sync issue on a long interview.

The first thing I would suggest is configure Logic's time display format (in the transport bar) to HH:MM:SS:FF. That should be universally applied to all media types. Then see if after syncing the video and audio clips by timecode if they stay in sync, or at least start out in sync as indicated by the timecode display.

All this should be second nature to an audio engineer. They normally deal with this kind of thing frequently.

Thanks for taking the time to reply & for all this information. Everything was shot, edited & exported at 25fps so I’m sure it’s not no1 or no2. I’m checking everything and will speak with the engineer to see how his system is set up, I’ll feedback when I know more.

One quick question - because of time constraints I supplied the video for him to work with as mp4 not mov, could the mp4 compression be causing an issue & knocking the timecode out of slightly out of sync?

Thanks

If the two devices were jam synced, it is not uncommon for timecode to be half a frame or one frame off. Timecode is an audio waveform that must be decoded by circuitry on the receiving end. The receiving hardware logic is supposed to compensate for the decoding latency by "fixing up" the timecode data, but this does not always happen perfectly. This issue is discussed in the book "Timecode A User's Guide", by John Ratcliff, under the subheading "Adjusting for the decoding delay".

Rather than jam sync, if continuous timecode is fed to both recorder and camera, they can still drift apart over time. This is because timecode is not genlock, a separate signal that locks the devices to the same frame rate. 

On higher-end cameras and audio recorders, e.g, Sony FX6, Sound Devices MixPre series II, etc, they use a temperature-compensated quartz oscillator that has low drift and will typically stay within one frame for several hours. External timecode devices such as Tentacle Sync E also have low-drift oscillators.

In your case if the audio and video are drifting apart, is that seen on your end or just by the sound guy? What is the rate of drift? IOW if it starts out in sync, after 5 minutes, 10 min, etc, how far out is it? The rate of drift can provide clues about the problem source.

Re you sending him MP4, providing his software can read the timecode, it normally should not be affected by MP4 compression. The main problem with MP4 is inability to read the timecode because the MP4 container format never adopted a standardized metadata layout for timecode.

If the two sources drift apart fairly rapidly, that can be caused by a DF/NDF issue or a 24.0 fps to 25.0 fps rate conforming issue. If both camera and recorder were set to 25.0 fps AND the timecode source on all devices was also set to 25.0 fps, that should not happen. If external timecode devices were used, those must be set to the same frame rate and DF/NDF setting as the camera and recorder.

If the two sources drift apart slowly, that can be caused by lack of precision in the timebase on one or the other device. E.g, two quartz watches will gradually drift apart. Actual surveys show some quartz watches drift by 2 sec per day (much worse than the spec), so two watches with opposite drift could move apart at 4 sec per day. For two audio recorders or cameras, this equates to 100 milliseconds per hour, easily enough to cause a lip sync issue on longer programs. The same type of quartz timebase is used on lower-end cameras and recorders.