Answers.Body: <p>As per the Broadcast Engineer's <a href="https://books.google.com/books?isbn=1136024174" rel="nofollow">Reference Book</a>, p. 203</p>
  
  <blockquote>
    <p>This correction will match DF time to real time to within
    approximately 2.6 frames per day; to eliminate the residual error the
    timecode generator can be reset each midnight.</p>
  </blockquote>
  
  <p>So, apparently nothing.</p>
  
  <p>As far as the "extra" frames, Charles Poynton <a href="https://groups.google.com/d/msg/sci.engr.television.advanced/rsLQnAC1qlQ/Rvc-_QK5qyQJ" rel="nofollow">says</a>,</p>
  
  <blockquote>
    <p>If a timecode sequence is to be maintained longer than 24 hours,
    timecode should be jammed daily to reference clock time at an
    innocuous moment. No standard recommends when this should take place;
    however, the usual technique is to insert duplicate timecode numbers
    00:00:00;00 and 00:00:00;01. Editing equipment treats the duplicate
    codes as a timecode interruption.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T16:43:47.393Z
Answers.Text: This (very helpfully!) explains how the error is removed each day, but doesn't explain how the "extra" frames are handled.
Answers.UserDisplayName: Erik D.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T17:23:13.493Z
Answers.Text: I'm assuming they aren't handled. If they were, there would be no residual error to reset.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T20:06:31.453Z
Answers.Text: I don't mean "handled" as in "corrected"; I agree the error needs to be reset after every 24-hour periods. That said, 29.97 dropframe gives us 2,589,407 frame labels for a given 24-hour period, but the actual framerate requires labels for 2,589,409.6 frames -- unless the reset includes ignoring two frames each night, which seems to introduce a new sync issue.
Answers.UserDisplayName: Erik D.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T22:40:54.443Z
Answers.Text: @ErikD.  What issues do you see here, and where would they arise? Is there anything in your experience that indicates that this causes real-world problems, and for whom?
Answers.UserDisplayName: Jim Mack
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-06T02:16:25.830Z
Answers.Text: @JimMack I'm dealing with a CMS that stores timecode values as millisecond offsets from midnight. Assuming I'm using time-of-day timecode, I'm frame-inaccurate for any footage captured after about 2pm if I'm calculating at exactly 29.97 fps. If I use the correct 30 fps * (1000/1001), I have two and a half unlabelable frames for footage spanning midnight.
Answers.UserDisplayName: Erik D.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-06T05:58:17.653Z
Answers.Text: Can you customize the timecode function? Basically, you need to skip one of the two timecode frame drops at 9h16m6s and 18h32m13s.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-29T19:45:26.983Z
Answers.LastActivityDate: 2016-03-04T20:29:15.667Z
Answers.LastEditDate: 2016-03-04T20:29:15.667Z
Answers.UserDisplayName: Gyan
Answers.Body: <p>The information so far: you're acquiring video content continuously at exactly 29.97 with no breaks ever, forever. Plus A) each video frame must have a unique label and B) these labels must always exactly match true time of day, within a small epsilon that averages to zero.</p>
  
  <p>Given those conditions, there's no solution using only standard video sync and time code. You must compromise / customize something.</p>
  
  <p>Some possibilities are:</p>
  
  <p>1 - Resynchronize TC to TOD at every break in recording. I know we assumed no breaks, but no recording medium has infinite length. Scheduled breaks or resync points might be possible.</p>
  
  <p>2 - Jam the TCG to TOD every "n" hours and live with the consequences.</p>
  
  <p>3 - Store both the mSec-exact TOD and the TC (or the accumulated delta) in the CMS, and use them both on retrieval of a given frame. Couple this with a reset to 0 whenever possible.</p>
  
  <p>4 - Use the user bits of the TC to encode the mSec-exact TOD, instead of storing it in the CMS database. However, the delta won't survive dubbing / editing.</p>
  
  <p>5 - Similar to what @Mulvya suggests, customize the TC generation to not drop three normally-skipped frame labels each day. That would change the drift from -2.589 frames/day to +0.411 fr/day. This can be further corrected by skipping one of the not-drops every 2 days, making the average error term -0.02 fr/day, etc. You can continue this to any desired accuracy. This is only possible if your TC doesn't have to be used outside your own context. "Normal" systems for editing etc won't understand it.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-06T13:16:07.533Z
Answers.LastActivityDate: 2016-03-06T13:16:07.533Z
Answers.UserDisplayName: Jim Mack
Body: <p><strong>A quick primer:</strong><br/>American television was originally broadcast at 30 frames per second. In order to accommodate color information without losing backward-compatibility with B&amp;W televisions, the framerate was slowed by a factor of 1000/1001, to approximately 29.97 FPS.</p>
  
  <p>29.97 footage was still labeled as 30 FPS; however, the difference in framerate caused the timecode to be off by a minute-and-a-half per day, causing sync issues for broadcasters. To counteract this, "dropframe" timecode was developed. At 30 FPS, there are 18000 frames per ten minutes; at 29.97 <em>exactly</em>, there are 17982 frames per ten minutes. To account for the eighteen-frame difference, we "skip" two frames on every minute not divisible by 10. For example:</p>
  
  <pre><code>30 FPS
  00:00:59:29 + 1 frame = 00:01:00:00
  00:04:59:29 + 1 frame = 00:05:00:00
  00:09:59:29 + 1 frame = 00:10:00:00
  
  29.97 FPS, dropframe
  00:00:59;29 + 1 frame = 00:01:00;02
  00:04:59;29 + 1 frame = 00:05:00;02
  00:09:59;29 + 1 frame = 00:10:00;00
  </code></pre>
  
  <p><strong>The question:</strong><br/>The math works out at <em>exactly</em> 29.97, but the framerate is slightly faster -- 30*(1000/1001) works out to 29.97002997002... The difference is negligible for any single piece of footage; the error here only works about to about two-and-a-half frames per twenty-four hours. But <strong>how does a master sync generator account for these extra frames?</strong> There's no labeling scheme for them, and midnight will not occur on a clean frame.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-29T19:02:46.297Z
Comments.Text: Interesting. Certainly, apps like FFmpeg don't [account](https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/timecode.c#L34) for the discrepancy. And the impression from search suggests neither do most other s/w or appliances.
Comments.UserDisplayName: Gyan
Tags: <sync><timecode><broadcasting>
Title: How is 29.97 timecode generated over a full day without frame errors?
UserDisplayName: Erik D.
ThreadText: # How is 29.97 timecode generated over a full day without frame errors?
  
  (Asked by: username_0 on 2016-02-29)
  
  **A quick primer:**  
  American television was originally broadcast at 30 frames per second. In order to accommodate color information without losing backward-compatibility with B&W televisions, the framerate was slowed by a factor of 1000/1001, to approximately 29.97 FPS.
  
  29.97 footage was still labeled as 30 FPS; however, the difference in framerate caused the timecode to be off by a minute-and-a-half per day, causing sync issues for broadcasters. To counteract this, "dropframe" timecode was developed. At 30 FPS, there are 18000 frames per ten minutes; at 29.97 *exactly*, there are 17982 frames per ten minutes. To account for the eighteen-frame difference, we "skip" two frames on every minute not divisible by 10. For example:
  
  ```
  30 FPS
  00:00:59:29 + 1 frame = 00:01:00:00
  00:04:59:29 + 1 frame = 00:05:00:00
  00:09:59:29 + 1 frame = 00:10:00:00
  
  29.97 FPS, dropframe
  00:00:59;29 + 1 frame = 00:01:00;02
  00:04:59;29 + 1 frame = 00:05:00;02
  00:09:59;29 + 1 frame = 00:10:00;00
  
  ```
  
  **The question:**  
  The math works out at *exactly* 29.97, but the framerate is slightly faster -- 30\*(1000/1001) works out to 29.97002997002... The difference is negligible for any single piece of footage; the error here only works about to about two-and-a-half frames per twenty-four hours. But **how does a master sync generator account for these extra frames?** There's no labeling scheme for them, and midnight will not occur on a clean frame.
  
  **Tags:** sync, timecode, broadcasting
  
  > **Comments:**
  > **username_1**: Interesting. Certainly, apps like FFmpeg don't [account](https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/timecode.c#L34) for the discrepancy. And the impression from search suggests neither do most other s/w or appliances.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-02-29. Score: 2 | Accepted answer
  
  As per the Broadcast Engineer's [Reference Book](https://books.google.com/books?isbn=1136024174), p. 203
  
  > This correction will match DF time to real time to within
  > approximately 2.6 frames per day; to eliminate the residual error the
  > timecode generator can be reset each midnight.
  
  So, apparently nothing.
  
  As far as the "extra" frames, Charles Poynton [says](https://groups.google.com/d/msg/sci.engr.television.advanced/rsLQnAC1qlQ/Rvc-_QK5qyQJ),
  
  > If a timecode sequence is to be maintained longer than 24 hours,
  > timecode should be jammed daily to reference clock time at an
  > innocuous moment. No standard recommends when this should take place;
  > however, the usual technique is to insert duplicate timecode numbers
  > 00:00:00;00 and 00:00:00;01. Editing equipment treats the duplicate
  > codes as a timecode interruption.
  
  > **Comments:**
  > **username_0**: This (very helpfully!) explains how the error is removed each day, but doesn't explain how the "extra" frames are handled.  
  > **username_1**: I'm assuming they aren't handled. If they were, there would be no residual error to reset.  
  > **username_0**: I don't mean "handled" as in "corrected"; I agree the error needs to be reset after every 24-hour periods. That said, 29.97 dropframe gives us 2,589,407 frame labels for a given 24-hour period, but the actual framerate requires labels for 2,589,409.6 frames -- unless the reset includes ignoring two frames each night, which seems to introduce a new sync issue.  
  > **username_2**: @ErikD.  What issues do you see here, and where would they arise? Is there anything in your experience that indicates that this causes real-world problems, and for whom?  
  > **username_0**: @username_2 I'm dealing with a CMS that stores timecode values as millisecond offsets from midnight. Assuming I'm using time-of-day timecode, I'm frame-inaccurate for any footage captured after about 2pm if I'm calculating at exactly 29.97 fps. If I use the correct 30 fps * (1000/1001), I have two and a half unlabelable frames for footage spanning midnight.  
  > **username_1**: Can you customize the timecode function? Basically, you need to skip one of the two timecode frame drops at 9h16m6s and 18h32m13s.  
  
  ---
  
  ### Answer by username_2 on 2016-03-06. Score: 0
  
  The information so far: you're acquiring video content continuously at exactly 29.97 with no breaks ever, forever. Plus A) each video frame must have a unique label and B) these labels must always exactly match true time of day, within a small epsilon that averages to zero.
  
  Given those conditions, there's no solution using only standard video sync and time code. You must compromise / customize something.
  
  Some possibilities are:
  
  1 - Resynchronize TC to TOD at every break in recording. I know we assumed no breaks, but no recording medium has infinite length. Scheduled breaks or resync points might be possible.
  
  2 - Jam the TCG to TOD every "n" hours and live with the consequences.
  
  3 - Store both the mSec-exact TOD and the TC (or the accumulated delta) in the CMS, and use them both on retrieval of a given frame. Couple this with a reset to 0 whenever possible.
  
  4 - Use the user bits of the TC to encode the mSec-exact TOD, instead of storing it in the CMS database. However, the delta won't survive dubbing / editing.
  
  5 - Similar to what @Mulvya suggests, customize the TC generation to not drop three normally-skipped frame labels each day. That would change the drift from -2.589 frames/day to +0.411 fr/day. This can be further corrected by skipping one of the not-drops every 2 days, making the average error term -0.02 fr/day, etc. You can continue this to any desired accuracy. This is only possible if your TC doesn't have to be used outside your own context. "Normal" systems for editing etc won't understand it.
  
  
  ---
  
  