Tentacle Track E audio almost in sync.

I've been working on a few projects, shooting with BMPC 6K pro . Audio is recorded to camera with a decent on board mic or boom and frequently subjects have a track E recorder with a lav. Camera has a tentacle for TC and the track E is synced with camera tentacle for TC. Here's the issue- when syncing with time code, the track e file is always ahead of camera, by some variable amount of sub frames, which might be as low as 7 and as many as 25, but its always ahead. I theory synced TC should take care of this but it seems that it does not. If I sync by waveform the results tend to be better, if not perfect, however in situations where camera scratch audio isn't great or recorded in a noisy space, then sync by waveform is less reliable. The issue is correctable, nudge the errant track X amount of sub frames to match, but isn't out of sync audio  what synced timecode is supposed to prevent? 

I've seen about 3-4 frames variable sync when jam-syncing from Tentacle Sync E to a Sony FX6 and using the Track E recorder. But not 7-25 frames off. Note in this case I wasn't using Tentacle's LTC audio timecode, rather just did a one-time jam sync of the FX6 camera via 3.5mm to BNC cable. The Tentacle Track E and Sync E were first synced via the iOS app.

I did not see this when using Tentacle Sync E as a continuous timecode source to the FX6. That is our normal procedure -- there is a dedicated Sync E on the Sound Devices audio recorder and on each camera. In this config Tentacle is not writing audio LTC timecode to one side of an audio track, but continuously providing "file timecode" metadata which is silently recorded by the camera. When doing that the Track E recorder synced up OK with the other devices, although I haven't tested that in a while -- we normally don't use the Track E but wireless lavs.

Regardless of mode, each camera and recorder should generally be at the same frame rate -- including DF/NDF. By definition 23.98 and 24.0 are NDF (Non Drop Frame), whereas 29.97 and 59.94 can be either DF or NDF. So normally if they are all at 23.98 the NDF setting is automatic. However if you have a gimbal camera at 59.94, then it must be set to NDF otherwise the timecode will not match up.

On Blackmagic cameras, sometimes the project frame rate and sensor frame rate are not set properly. Make sure those are set as you expect, as otherwise it can cause various timing and sync issues. This often happens when the HFR (High Frame Rate) button is accidentally pressed.

The tracks are out of sync 7-25 SUB frames, not frames.  Tracks are  enough out of sync to be audible though not horrible. The sync issue is correctable in X or in Fairlight, it's just annoying and it has not been that consistent either. Sometimes there is no sync issue between camera audio and Track E recording.

Since a subframe is 1/80th of a frame, that implies it's off by 25/80 or less than 1/2 a frame. Is that right?

I spent a long time troubleshooting the unpredictable timecode mis-sync when using a jam-synced camera from Sync E and a Track E recorder. In my case it was a variable # of frames, but normally only 1/2 frame. However if mixing 25 and 50 fps material after jam syncing the FX6, it could be off 2 or more frames. It varied whether the Tentacle Sync E was the timecode master jam-syncing the FX6 or if the FX6 was the timecode master jam-syncing the SyncE. In FCP if I sync'd a multicam on timecode, I could use clip skimming to see the timecode values of each clip. They were in fact precisely sync'd on timecode but there was a 1-4 frame variable delay based on the audio waveform. 

I suspected there might be some variation or poorly-documented detail about latency during the physical jam sync. If you imagine plugging in the timecode cable in slow motion, the contact will do various things: it will bounce and make/break contact a few times, finally make contact at some random point within the 80-bit timecode packet. That packet is serially conveyed at about 1 to 2 Khz. I thought there might be cases where it fails to sync on the 1st packet, then it must wait for the 2nd or 3rd, which are then out of sync with the camera audio.

The SMPTE timecode spec and associated hardware design guidelines are supposed to take into account latency for decoding the timecode signal. I think each timecode decoder hardware is supposed to know its own latency and where necessary "fix up" the timecode values. It is almost impossible to find any documentation on that.

I discussed it with our audio engineer, who suggested just don't jam sync but use continuously  connected timecode. So that's what we now do, and it seems to work better. 

If I have time I'll re-test the whole thing including several Track E recorders but I'm getting ready for a field assignment so it will be a while.

I can see a couple of different scenarios. There could be some latency in the camera recording signal pathway that is not there in the track E recording . Or in the case where you have an on board camera mic for scratch should and a track E on a subject that is some distance way from the camera, there could be a measurable delay between when the mic on subject receives the sound and when the camera mic receives the sound wave. I think both of these things are possible since the offset I am seeing is within a relatively small number of subframes, yet enough to make a difference sound quality wise.

Is your BMPCC 6K Pro using (a) Continuous LTC audio TC from the Tentacle Sync E, (b) Jam-sync from the Tentacle or (c) Continuously connected metadata TC (aka "file" TC) from the Tentacle? Those are the three ways it can be used.

If continuous LTC audio TC, that requires using either Resolve (which can read audio LTC timecode) or Tentacle Desktop in post to produce an XML for FCP to sync them.

I believe the BMPCC 6K Pro can either accept jam sync from the Tentacle or stay continuously connected and if configured properly it will not record audio LTC but rather use the timecode stream to replace it's onboard TC generator. I don't know the procedure on the 6K Pro but on our Sony FX6 cameras you just look for "TC Ext - Lk" and leave it connected to the BNC TC input port. 

If you can hear on any audio track of the 6K Pro the squealing TC sound, the Tentacle is likely not providing continuous TC metadata. There may be slightly different latency behaviors for each of these cases.

On my field assignment over the next two weeks I'll discuss this again with our audio engineer. He has many years experience in the industry.  When I return I plan on re-testing all of the above in various combinations.

We may be shooting multicam with RED, BMPCC 6K Pro, and Sony FX6, and Sound Devices Mix-Pre Mk II recorders, all with Tentacle Sync E continuously connected to each, plus jam-sync our Denecke production slate. We have several Track E recorders but we usually don't use them. I don't know how many concurrent cameras yet, but this may form a natural test. I'll examine the sync closely either on site or when I return.

If you have time to throw some short clips from your shoot with various cameras into X or resolve and check audio sync I am very interested in what you find. I always have a tentacle connected to my camera and any other cameras or audio devices when shooting so my tc should be as good as it gets. I realize this is a bit of a rabbit hole but if you could compare sync on the different cameras, that might be instructive. Again we’re looking for a sub frame offset. I know that sound devices mixers have a menu item for a built in delay in milliseconds for recording, which I suppose is there to compensate for exactly this issue.