Time code: Difference between revisions
imported>William Meyer m (much additional content) |
mNo edit summary |
||
| (10 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
{{subpages}} | |||
In the mid-1950's, the first practical [[videotape recorder|videotape recorders]] were introduced. This shortly gave rise to the need for editing content, but the nature of those machines was such that if tape movement were stopped, a picture was not and could not be displayed. This led to the invention of a '''time code''' address that was recorded on the second audio track of the tape. Times were of the form: hh:mm:ss:ff, where hh means hours, mm means minutes, ss means seconds, and ff means frames. In the days of [[monochrome television]], there were 30 frames per second; [[color television]] in the United States modified this to 29.97 frames per second (fps). Correction of the resulting error with respect to real time was accomplished through the addition of a format called drop-frame, in which two frame addresses were omitted at the first frame of the first second of each minute not evenly divisible by 10. Outside North America, other frame rates were used, such as 25 fps in Europe. Time code has also been used at 24 fps for application to film. | In the mid-1950's, the first practical [[videotape recorder|videotape recorders]] were introduced. This shortly gave rise to the need for editing content, but the nature of those machines was such that if tape movement were stopped, a picture was not and could not be displayed. This led to the invention of a '''time code''' address that was recorded on the second audio track of the tape. Times were of the form: hh:mm:ss:ff, where hh means hours, mm means minutes, ss means seconds, and ff means frames. In the days of [[monochrome television]], there were 30 frames per second; [[color television]] in the United States modified this to 29.97 frames per second (fps). Correction of the resulting error with respect to real time was accomplished through the addition of a format called drop-frame, in which two frame addresses were omitted at the first frame of the first second of each minute not evenly divisible by 10. Outside North America, other frame rates were used, such as 25 fps in Europe. Time code has also been used at 24 fps for application to film. | ||
| Line 8: | Line 8: | ||
The definition of this time code was formalized by the SMPTE ([[http://www.smpte.org Society of Motion Picture and Television Engineers]]) in the SMPTE [[12M]] standards document (SMPTE Standards documents are not available for free download.) | The definition of this time code was formalized by the SMPTE ([[http://www.smpte.org Society of Motion Picture and Television Engineers]]) in the SMPTE [[12M]] standards document (SMPTE Standards documents are not available for free download.) | ||
===Longitudinal | ===Longitudinal time code=== | ||
In the longitudinal format, SMPTE time code is contained in 80 bits of data, which are defined as: | In the longitudinal format, SMPTE time code is contained in 80 bits of data, which are defined as: | ||
:0..3: Unit Frames | :0..3: Unit Frames | ||
| Line 19: | Line 19: | ||
:20..23: user bits field 3 | :20..23: user bits field 3 | ||
:24..26: Tens of Seconds | :24..26: Tens of Seconds | ||
:27: Bi-phase mark-correction bit; set or cleared so every 80-bit word has an even number of zeros. This can be used to | :27: Bi-phase mark-correction bit; set or cleared so every 80-bit word has an even number of zeros. This can be used to ensure that the DC component of the time code frame is zero. It also allows the beginning of the sync word to be of constant polarity, which is an aid to technicians reading the bi-phase coding on an oscilloscope; the polarity would otherwise invert on alternate frames, as the frame count increments. This was not a part of the original standard, but is an enhancement that became practical after ASICs and fast microprocessors were introduced to the time code landscape. | ||
:28..31: user bits field 4 | :28..31: user bits field 4 | ||
:32..35: Unit Minutes | :32..35: Unit Minutes | ||
| Line 32: | Line 32: | ||
:59: binary group flag bit (see bit 43 for encoding) | :59: binary group flag bit (see bit 43 for encoding) | ||
:60..63: user bits field 8 | :60..63: user bits field 8 | ||
:64..79: sync word, always: 0011 1111 1111 1101 Note that | :64..79: sync word, always: 0011 1111 1111 1101 Note that twelve consecutive ones will only occur in the sync word, and that the two zeros preceding and 01 following make it possible to determine the direction of play. | ||
Thirty-two bits are reserved for user data. These are often used for a reel number and date, and have also been used to contain the time code from the original master reel. They can contain anything, but bits 43 and 59 must always be set to zero. | Thirty-two bits are reserved for user data. These are often used for a reel number and date, and have also been used to contain the time code from the original master reel. They can contain anything, but bits 43 and 59 must always be set to zero. | ||
| Line 40: | Line 40: | ||
Longitudinal SMPTE timecode has traditionally been recorded at a level 10dB below system reference for normal audio, to minimize both distortion and crosstalk. | Longitudinal SMPTE timecode has traditionally been recorded at a level 10dB below system reference for normal audio, to minimize both distortion and crosstalk. | ||
===VITC | ====Drop-frame==== | ||
The modification of frame rate from the 30Hz of monochrome television to the 29.97 of [[NTSC]] introduced a problem for time code. Since the frame rate is an unpleasant fraction, if time code counts based on 30 frames per second, the relation between time code and time of day will diverge. Drop-frame is a clever hack that minimizes the accumulating error. The method is to declare that the first frame address of the zeroth second of each minute not evenly divisible by 10 will be numbered :02. This means that from minutes 1 through 9 of each decade, two addresses are missing, and therefore in each 10 minute period, 18 frames are "dropped". Drop-frame solves the divergence of time code and time, but introduces interesting annoyances in performing simple arithmetic on drop-frame times. | |||
Dropping 2 frame counts every minute, except every tenth minute, results in 30×0.999 = 29.97 frame/S. | |||
The sequence when frame counts are dropped: | |||
<br>01:08:59:28 | |||
<br>01:08:59:29 | |||
<br>01:09:00:02 | |||
<br>01:09:00:03 | |||
The sequence on every tenth minute: | |||
<br>01:09:59:28 | |||
<br>01:09:59:29 | |||
<br>01:10:00:00 | |||
<br>01:10:00:01 | |||
===VITC time code=== | |||
VITC was invented after the development of helical-scan videotape recorders, to facilitate the reading of time code when the tape is stopped. Helical-scan recorders changed the editing process, since it is possible to see a complete image with no tape movement. This made precise edit point selection easy, but longitudinal time code can only be read while tape is moving. VITC solved this problem. | VITC was invented after the development of helical-scan videotape recorders, to facilitate the reading of time code when the tape is stopped. Helical-scan recorders changed the editing process, since it is possible to see a complete image with no tape movement. This made precise edit point selection easy, but longitudinal time code can only be read while tape is moving. VITC solved this problem. | ||
In VITC, the time code data are encoded into the actual video, but in the [[vertical interval]], where they will not be seen in the picture. | In VITC, the time code data are encoded into the actual video, but in the [[vertical interval]], where they will not be seen in the picture. | ||
==Generating and | ==Generating and reading time code== | ||
Specialized equipment is used for generating and reading time code. | Specialized equipment is used for generating and reading time code. | ||
| Line 52: | Line 69: | ||
Time code generators are referenced to house sync or [[black burst]], to maintain a precise timing reference. While there may be any number of generators in use in a facility, one of them is normally considered the master, and produces the master time code reference for that facility. Other generators may need to be synchronized to this code, or may be running on a completely different time reference, as may happen in editing situations. | Time code generators are referenced to house sync or [[black burst]], to maintain a precise timing reference. While there may be any number of generators in use in a facility, one of them is normally considered the master, and produces the master time code reference for that facility. Other generators may need to be synchronized to this code, or may be running on a completely different time reference, as may happen in editing situations. | ||
===Readers and | ===Readers and decoders=== | ||
A time code reader accepts the time code bit stream, and converts it to human readable form, whether for display alone, or insertion in the video as [[burned-in time code]], or for use in an editing system. A time code decoder performs the same task, but adds one frame to the result, | A time code <b>reader</b> accepts the time code bit stream, and converts it to human readable form, whether for display alone, or insertion in the video as [[burned-in time code]], or for use in an editing system. | ||
A time code <b>decoder</b> performs the same task, but adds one frame to the result when reading forward (subtracting in reverse), giving an "on-time" code. As the time code for a given frame address is written on that frame, by the time the address has been read, it is inherently one frame off, as the code read is for the frame just passed. In this context, "decode" refers to applying that one frame correction. | |||
== | ==Time Code Mathematics== | ||
Time code is valuable in locating specific frames in a video element. However, in editing, it is essential to add and subtract time code values. The complexities of that process are reduced by translating addresses in hh:mm:ss:ff format to integer frame counts. The arithmetical manipulations are then applied to simple integers, and the result translated back to the appropriate time code format. This practice continues in non-linear editing environments, where the medium is not tape. | |||
[[Category: | [[Category:Suggestion Bot Tag]] | ||
Latest revision as of 06:01, 29 October 2024
In the mid-1950's, the first practical videotape recorders were introduced. This shortly gave rise to the need for editing content, but the nature of those machines was such that if tape movement were stopped, a picture was not and could not be displayed. This led to the invention of a time code address that was recorded on the second audio track of the tape. Times were of the form: hh:mm:ss:ff, where hh means hours, mm means minutes, ss means seconds, and ff means frames. In the days of monochrome television, there were 30 frames per second; color television in the United States modified this to 29.97 frames per second (fps). Correction of the resulting error with respect to real time was accomplished through the addition of a format called drop-frame, in which two frame addresses were omitted at the first frame of the first second of each minute not evenly divisible by 10. Outside North America, other frame rates were used, such as 25 fps in Europe. Time code has also been used at 24 fps for application to film.
Variations
In addition to time code on an audio track, which is generally referred to as longitudinal time code, other approaches have been employed, including the embedding of time code data in the television vertical interval and even the embedding of a single data bit in each of the first 80 horizontal sync pulses. Some videotape recorders were designed that provided special tracks for the recording of time code. In the move to digital television, time code has been designed into the data definitions from the start, so the notion of a time code track is moot.
Standards
The definition of this time code was formalized by the SMPTE ([Society of Motion Picture and Television Engineers]) in the SMPTE 12M standards document (SMPTE Standards documents are not available for free download.)
Longitudinal time code
In the longitudinal format, SMPTE time code is contained in 80 bits of data, which are defined as:
- 0..3: Unit Frames
- 4..7: user-bits field 1
- 8..9: Tens of Frames
- 10: 1=drop frame format (see discussion below)
- 11: 1="color frame", i.e. the time code is synchronised with a color TV field sequence.
- 12..15: user-bits field 2
- 16..19: Units Seconds
- 20..23: user bits field 3
- 24..26: Tens of Seconds
- 27: Bi-phase mark-correction bit; set or cleared so every 80-bit word has an even number of zeros. This can be used to ensure that the DC component of the time code frame is zero. It also allows the beginning of the sync word to be of constant polarity, which is an aid to technicians reading the bi-phase coding on an oscilloscope; the polarity would otherwise invert on alternate frames, as the frame count increments. This was not a part of the original standard, but is an enhancement that became practical after ASICs and fast microprocessors were introduced to the time code landscape.
- 28..31: user bits field 4
- 32..35: Unit Minutes
- 36..39: user bits field 5
- 40..42: Tens of Minutes
- 43: binary group flag bit (with bit 59, 43,59 = 00 = no format for user bits, 10 = eight bit format, 01, 11 are unassigned and reserved).
- 44..47: user bits field 6
- 48..51: Unit Hours
- 52..55: user bits field 7
- 56..57: Tens of Hours
- 58: unused, reserved, should transmit zero and ignore on receive for compatibility
- 59: binary group flag bit (see bit 43 for encoding)
- 60..63: user bits field 8
- 64..79: sync word, always: 0011 1111 1111 1101 Note that twelve consecutive ones will only occur in the sync word, and that the two zeros preceding and 01 following make it possible to determine the direction of play.
Thirty-two bits are reserved for user data. These are often used for a reel number and date, and have also been used to contain the time code from the original master reel. They can contain anything, but bits 43 and 59 must always be set to zero.
The bits are encoded as "biphase". A zero bit has a single transition at the start of the bit period. A one bit has two transitions, at the beginning and middle of the period. This encoding is self-clocking.
Longitudinal SMPTE timecode has traditionally been recorded at a level 10dB below system reference for normal audio, to minimize both distortion and crosstalk.
Drop-frame
The modification of frame rate from the 30Hz of monochrome television to the 29.97 of NTSC introduced a problem for time code. Since the frame rate is an unpleasant fraction, if time code counts based on 30 frames per second, the relation between time code and time of day will diverge. Drop-frame is a clever hack that minimizes the accumulating error. The method is to declare that the first frame address of the zeroth second of each minute not evenly divisible by 10 will be numbered :02. This means that from minutes 1 through 9 of each decade, two addresses are missing, and therefore in each 10 minute period, 18 frames are "dropped". Drop-frame solves the divergence of time code and time, but introduces interesting annoyances in performing simple arithmetic on drop-frame times.
Dropping 2 frame counts every minute, except every tenth minute, results in 30×0.999 = 29.97 frame/S.
The sequence when frame counts are dropped:
01:08:59:28
01:08:59:29
01:09:00:02
01:09:00:03
The sequence on every tenth minute:
01:09:59:28
01:09:59:29
01:10:00:00
01:10:00:01
VITC time code
VITC was invented after the development of helical-scan videotape recorders, to facilitate the reading of time code when the tape is stopped. Helical-scan recorders changed the editing process, since it is possible to see a complete image with no tape movement. This made precise edit point selection easy, but longitudinal time code can only be read while tape is moving. VITC solved this problem.
In VITC, the time code data are encoded into the actual video, but in the vertical interval, where they will not be seen in the picture.
Generating and reading time code
Specialized equipment is used for generating and reading time code.
Generators
Time code generators are referenced to house sync or black burst, to maintain a precise timing reference. While there may be any number of generators in use in a facility, one of them is normally considered the master, and produces the master time code reference for that facility. Other generators may need to be synchronized to this code, or may be running on a completely different time reference, as may happen in editing situations.
Readers and decoders
A time code reader accepts the time code bit stream, and converts it to human readable form, whether for display alone, or insertion in the video as burned-in time code, or for use in an editing system.
A time code decoder performs the same task, but adds one frame to the result when reading forward (subtracting in reverse), giving an "on-time" code. As the time code for a given frame address is written on that frame, by the time the address has been read, it is inherently one frame off, as the code read is for the frame just passed. In this context, "decode" refers to applying that one frame correction.
Time Code Mathematics
Time code is valuable in locating specific frames in a video element. However, in editing, it is essential to add and subtract time code values. The complexities of that process are reduced by translating addresses in hh:mm:ss:ff format to integer frame counts. The arithmetical manipulations are then applied to simple integers, and the result translated back to the appropriate time code format. This practice continues in non-linear editing environments, where the medium is not tape.