An account manager friend of mine from VFX house emailed to ask me about a specific TC issue on a 23.98 D5 to 29.97 DBC she was having between editorial and a closed captioning vendor. I wrote up the following explanation to help her understand what was going on in her particular case. Thought I'd share it so if you ever have to explain TC to anyone you have this to refer to...
For starters, in the video world, TC counts, or addresses, video frames, not time. So when we say 23.98 or 29.97 video we're still really counting frames in whole numbers, 24 and 30 frames. The speed at which the video runs, and therefore the TC running with it, determines the actual real world time duration relative to the clock on the wall. TC is a means to assign a unique, repeatable reference number to each video frame, which can then be repeatably recalled with total accuracy.
Non-drop Frame Time Code: At 24 fps we always use consecutive numbers when counting. Each next frame is assigned a number incremented by one, every 24 frames (00:00, 00:01, 00:02... 00:23, 01:00, 01:01, etc.) It works the same way in Non-drop Frame 30, but we count all the way up to frame 29 before rolling over into the next second's 00 frame. Forgetting about real world time for a moment I'll continue generically referring to 24 and 30 fps video. When we take a 24 fps source and convert or re-map the video image to 30 fps the traditional way to do so is by introducing a 2:3 cadence over the interlace fields of the 30 fps video. Each 30 fps frame is actually comprised of 2 interlaced video fields for a total of 60 fields in a counted "second" of video.
Let's look at 1/6 of a counted second of video, four frames of a 24 fps source (A, B, C, and D), and how they are converted to 5 frames (10 fields) at 30 fps.
For starters, in the video world, TC counts, or addresses, video frames, not time. So when we say 23.98 or 29.97 video we're still really counting frames in whole numbers, 24 and 30 frames. The speed at which the video runs, and therefore the TC running with it, determines the actual real world time duration relative to the clock on the wall. TC is a means to assign a unique, repeatable reference number to each video frame, which can then be repeatably recalled with total accuracy.
Non-drop Frame Time Code: At 24 fps we always use consecutive numbers when counting. Each next frame is assigned a number incremented by one, every 24 frames (00:00, 00:01, 00:02... 00:23, 01:00, 01:01, etc.) It works the same way in Non-drop Frame 30, but we count all the way up to frame 29 before rolling over into the next second's 00 frame. Forgetting about real world time for a moment I'll continue generically referring to 24 and 30 fps video. When we take a 24 fps source and convert or re-map the video image to 30 fps the traditional way to do so is by introducing a 2:3 cadence over the interlace fields of the 30 fps video. Each 30 fps frame is actually comprised of 2 interlaced video fields for a total of 60 fields in a counted "second" of video.
Let's look at 1/6 of a counted second of video, four frames of a 24 fps source (A, B, C, and D), and how they are converted to 5 frames (10 fields) at 30 fps.
24 TC | 00:00 | 00:01 | 00:02 | 00:03 |
24 source | A | B | C | D |
30 F1/F2 | A1/A2 | B1/B2 | B3/C1 | C2/D1 | D2/D3 |
30 TC | 00:00 | 00:01 | 00:02 | 00:03 | 00:04 |
Time/Counting}-------}-------}-------}-------}-------}}
Though the columns may not be perfectly aligned due to font issues (use fixed width font like Courier and it will work), presume they are, and hopefully you can see that there is an exact duration and sequence relationship between the source and converted video frames. Notice that in the 30 fps sequence there are two fields of A, 3 fields of B, 2 fields of C, and 3 fields of D, hence the 2:3 cadence over 10 video fields. Also note that the time it takes to play four 24 fps source frames is exactly the same as the time it takes to play the 30fps converted, interlaced frames. Repeat this sequence five more times for a total of six and you have counted out one full second of video ending in 00:23 on the 24 time line and 00:29 on the 30. (remember we are assigning a unique, repeatable reference number to each video frame, NOT measuring real world time.)
A brief NTSC video history lesson: In the days of black and white TV, video actually ran at 30 frames per second, but the addition of color to the Standard Definition NTSC signal lengthened it just enough so that only 29.97 frames could be displayed in exactly :01 of real time. In black and white there were 30 frames x 60 seconds x 60 minutes equalling 108,000 frames in an hour to real time. But in the color system the equation was 29.97 frames x 60 seconds x 60 minutes = 107,892 frames per hour. That's a difference of 108 frames. Divide 108 frames by 30 fps and what do you get? 03:18. Does that number sound familiar? 3 seconds and 18 frames. What do we do, just throw them away? Over a course of 10 hours, that's :36 seconds. That's a commercial! Can't miss out on that TV revenue. Over a twenty-four hour day that's 1:26:12. One minute, twenty-six seconds and twelve frames. What executive in his right mind is going to let the time for almost three full, revenue generating, commercials slide? A new way of counting/addressing frames was needed to more accurately plan for broadcasting and commercial time.
Enter Drop-frame Time Code: A new counting system was devised to "address" the issue. The formula is simple: Drop the first two counting numbers from the sequence starting at the top of every minute, except for every tenth minute. Than means nothing happens in minutes 00, 10, 20, 30, 40, and 50, but in all other minutes of a given hour, frames 00 and 01 are omitted from the sequence. Example sequence: HH:02:59;28, HH:02:59;29, HH:03:00;02, HH:03:00:03... etc. (60 total minutes - 6 undropped minutes) x 2 dropped counting numbers = 108 dropped counting numbers per hour. That's our magic 03:18 again. Hey if we count 29.97 real time video in Drop-frame style, one hour of real time video equals one hour of DFTC. It's perfect. It's important to note here that no actual video frames are dropped or lost in the process. Only counting numbers are skipped in the addressing sequence. It's cliché in this discussion, and you may think an urban legend, but I actually have had people say, when asked if they want DF or NDF TC, "No. I want all the frames."
A brief NTSC video history lesson: In the days of black and white TV, video actually ran at 30 frames per second, but the addition of color to the Standard Definition NTSC signal lengthened it just enough so that only 29.97 frames could be displayed in exactly :01 of real time. In black and white there were 30 frames x 60 seconds x 60 minutes equalling 108,000 frames in an hour to real time. But in the color system the equation was 29.97 frames x 60 seconds x 60 minutes = 107,892 frames per hour. That's a difference of 108 frames. Divide 108 frames by 30 fps and what do you get? 03:18. Does that number sound familiar? 3 seconds and 18 frames. What do we do, just throw them away? Over a course of 10 hours, that's :36 seconds. That's a commercial! Can't miss out on that TV revenue. Over a twenty-four hour day that's 1:26:12. One minute, twenty-six seconds and twelve frames. What executive in his right mind is going to let the time for almost three full, revenue generating, commercials slide? A new way of counting/addressing frames was needed to more accurately plan for broadcasting and commercial time.
Enter Drop-frame Time Code: A new counting system was devised to "address" the issue. The formula is simple: Drop the first two counting numbers from the sequence starting at the top of every minute, except for every tenth minute. Than means nothing happens in minutes 00, 10, 20, 30, 40, and 50, but in all other minutes of a given hour, frames 00 and 01 are omitted from the sequence. Example sequence: HH:02:59;28, HH:02:59;29, HH:03:00;02, HH:03:00:03... etc. (60 total minutes - 6 undropped minutes) x 2 dropped counting numbers = 108 dropped counting numbers per hour. That's our magic 03:18 again. Hey if we count 29.97 real time video in Drop-frame style, one hour of real time video equals one hour of DFTC. It's perfect. It's important to note here that no actual video frames are dropped or lost in the process. Only counting numbers are skipped in the addressing sequence. It's cliché in this discussion, and you may think an urban legend, but I actually have had people say, when asked if they want DF or NDF TC, "No. I want all the frames."
