Timecode slipping from compressor output to premiere sequence (24P/23.976?)

[Angelo Lorenzo]

Premiere treats 23.976 as 24 and displays full non-dropcode timecode.

While we get the number 23.976 from inverse telecine from 29.97fps video, it’s not subject to dropframe timecode which is specific to NTSC at 29.97fps and you’ll see why from the quote below.

24fps timecode is only an “approximation” of real time for 23.976fps, and there is no official drop-frame version of it.

It also sounds like this might be a bug with Compressor (from 2009, but who knows if it’s ever been fixed; there are steps to recreate and confirm) https://discussions.apple.com/thread/1872384?start=0&tstart=0

This is a quote from wikipedia:

————————-
Drop frame timecode dates to a compromise invented when color NTSC video was invented. The NTSC re-designers wanted to retain compatibility with existing monochrome TVs. However, the 3.58 MHz (actually 315/88 MHz = 3.57954545 MHz) color subcarrier would absorb common-phase noise from the harmonics of the line scan frequency. Rather than adjusting the audio or chroma subcarriers, they adjusted everything else, including the frame rate, which was set to 30*1.000/1.001 Hz.

This meant that an “hour of timecode” at a nominal frame rate of 30 frame/s was longer than an hour of wall-clock time by 3.59 seconds, leading to an error of almost a minute and a half over a day. This caused people to make unnecessary mistakes in the studio.

To correct this, drop frame SMPTE timecode drops frame numbers 0 and 1 of the first second of every minute, and includes them when the number of minutes is divisible by ten. This almost perfectly compensates for the difference in rate, leaving a residual timing error of roughly 86.4 milliseconds per day, an error of only 1.0 ppm. Note: only timecode frame numbers are dropped. Video frames continue in sequence. i.e. – Drop frame TC drops two frames every minute, except every tenth minute.
———————————–

[Angelo Lorenzo]

Oddly, it does seem like a timecode drift, as 12 seconds every 4 hours works itself out to 1 frame every 1000 (approximately). I wonder if iMovie/Compressor is burning in wall-clock time and not actual timecode.

Does FCP have a “timecode overlay” effect? You could try burning in TC as 24 or 30 non-drop frame, as Premiere can monitor a 23.976 timeline as either. It would remove whatever funkiness Compressor is doing by burning in a true timebase.

It may even be worth burning in a true frame count. Frame 275 is frame 275 no matter what the timecode or playback rate.

[Cassidy Clawson]

Thank you very much for the information. It’s fascinating.

I think I am experiencing both Compressor bugs that are discussed in that thread … the drift of ~3 seconds per hour AND an inaccurate start time in the export.

From now on I will do this type of time coding with frames FOR SURE.

Problem is… one of our writers made a very nice story edit in iMovie using our proxy timecoded 5 hour video as her source material. The plan was that I could watch her edit, see the timecodes of the cuts and rebuild the edit in premiere from the corresponding 5 hour sequence (where we have all the good video tracks and audio sync’d).

It takes a lot more work when the time is off and I don’t see an easy way to fix this given our current position. Oh well.

Timecode is something so critical and precise that a bug is inexcusable. I could care less about the dropped frames or deviation from wall clock… it just needs to be the same across applications and exports!

Thanks again. Any additional ideas appreciated.

Cassidy