<p>First, let me say that I have no idea what Premiere is doing with its values or what a 'tick' means in their terms. I can only speak generally.</p>

<p>The video frame rate should match the timecode rate, but for 'drop frame' timecodes the relationship isn't perfectly linear. There are certain timecode numbers that never show up in the sequence -- the ones that are 'dropped'. So for such codes you can't just perform a simple computation, you have to consider the drops.</p>

<p>Over the course of 1 hour there are 108000 frames at 30fps, but drop frame code will produce only 107892 unique numbers. Both clocks will agree that "the time" is 1:00:00:00.</p>

<p>If you're just using timecodes to label each frame with a unique number then any scheme will do. If you need to match time of day, then you have to take the dropped numbers into account. What do you need to do with your values?</p>

CC BY-SA 3.0
2017-03-28T15:12:30.437Z
I should have noted that the start time of 10 hours is not a duration, only a marker, so it is treated as a constant or offset. The video didn't start at 36036 seconds, it started at 0 seconds. The first frame is labelled 10:00:00:00 but that's all TCs are: labels.
Jim Mack
CC BY-SA 3.0
2017-03-28T21:04:10.400Z
What I'm trying to do is this: I find comment markers in the Premiere project and then locate the corresponding video clip(s). Then I have to figure out how far into the clip this marker is set, and use that offset to extract a screenshot from the video with a different program (e.g. ffmpeg). For a video with start at 10h, the Premiere XML tells me it's 36036 seconds. I use that value in my marker offset calculation and end up 36s too early in the video file. With a 24 fps video I do not have this problem. I should probably provide more data in my question.
Thomas Tempelmann
CC BY-SA 3.0
2017-03-28T22:01:44.210Z
@ThomasTempelmann - I'm sorry I don't know how Premiere notes internal durations etc because this should be easy to solve with that info. You probably need to identify when a video is encoded at a non-integer frame rate and apply the DF correction (1000/1001), but the devil is in the details. If you could provide examples of all the constant values you can extract from both a 30fps and a 29.97 metadata set ('ticks' etc), then also some duration values from each and the codes they indicate, I'm sure we can tease out the info.
Jim Mack
CC BY-SA 3.0
2017-03-29T19:41:50.420Z
I now realized that I left some important info out, and that's also the solution to my problem: The problem is caused because I also read an EDL created by Premiere, and that EDL is missing the information whether a clip is DF or NDF. So, when it tells me that the 23.976 FPS clip starts at 10:00:00:00, and Premiere's project file says it's at 10:00:36:00, I have a mismatch. I was looking for a solution in the wrong place. The solution is to ignore the EDL entirely - then there's no problem.
Thomas Tempelmann
CC BY-SA 3.0
2017-03-28T14:53:09.447Z
2017-03-28T14:53:09.447Z
Jim Mack
<p>I am a programmer and am processing Adobe Premiere <code>.prproj</code> files. I read the contained XML data to figure out where a <code>&lt;Media&gt;</code> element's video file starts.</p>

<p>I have a video that's been recorded with a timecode starting at 10:00:00:00, i.e. exactly 10 hours, or 36000 seconds. That timecode is what Premiere shows for the start of the file.</p>

<p>The corresponding data in the project file is:</p>

<pre><code>&lt;Media ...&gt;
    ...
    &lt;Start&gt;9153720576000000&lt;/Start&gt;
&lt;/Media&gt;
</code></pre>

<p>That value uses ticks as unit.</p>

<p>Now, I make the assumption that one second equals 254016000000 ticks. That's because, when I have, for example, a sequence with 25 FPS, its FrameRate element in the XML specifies 10160640000 ticks, and that's exactly a 25th of a second.</p>

<p>But when I divide the <code>&lt;Start&gt;</code> value 9153720576000000 by 254016000000, I get 36036 seconds, and not, as expected, 36000 seconds.</p>

<p>So, by reading the XML values, I learn that the video starts at 10:00:36:00.</p>

<p>Curiously, that difference is exactly the 1001/1000 ratio of NTSC drop-frame timing, right?</p>

<p>Now, how do I make sense of the data in the Premiere project file? On one hand, its ticks base of 254016000000 is precisely identifying the used frame rates in the same file, so it must be the correct value for <em>ticks per second</em>. OTOH, it is off for time codes by 1ms per second.</p>

<p>How shall I interpret ticks values in the file? Shall I adjust them all by a factor of 1.001 to get the actual time code, or where's my error in all this?</p>

<p>Or is it a known fact that timecodes are not based on actual seconds but on 1.001 seconds?</p>

<p><strong>In other words, does 10:00:00:00 mean that it's actually starting at 36036 seconds?</strong></p>

<p><strong>Update</strong></p>

<p>It appears that there is indeed a drift with timecodes vs. real time, but only if the recording uses fractional FPS such as 29.97 or 23.976 (= 23.98), according to <a href="http://www.xdcam-user.com/2016/12/notes-on-timecode-and-timecode-sync-for-cinematographers/#comment-92739" rel="nofollow noreferrer">this article</a>.</p>

<p>And, indeed, the media file in question was recorded at 23.98 FPS.</p>

<p>So, am I right in the assumption that whenever I interpret a time code, I need to also look at the involved FPS, and if it's fractional, I have to add 1ms per second to the calculated time to be more accurate in the long run? (I do not care about single frame accuracy, so it does not matter when I apply the drift correction, it's only a question when to apply it at all.)</p>

<premiere><timecode><xml>
Premiere .prproj file ticks drift by 1/1000 compared to timecodes
Thomas Tempelmann
# Premiere .prproj file ticks drift by 1/1000 compared to timecodes

(Asked by: username_0 on 2017-03-28)

I am a programmer and am processing Adobe Premiere .prproj files. I read the contained XML data to figure out where a  element's video file starts.
I have a video that's been recorded with a timecode starting at 10:00:00:00, i.e. exactly 10 hours, or 36000 seconds. That timecode is what Premiere shows for the start of the file.
The corresponding data in the project file is:

    ...
    9153720576000000


That value uses ticks as unit.
Now, I make the assumption that one second equals 254016000000 ticks. That's because, when I have, for example, a sequence with 25 FPS, its FrameRate element in the XML specifies 10160640000 ticks, and that's exactly a 25th of a second.
But when I divide the  value 9153720576000000 by 254016000000, I get 36036 seconds, and not, as expected, 36000 seconds.
So, by reading the XML values, I learn that the video starts at 10:00:36:00.
Curiously, that difference is exactly the 1001/1000 ratio of NTSC drop-frame timing, right?
Now, how do I make sense of the data in the Premiere project file? On one hand, its ticks base of 254016000000 is precisely identifying the used frame rates in the same file, so it must be the correct value for ticks per second. OTOH, it is off for time codes by 1ms per second.
How shall I interpret ticks values in the file? Shall I adjust them all by a factor of 1.001 to get the actual time code, or where's my error in all this?
Or is it a known fact that timecodes are not based on actual seconds but on 1.001 seconds?
In other words, does 10:00:00:00 mean that it's actually starting at 36036 seconds?
Update
It appears that there is indeed a drift with timecodes vs. real time, but only if the recording uses fractional FPS such as 29.97 or 23.976 (= 23.98), according to this article.
And, indeed, the media file in question was recorded at 23.98 FPS.
So, am I right in the assumption that whenever I interpret a time code, I need to also look at the involved FPS, and if it's fractional, I have to add 1ms per second to the calculated time to be more accurate in the long run? (I do not care about single frame accuracy, so it does not matter when I apply the drift correction, it's only a question when to apply it at all.)

**Tags:** premiere, timecode, xml


---

## 1 answers

### Answer by username_1 on 2017-03-28. Score: 1

First, let me say that I have no idea what Premiere is doing with its values or what a 'tick' means in their terms. I can only speak generally.

The video frame rate should match the timecode rate, but for 'drop frame' timecodes the relationship isn't perfectly linear. There are certain timecode numbers that never show up in the sequence -- the ones that are 'dropped'. So for such codes you can't just perform a simple computation, you have to consider the drops.

Over the course of 1 hour there are 108000 frames at 30fps, but drop frame code will produce only 107892 unique numbers. Both clocks will agree that "the time" is 1:00:00:00.

If you're just using timecodes to label each frame with a unique number then any scheme will do. If you need to match time of day, then you have to take the dropped numbers into account. What do you need to do with your values?

> **Comments:**
> **username_1**: I should have noted that the start time of 10 hours is not a duration, only a marker, so it is treated as a constant or offset. The video didn't start at 36036 seconds, it started at 0 seconds. The first frame is labelled 10:00:00:00 but that's all TCs are: labels.  
> **username_0**: What I'm trying to do is this: I find comment markers in the Premiere project and then locate the corresponding video clip(s). Then I have to figure out how far into the clip this marker is set, and use that offset to extract a screenshot from the video with a different program (e.g. ffmpeg). For a video with start at 10h, the Premiere XML tells me it's 36036 seconds. I use that value in my marker offset calculation and end up 36s too early in the video file. With a 24 fps video I do not have this problem. I should probably provide more data in my question.  
> **username_1**: @ThomasTempelmann - I'm sorry I don't know how Premiere notes internal durations etc because this should be easy to solve with that info. You probably need to identify when a video is encoded at a non-integer frame rate and apply the DF correction (1000/1001), but the devil is in the details. If you could provide examples of all the constant values you can extract from both a 30fps and a 29.97 metadata set ('ticks' etc), then also some duration values from each and the codes they indicate, I'm sure we can tease out the info.  
> **username_0**: I now realized that I left some important info out, and that's also the solution to my problem: The problem is caused because I also read an EDL created by Premiere, and that EDL is missing the information whether a clip is DF or NDF. So, when it tells me that the 23.976 FPS clip starts at 10:00:00:00, and Premiere's project file says it's at 10:00:36:00, I have a mismatch. I was looking for a solution in the wrong place. The solution is to ignore the EDL entirely - then there's no problem.  

---

