Timecode is an audio track that can be interpreted by your computer or firing system as a sequence of time stamps.  Time stamps are typically written as HH:MM:SS:FF.

Table 1 – SMPTE time stamps

You can think of timecode as a recording of a fast talking human clock reader barking out: “0 hours, 0 minutes, 0 seconds, 0 frames, <short pause>, 0 hours, 0 minutes, 0 seconds, 1 frame, <short pause>, 0 hours, 0 minutes, 0 seconds, 2 frames, etc.”  The clock reader would need to be talking fast because frames are typically about 1/30th of a second.  So if the clock reader were reading every frame, he’d be talking very, very fast, with each time stamp utterance taking just a fraction of a second.

Timecode, however, is meant for computers and devices like firing systems to understand, so the audio encoding of these time stamps is in a protocol that is efficient for computers to decode, not humans.

There are several protocols for encoding timecode in an audio signal, some that are specific to firing systems or other hardware devices, and some that are open standards.  SMPTE timecode is an open standard timecode encoding that is recognized and understood by almost all timecode processing hardware, so often when people say “timecode” they mean more specifically “SMPTE timecode”.  This article is discusses the frame rates and frame numbers specifically for SMPTE timecode (see LTC details).

Frame rates

The frame rate of SMPTE timecode is simply the number of the time stamps per second in the signal.  The commonly supported frame rates are,

Table 2 – SMPTE frame rates

The SMPTE time stamps do not contain within them any explicit indication of the frame rate.  If you played a SMPTE timecode track that was recorded at 30 fps at 0.1% slower than the normal playback rate, you would have, identically, 29.97 fps SMPTE (the non-drop frame version).

The “drop frame” version of timecode, for readers who are looking ahead a paragraph or two, does not change the frame rate of the SMPTE time stamps.  Thus in Finale 3D, the “Show > Show settings > Set timeline snap-to resolution” includes only the frame rates of Table 2 and a few unrelated options; there is no mention of drop frame or non-drop frame in the timeline snap-to resolution options because the timeline, like a ruler, is delineated in equally spaced units.  A ruler is delineated in 1/16th inch units on the imperial side and millimeters on the metric side.  The timeline is delineated in milliseconds by default or the snap-to resolution chosen by the user, which is equally spaced units of 1/30th of a second or 1/29.97ths of a second or 1/25ths of a second or 1/24ths of a second.

Figure 1 – Timeline snap-to resolutions include the four SMPTE timecode frame rates.

Frame numbers

The 30 fps SMPTE time stamps count in frames sequentially from 0 to 29.  Thus the stream of HH:MM:SS:FF time stamp values progresses in synch with the progression of time in the real world: after 30 frames at 30 fps, one second has gone by in the real world and one second has gone by in the HH:MM:SS:FF time stamp representation.

The 25 fps and 24 fps SMPTE time stamps count in frames sequentially from o to 24 and from 0 to 23 respectively.  So they also progress in synch with time in the real world.

If the 29.97 fps SMPTE time stamps count in frames sequentially from 0 to 29, just like the 30 fps time stamps, then the time stamp values will not remain in synch with time in the real world.  29.97 fps is slightly slower than 30 fps, so the time stamp HH:MM:SS:FF in the 29.97 fps stream following a sequence of 30 frames would say that exactly one second has transpired while in reality slightly more than one second has transpired.

Projecting this difference out to a longer period of time, after 10 minutes the 29.97 fps time stamps would fall behind time in the real world by 0.6 seconds.  If you set your watch by the time stamp values, your watch would be running slowly.  If you executed a 30 fps firing system script using sequential time stamps playing back at 29.97 fps, the script would play back slowly, and would become out of synch with the music.

To correct for this difference a new, not entirely sequential counting system was invented to count the frames of 29.97 fps SMPTE.  The new counting system counts from 0 to 29 for most seconds, but skips frame 0 and frame 1 for some seconds, jumping directly from frame 29 of the previous second to frame 2 of the next second.  This counting system is called “drop frame.”

SMPTE 29.97 fps DF (drop frame)

SMPTE 29.97 fps drop frame, or “29.97 fps DF” for short, is a variation of 29.97 fps SMPTE that keeps closely in synch with the progression of time in the real world by counting frames in a manner that is not entirely sequential.  To disambiguate whether frame numbers in SMPTE time stamps are counting in drop frame (DF) or non-drop frame (NDF), the punctuation of the HH:MM:SS:FF notation is adjusted for DF, substituting a semicolon for the last colon.

Table 3 – Notation for the two SMPTE 29.97 fps versions

Both the DF and NDF version of 29.97 fps SMPTE have a frame rate of 29.97 fps.  The difference is the NDF version counts all frames sequentially from 0 to 29, while the DF version skips in its counting sequence from frame 29 of one second to frame 2 of the next second for some of the seconds.

The HH:MM:SS;FF time stamps of the DF stream count sequentially and lose ground against real world time for the first minute of play, and then at one minute the counting sequence skips from 00:00:59:29 to 00:01:00:02.  The 00:00:59:29 time stamp is slightly later than 59 seconds and 29/30ths in real world time, but the 00:01:00:02 time stamp, which is immediately following, catches up.  During every minute that passes, the DF time stamps lose ground against real world time, and then at the end of every minute the DF time stamps skip two frame numbers to catch up.

The catching up mechanism of skipping two frame numbers slightly overcompensates for the lost ground of the preceding minute, so very gradually the catching up mechanism gains ground against real world time.  To avoid gaining ground continually, the DF frame counting system doesn’t skip the two frames at the beginning of minutes that are divisible by 10, which includes the first minute of play at minute zero.

In the SMPTE timecode signal, the time stamps contain a “drop frame” flag along with the HH:MM:SS:FF fields, indicating whether the frame counting is sequential or following the drop frame counting system.  The drop frame flag is defined for both 29.97 fps SMPTE and also for 30 fps SMPTE, though uses for 30 fps DF are rare since it doesn’t keep in synch with real world time.  More often than not if you see the words “30 fps DF” the intended meaning is “29.97 fps DF”, so to avoid confusion Finale 3D does not support 30 fps DF.  The NDF version of 29.97 fps timecode also doesn’t keep in synch with real world time, but there are applications that use it so Finale 3D does support it.  The list of frame rates and versions that Finale 3D supports for effect time representations is in Figure 2.  You can select the time format from “Show > Set show information…” or “Show > Show settings > Set effect time format”.

Figure 2 – Effect time formats include the four SMPTE timecode frame rates and both versions of 29.97 fps: DF and NDF

SMPTE 29.97 fps NDF (non-drop frame)

SMPTE 29.97 fps non-drop frame, or “29.97 fps NDF” for short, progresses through HH, MM, and SS significantly slower than the progression of time in the real world (called “wall clock” time) by 1.2 seconds for every 20 minutes.   It advances the HH, MM, and SS by one second after the passage of every 30 frames, but the frames are playing back at only 29.97 per second, so the HH, MM, SS advance at a rate of 29.97 / 30 as fast as wall clock time.

If a firing system controller is being driven by SMPTE 29.97 NDF timecode, it will trigger the script events at this slow rate.  Some controllers have an option to compensate for the slower-than-wall-clock rate of SMPTE 29.97 NDF, but compensation in the controller isn’t well suited for circumstances like concert soundtracks with multiple songs beginning at different agreed upon SMPTE times since the songs don’t necessarily use the same timecode format, and since the operator of the controller may not know in what order the songs will be played.  For circumstances like these, Finale 3D offers better suited options to adjust the event times in the script for SMPTE 29.97 NDF, described here: SMPTE 29.97 NDF (non-drop frame).

When adding a soundtrack to your show, if you elect for Finale 3D to split the soundtrack’s timecode sections apart and automatically position them independently on the timeline, Finale 3D will position them on the timeline at the wall clock time interpretation of the SMPTE HHMMSSFF timestamps, even if the SMPTE timecode sections internally are in SMPTE 29.97 fps NDF.  Similarly, if you slave the playhead in Finale 3D to external timecode input (see Timecode basic instructions), the playhead will be positioned according to the wall clock time interpretation of the timestamps.

Timecode on the timeline

You can change the effect time format in Finale 3D to any of the frame rates and versions in Figure 2.  The timeline, which is delineated in real world time as far as hours, minutes and seconds, shows the playhead time in the effect time format.  If you are scripting in an environment in which you are communicating points of the show with other people using the timecode times, it is most convenient to set both the timeline snap-to resolution and the effect time format to match the timecode of the show.  That will cause the playhead to snap to the times corresponding to valid frames of the show and to display them correctly.  Using the ruler analogy, the playhead would be snapping to the 1/16th inch or 1mm marks on the ruler, and would never lie in between the marks.

If the playhead does lie in between the frames of the effect time format, the playhead’s time will display with an additional “+ms” remainder to reflect the exact time in milliseconds.  Since the timeline’s hours, minutes, and seconds are in real world time, while the playhead’s time is in the effect time, you can see on the timeline exactly how 29.97 DF or NDF get out of synch with time in the real world.  It is analogous to the ruler that shows imperial markings on one side and metric markings on the other — for any length on the ruler, you can compare the two measuring systems’ representation for that specific length.

To see, set the effect time format to “29.97 fps DF” and leave the snap-to resolution at milliseconds.  Then move the playhead to exactly 1 minute in real world time using the menu item, “Show > Goto time” and typing just “1m” into the input field.  The shorthand “1m” or “1h” or any number of seconds with decimal point always indicates real world time, whereas the “00:01:00;00” format would indicate the one minute time stamp of 29.97 fps DF timecode — not the same as one minute in real world time.

Figure 3 – One minute in real world time corresponds to “00:00:59;28” in 29.97 fps DF plus 7 milliseconds.

Figure 3 shows the playhead at one minute in real world time, and simultaneously displays “00:00:59;28+07ms” in the 29.97 fps DF effect time format.  As you can see, the timecode representation hasn’t yet reached frame “00:00:59;29” and has one more frame to go after that to reach the next minute.  Since frames are about 33ms long, it is about 33 – 7 + 33 = 59ms behind real world time.

At the one minute mark, however, the drop frame counting system catches up by skipping two frames, amounting to 2 * 33 = 66ms.  Set the snap-to resolution to 29.97 fps, and drag the playhead to the right.  Observe as you move the playhead from frame to frame that the frame numbers count: “00:00:59;28”, then “00:00:59;29” and then…

Figure 4 – The DF frame after “00:00:59;29” is “00:01:00;02”.  Frame numbers “00:01:00;00” and “00:01:00;01” don’t exist.

Frame numbers “00:01:00;00” and “00:01:00;01” don’t exist in 29.97 fps DF, so the frame after “00:00:59;29” is “00:01:00;02”.  Change the effect time format to 29.97 fps NDF and you’ll see the equivalent NDF frame number as shown in Figure 5 zoomed in.

Figure 5 – The NDF frame after “00:00:59:29” is “00:01:00:00” and it is well after the 1m mark in real world time.

The frame “00:01:00:00” in 29.97 fps NDF is well after one minute in real world time, as you can see by the gap between the playhead and the 1m mark on the timeline in Figure 5.  The timeline illustrates why the drop frame system was necessary for 29.97 fps frame rates.