ntsc drift TIMECODE - Main Timeline not in sync with External Timecode

[joeartist]

I am working on a project and receiving timecode for show control. When timecode is being received, the main timeline does not sync with the external timecode. There seems to be some drift. Both the video file, timecode, and wo settings are all 29.97 NDF. Not sure why this is, hoping someone might have some input. 

 

Thank you,

Joeartist

[jfk]

Sounds normal.

The timeline is calibrated in clock / stopwatch time, not timecode time. With NTSC 29.97, drop or non-drop, the timecode time will NOT match clock / stopwatch time - that inaccuracy is inherent to NTSC timecode.

If you want to see timeline position in NTSC timecode format, add a status timeline position display, double click on the time readout, and change the display to the matching timecode type.

[RBeddig]

There was also a bug in an earlier version of WATCHOUT 6 (don't remember which one right now) where the incoming timecode and the WATCHOUT timeline position could be off by a few seconds with NTSC timecode. This was resolved shortly after so make sure that your WATCHOUT version is quite up-to-date.

[joeartist]

Thank you JFK and RBeddig for you help. 

 

We have been able to achieve stable timecode input into watchout. It turns out that the timecode plugin for Ableton was wavering based on tempo, Watchout did not like that and we have moved to using a striped audio track.

The new issue we are having is the sync between the video track and the striped audio track sending the timecode from Ableton. The video track in Watchout is consistently ahead of the music click track that is playing along side the timecode. 

Specs:

29.97 NDF (setting in watchout)
Striped audio file 48k, 8bit, 29.97 NDF (playback from Ableton)
29.97 NDF (video file)
WO 6.5
 

We are considering getting both the Ableton computer and the Watchout computer synced on an external clock source. 
 

Any thoughts would be appreciated. 

EDIT:

After further testing, there seems to be about a 2 second discrepancy between the audio click track and the video playback in WO. WO is ahead.

 

 

[RBeddig]

I just checked that we had something similar on a project with LTC @ 30fps and WATCHOUT 6.4. In this version, all incoming timecode was interpreted as 25fps and WATCHOUT was appr. 4 sec. ahead of the timecode while the timecode tester app in the WATCHOUT folder was accurate. This behavior was fixed in 6.4.1 and versions before 6.4 were not affected either.

[joeartist]

That is interesting. It seems that is the exact issue we are running into, about 2 seconds ahead for us. 

We tested last night with Watchout set to drop frame rather than non drop frame and this seemed to align the visual with the audio. Very strange since everything has been build around NDF. 

We run the show tomorrow and I will report back if this fixed the issue. 

 

 

[Nojbi]

Hello

I have the same issue on version 672. With nondrop TC it goes even 3sec ahead on main timeline against timecode tester.

Is there any solution for that? I can't change the codes as they are provided by music band ...

Thank you

Jan

[jfk]

14 hours ago, Nojbi said:

Hello

I have the same issue on version 672. With nondrop TC it goes even 3sec ahead on main timeline against timecode tester.

Is there any solution for that? I can't change the codes as they are provided by music band ...

Thank you

Jan

There is no error shown in your sample screenshot. i.e. Above would be correct if the Status Window - Main Timeline Position is in its default timeline time display.

SMPTE NTSC 29.97 both drop and non-drop time code time never match real time. NTSC time code is always short of real time although drop frame has a much smaller error. The amount of error increases with time. On the other hand, SMPTE EBU 25 will match real time.
As a double check on what is shown above, I used a time code converter to convert SMPTE NTSC 29.97 NDF 56:03.20 to SMPTE EBU 25. Comes out the same as the WATCHOUT screenshot above.

Note: the Main Timeline Position display can be changed to show time code format of your choice.

The tool linked above will allow you to upload the list of SMPTE times and convert them to a close approximation of timeline time.

[wiesemann]

Have used 25fps timecode coming from an audiotrack of a mp4 played on an iPad. There is an offset, which means you will have to somehow find the real start of the program.

I used TC from 09:59:20:00 or so to keep some time for synching. One can hear the jump to 10:00:00:00 and use that as reference.

[Nojbi]

On 10/26/2023 at 4:09 PM, jfk said:

There is no error shown in your sample screenshot. i.e. Above would be correct if the Status Window - Main Timeline Position is in its default timeline time display.

SMPTE NTSC 29.97 both drop and non-drop time code time never match real time. NTSC time code is always short of real time although drop frame has a much smaller error. The amount of error increases with time. On the other hand, SMPTE EBU 25 will match real time.
As a double check on what is shown above, I used a time code converter to convert SMPTE NTSC 29.97 NDF 56:03.20 to SMPTE EBU 25. Comes out the same as the WATCHOUT screenshot above.

Note: the Main Timeline Position display can be changed to show time code format of your choice.

The tool linked above will allow you to upload the list of SMPTE times and convert them to a close approximation of timeline time.

Hello, one thing is what it show in the display and the second thing is what it does in the timeline, so if my video on the timeline is approx 3 sec ahead of what is expected then it cant be used ...

I finally found workaround so I have app which has realtime conversion between formats and so it goes via another software which accept it ok and generate LTC in 25FPS  and then it works also in watchout. But it is more than weird and it was some extra costs and extra pieces in the way ...