|
Conversion between SMPTE hh:mm:ss:ff Time Code and FramesBrooks Harris, EdlMax, LLC. Version V4 2015-04-04 Demonstration c source code: SMPTE time code (sometimes called "SMPTE/EBU time code", "EBU time code", or simply “timecode”) is specified in the SMPTE standard SMPTE ST 12-1 Time and Control Code, (formerly called "SMPTE 12M"). SMPTE ST 12-1 describes the structure of time code data and its numbering schemes together with digital encoding formats. SMTPE ST 12-1 is the foundational document for "SMPTE time code" from which many other time code-related SMPTE standards are derived. The behavior of the time and frames data in SMPTE time code derives from its original purpose for monitoring tape position by frames. When it was invented the best way to encode the position of a frame on tape was in the form of hours:minutes:seconds:frames (hh:mm:ss:ff). The binary form used in ST 12-1 is encoded using Binary Coded Decimal (BCD) together with other operational metadata to enable real-time signal detection of values, direction, and speed on tape. SMPTE time code can be thought of as a "position", or "index"; an absolute integer number of frames from a zero starting point encoded as an hh:mm:ss:ff number from a 00:00:00:00 "origin". This encoding form also has the advantage of being human readable as a time. SMPTE time code can also be represented in character (text) format. The official form of character representation is specified in SMPTE ST 258, Transfer of Edit Decision Lists. The data elements of the text format follow the numbering and counting schemes defined in SMPTE ST-12-1. Both binary and text forms encode the frame position value as hh:mm:ss:ff. Conversion between them is the subject of this article. Binary FormatsSMPTE ST-12-1 details information about three related topics: 1) The time and frames data itself and its counting methods. This aspect is often of most interest and relevance to many software implementations. 2) Specification of how the binary versions of time code are to be phase-aligned to the video signal they are applied to. 3) The "transport layer", that is, the bit layout of time code binary data and operational metadata. Two transports are defined in SMPTE ST 12-1 – "Linear Time code (LTC)" is used for magnetic tape position tracking and transporting time code over (analog) wires, and Vertical Interval Time code (VITC)" is used to transport time code data in the vertical interval of analog video signals. One additional transport layer, defined in a companion document SMPTE ST 12-2 – “Ancillary Time Code (ATC)”, is used to transport time code data in digital video signals. Text FormatsTime code can also be represented as text, the familiar form seen on many system displays, in edit decision lists, application parameter settings, etc. SMPTE ST 258, section 8 Time code specifies text-formatting rules for time code character representation: [hour]":"[minute]":"[second][":" | ";" | "." | ","][frames] where the last separator (the character between seconds and frames) indicates the count mode (Non-drop Frame or Drop Frame) and "field 1" or "field 2" of interlace video. "00:00:00.00" (period - field 1 non-drop-frame) SMPTE Time code and text formatting does not explicitly address “progressive” video formats. In this case it is convention to default to ":" (non-drop-frame) or ";" (drop-frame). In systems and applications supporting conventional interlace video formats the "field 1" and "field 2" designations have significance. In many other applications the field data is not important or may be ignored. Typically in these cases ":" or ";" are used as default. Implementers and users should exercise caution regarding this aspect of time code. Encoding of Frames as hh:mm:ss:ffThe SMPTE time code numbering schemes, or "count mode(s)", label frames as hh:mm:ss:ff starting at an arbitrary zero origin (00:00:00:00) through approximately 24 hours, depending on the rate and count mode in use. SMPTE time code supports four frame rates:
(60/1, 60000/1001, 50/1, and 48/1 can be supported by treating frames in pairs. This is beyond the scope of this article) Its important to note that the NTSC frame rate is *not* 29.97, as is often stated. The true and correct rate is 30000/1001, which is 29.97002997002997... (a repeating decimal fraction). Rounded to 2 decimal points it is 29.97 and this how the 30000/1001 rate gets the name "29.97". But 29.97 is not accurate enough for many purposes, especially maintaining video/audio sync. The "count modulus", that is, the number of unit counts per time, is referred to as "frames per (nominal) second": 30fps (0-29 frames) Here, "nominal" (name of) is used to indicate that a "second" is not a true second in the case of 30000/1001 rate video. Non-drop Frame and Drop Frame Count ModesThe "Non-drop Frame" count mode labels frames with an uninterrupted incrementing count of hh:mm:ss:ff. It is applicable to all rates. In the case of 30000/1001 (NTSC), the hh:mm:ss portions of a Non-drop Frame count does not indicate accurate running time because the frame rate is not exactly “30 frames per second”. The "Drop Frame" count mode was developed to compensate for the slightly slow frame rate of NTSC. 30000/1001 is approximately 29.97002997.... , that is, 30 frames last for slightly longer than true 30 frames-per-second. Put another way, an "NTSC second" is slightly longer than a true second - (1 / (30000 / 1001)) * 30 = 1.001 seconds. Thus there is a "drift" between the true time and uncompensated (Non-drop Frame) hh:mm:ss:ff representation. To compensate, the Drop Frame count mode skips, or "drops", certain numbers from the count. The rule is: “Drop” (omit) the frame numbers 00 and 01 from the count every minute except each tenth minute; that is, except each minute that is divisible by 10. To quote SMTPE ST 12-1, section 5.2.2 Drop frame – NTSC time compensated mode: So, at the end of the first minute the count "skips" from 00:00:59;29 to 00:01:00:00;02. The numbers 00:01:00:00;00 and 00:01:00:00;01 are "dropped", or omitted, from the count. At the end of the tenth minute the count does not skip - the count goes smoothly from 00:09:59;29 to 00:10:00:00;00 to 00:10:00:00;01. The NTSC video signal is always the same; the count modulus (30fps, 0-29) and frame rate (30000/1001) do not change whether Non-drop or Drop-frame count mode is used. Drop Frame is only a numbering scheme - actual video frames are not dropped! Where would they go? Drop Frame Accuracy and Broadcast “Daily Jam”The Drop Frame count mode does a good job of distributing the drift, or error, between true “clock time” and the 30000/1001 frame rate to produce usable “time-of-day” hh:mm:ss:ff values. But it is not exactly accurate; there is approximately a -2.6 frame error at the end of the 24-hour day. The Drop Frame value 24:00:00;00 = 2589408 frames, but 24 * 60 * 60 * (30000/1001) = 2589410.589410594… frames. The Drop Frame count mode under-counts by approximately In production and post-production this inaccuracy can generally be ignored, but in broadcast synchronization it is traditional to reset the time code value once a day to keep the indicated time-of-day as close as possible to true clock time. This is sometimes called “daily jam”, where the time code value is “jammed”, or reset, to an accurate clock. Thus, time code values are very nearly the true time-of-day and the error does not accumulate each day. About the Author Brooks Harris is President of EdlMax, LLC. (formally Brooks Harris Film & Tape, Inc. (BHFT)), a software development company in NYC specializing in edit data exchange. BHFT markets EDLMAX, an EDL and OMF management application, and provides consulting and custom implementations for OEM clients. Harris is a member of SMPTE and AES and a contributor to the SMPTE P18.27 Working Group on Editing Procedures and AES SC-06-01 Audio File Interchange. Harris is also a contributor to the EBU/SMPTE Task Force on the Harmonization of Data Interchange. BHFT is an OMF Champion and an AAF Adopter. |
