Premiere Pro Mismatch - Export is 3 Secs Longer Than Sequence Duration

[Guest]

Hello everyone,

I have an issue here with PP CC 2015 - or maybe I do not understand frame rates / time codes correctly.

Here's the PP project info:

> PP sequence setup is 23.976p

> all footage used in the sequence was shot at 23.976p

> timeline in the sequence shows a total duration of <b>00.39.59.19</b>

> when I export the video as 23.976p, it then shows a duration of 40 mins 2 secs in MediaInfo - a full 3 secs difference

> VLC player shows a duration of 40 mins 2 secs as well when playing the file yet the time code that was burned into the exported file shows 0.39.59.19 on last frame...... (?)

When I import that PP video file into Pro Tools into a 23.976p timeline it shows a duration of 0.39.59.19, but when I click on video properties I see 40 mins 2 secs 19 frames...

What am I not understanding here ? Shouldn't these SMPTE timcode values refer to the actual length of the sequence depending on the frame rate setting ?

Why does the total duration of my export differ from what was stated in the sequence timecode ?

Thanks !

[excited_Genie16B8]

I think the reported duration is not something you need to worry about.  Your sequence is coming out correctly.

[Meg The Dog · Accepted solution]

It's the difference between a 23.976 frame rate and real time.

24 fps (23.976) video is always non-drop timecode. There is no standard for 24fps drop frame code. And within Premiere Pro, your are reading the total running time based on non-drop frame timecode - so it is giving a time readout duration based on frames - which does not match real time - since the frames are running slightly slower than real time (23.976 fps as opposed to true 24fps).

Over the period of 30 minutes, this slow frame playback is making the show length run longer in real time by about two seconds per 30 minutes of program length.

This why in NTSC 29.97 and 59.94 video there is drop and non-drop timecode. Drop frame timecode drops timecode numbers at specified intervals over time to compensate for this difference - that the video rate is slightly slower than real time. By dropping a timecode number, the duration amount displayed increases on each dropped timecode number.

In drop frame timecode, when you have a duration of 30 minutes, it coresponds to real time 30 minutes.

Here's the math:

If you had 30 minutes of footage running at true 24 fps - 24fps X 60 seconds = 1440 frames in a minute, 1440 x 30 minutes = 43200 frames in the 30 minute show. (So non-drop TC, which counts the frames without regard to the true playback rate, displays a duration of 30 minutes - 43200 total frames, divided by 24(fps) = 1800 seconds = 30 minutes).

But since the video, is, in fact, running slightly slower, at 23.976, those 43200 frames take longer to play out over time by .024 frame per second of real time.  So 43200  (your total show amount of frames) divided by 23.976 (the playout per second frame rate) = 1801.801802 seconds, which is 30 minutes, 1.8 seconds.

Avid used to ( and maybe still does) come with a calculator to make this conversion and to help make the frame count = the desired running time. Both Premiere, and legacy FCP do not - I don't know if FCP-X does.

It should be noted that within commercial spot production, with durations of 30 or 60 seconds, this whole mess is less apparent. It only shows up when you work with program length material. This is why they drop frame timecode was invented.

It doesn't sound like you are aiming for a target show length, like a network time slot that require 28:30:00 on the frame, but if you were, a solution is to tighten up the edit by 1.8 seconds over 30 minutes

MtD

[Guest]

@ ACP: thank u for confirming that PP does not show real time as time code values, ergo not adjusting for the 0.024 drop.

Unfortunately I do need this to stay exactly under 40 mins, and believe it or not, there are no 3s to cut.

PP was just the edit, this 3s offset has trickled down to all other apps (sound, score, grade) and all of them do display the time code as well as u explained - and all of them referenced the PP video.

Def cutting the next one in Avid if they still have correct display..

what is the point of displaying time code duration if it is incorrect... ?

[Meg The Dog]

As I said, there is no drop frame option for timecode at the 23.976 frame rate - on any system. You only have one choice for timecode at 23.976:

So you have to have a way of determining what the realtime length is going to be - there are on-line calculators available to do the math - you can google search for them.

If I have to edit program length material at 23.976, I create a second sequence at 29.97 Drop Frame and nest the first sequence (the 23.98) into the 2nd as needed during the edit to check program length.

MtD

[Guest]

@ ACP: yeah.... my point was:

in 2018 u have to create a 2nd sequence in PP in order to get correct time code duration.... ?!?

wow. just wow.

the simple math that u provided above could be integrated into PP in 5 mins, and then simply show correct time code as per the chosen fps for that timeline... or at least a second timestamp that is correctly adjusted for 23.976... because what they call "23.976" is actually 24 fps

unreal I cannot trust a time code display - no matter what the frame rate is. that is just a parameter in an equation.

[Meg The Dog]

pete_f  wrote

n 2018 u have to create a 2nd sequence in PP in order to get correct time code duration.... ?!?

No, but you have to know what you are doing.  There are consequences to working in 23.976 code that have been present as long as timecode has been around, and you have to know how to deal with them to avoid issues.

the simple math that u provided above could be integrated into PP in 5 mins, and then simply show correct time code as per the chosen fps for that timeline... or at least a second timestamp that is correctly adjusted for 23.976... because what they call "23.976" is actually 24 fps

I'm not sure what you mean. Premiere Pro is doing exactly what you are telling it to do. Work with a sequence timebase of 23.976 and display the timecode accordingly.

unreal I cannot trust a time code display - no matter what the frame rate is. that is just a parameter in an equation.

That is simply not the case. You are confusing the timecode of sequence with the real time duration, which is something different.

You would have the same trouble you are having now if you had a sequence set to 29.97 non-drop frame timecode. The timecode would not match the realtime running duration. Non-drop code runs at the 29.97 frame rate - which is why drop frame code was invented, to circumvent these issues.

You have to know which to use and the consequences of the choice you make. This would still be true if you were working on Avid and not aware of these consequences, how would you know to change the display to reflect the real time running time?

MtD

[Guest]

the point is that time code duration has ONE MAIN PURPOSE: the real world run time. And that is incorrectly displayed in a 23.976 timeline.

Nobody is interested in a fictitious duration value that has zero use. (because it is false)

Again, the duration is there for us to know how long the actual, real world run time is.

General frame based SMPTE time code - the SMPTE timestamp - identifies what a frame is. That is of course displayed correctly.

The fact that u have to write "one should google for online calculators" to know the actual real world run time shows how insanely idiotic this is. U're sitting in front of a computer which does on thing only: calculate. Using a high-end, expensive, professional editing app that ultimately does not tell u how long the run time will be in the real world, which is an easy calculation (as u have demonstrated).

and then people like u use external online calculators... or remember to leave 1.8s space in a 30 mins cut... that, in 2017, in professional editing...... un-freaking-real

Has nothing to do with "knowing what u're doing" - the sole purpose of the app (--> Premiere) is to do that work for u ! Ur job is to edit.

and since we all know the problem, and the equation is super easy, there is zero reason not to show the actual, real world duration within the GUI - can be an extra field or enabled via preferences.

2017 and I have to suggest that feature. wow.

Thanks again for ur help and explaining the problem. I'm stunned though u defend the status quo of PP on this. I guess u just got used to it.

Thanks !

[brian704]

"the point is that time code duration has ONE MAIN PURPOSE: the real world run time"

ABSOLUTELY INCORRECT - the purpose of time code has always been to allow frames to be marked and accounted for in a computer data base. Just because you do not understand this art of post production, and you would like it another way does not mean that is what it is for. I would imagine that time-code is older than you are - they started in 1967. Drop-Frame Time code was created to correct for the problem you are complaining about.

.

[Guest]

@ brian704:

maybe u should read my answer before replying.... ?!

I stated that ​time code identifies what a frame is. It has nothing to do with a "computer database", although I can only assume u don't even know what a data base is.

But, back to the point... this is about the displayed timecode duration... DURATION... DURATION. not timecode in general. and that is incorrect in a 23.976 timeline, ergo useless. U have to calculate the real duration urself.

the duration (the real world length in time of footage) is obviously important when exporting sequences..............

[brian704]

OK so you have no interest in understanding what time-code is. You are asking it to do something it was not designed to do. Computers started editing back in the late 60's, I started in the early 70's. Writing database programs too, by the way. Duration is not what time-code is for. It would help you to learn a little about the history of your craft before you go ranting and degrading.

[Guest]

why are u in this thread ? u have no idea what u're talking about and now u're back tracking.

for the last time: timecode is a timestamp. the duration is obvious the time difference between two timestamps, which are based on the respective timecodes.

timecode itself is obviously essential. it is the duration display that needs to be accurate in real world time so that when exporting a certain time range, we know exactly pin-point to the frame in real world time the duration of the exported file.

if u don't understand this then I can't help u. this is a bare bones necessity.

And editing program that does NOT tell u the real world time of how long ur exported file will be is a joke. People having to manually calculate the real word time is a joke.

I understand that ur amateur hobby videos don't need to comply to specific lengths and duration. Understand that certain professional deliverables have very strict time restrictions.

[brian704]

So I repeat - you have no desire to learn about the tools of your supposed craft.

I have worked for over 40 years doing this - starting with Quad tape - something you've probably never heard of. I've worked for 3 major networks and countless productions. But you are obviously light-years ahead of us peons.

[Guest]

exactly, don't argue with a guy that is light years ahead of u.

when u say "learn about the tools", u actually mean "memorize bugs/problems/gotchas/idiotic behavior and then work around that". That is ur point. wow.

Man, have u been beaten senseless by the cluster array of inefficiencies some of these apps introduce and never fix or address. I know, I do full prod cycle - all fields. but this right here is massively dumb.

there is no argument against what I say. Every professional editor agrees. Guess why Avid had it integrated... ? Naturally if u only do features and or material that does not have time restrictions this will never creep up and/or be a problem...

at the very least - the very least - in the PP Media Encoder export window, when exporting from a 23.976 sequence - the real world duration should be displayed to the user.

[Guest]

the reason why I hammer on PP and not all other post prod apps that show exact same behavior, is because the edit is obviously the first step in the post prod pipeline and all other apps referencing the edit will be affected...

so if - as suggested here - we would make additional edits to stay below the actual real world duration restriction, then we would have to make adjustments to 9 timelines and sequences in 9 other post prod apps that were used for this project... a major cluster.

Fortunately, we found a better solution.