24p & 23.976 Timecode question

[neil wilkes]

When I have a sequence set to 24p, is the displayed timecode in the sequence in 24 or 23.976 form?

I ask as Chapter marks often seem off, and even with 24p sequences I seem to get output of 23.976 according to the media encoder.

Yet under sequence settings it states timedcode display = 24, and not 23.976.

What is the timecode display in the sequence actually showing me please? 24 drop or 24 non-drop? (24 or 23.976) and does it actually matter?

I am running PPro CS6.0.4 in this instance

Thanks

[excited_Genie16B8]

I don't think there's any difference where timecode is concerned.  Seems like drop frame only applies to 30i.

[jamesp2]

A sequence time-code setting of 24 only means that the system will count from 0 to 23 and then starts the frame count over again.  It doesn't indicate the actual time-base of the material.

When you create a sequence, and choose a 24p present, you'll note that the preset description indicates the time-base is actually 23.976 -- because video does not run at 24fps.  All time-line timings should reflect that fact.

[Steven L. Gotz]

You can go to the Sequence menu and ask for the Sequence Settings and you should see if you are viewing Drop Frame or Non-Drop Frame (24 or 23.976) in the Video box under Display settings.

If you are trying to match things up, you might find that changing it over to "Frames" instead (temporarily?) might help you to find the solution to your issue.

[jamesp2]

Steven Gotz wrote:

You can go to the Sequence menu and ask for the Sequence Settings and you should see if you are viewing Drop Frame or Non-Drop Frame (24 or 23.976) in the Video box under Display settings.

I believe you're mistaken here.  There is no option, in PPro or anywhere else, for 24fps drop frame time code.  It's either 24fps running at 24fps, or 23.976fps running at 23.976fps.  Material shot on film at a true 24fps time-base is played back in video at 23.976, but that's a different issue.  Once it's in video, it stays at 23.976 and that's the only time-base to measure it against.

[Steven L. Gotz]

You are correct. I was wrong. Sorry about that. I was looking at the wrong thing, or rather, looking at it the wrong way. My apologies.

I just put one minute of 24fps video from my Panasonic DMC-GH3 on a timeline. I then copied it over to create a 40 minute timeline.

If I multiply 24 frames per second times 60 seconds, I get 1440 frames. Multiply 1440 by 40 and I get 57600 frames. I figured that would be long enough to detect any frame count issue.

If I look at the timeline using 24fps as the setting, I see 40 minutes exactly. If I look at Frames, I see 57600. Therefore, footage shot at 24fps seems to be 24fps and not 23.976. Not so, as you have pointed out. So I looked deeper.

My findings indicate that even though when I drop the footage on the "New Item" button I get this indicating that it shows up as 24fps but is being played at 23.976

However, as I started to suspect using your information, if I look in the Sequence properties, I see it is longer than 40 minutes and yet the timeline says 40 minutes.

The same thing showing frames:

So that left me with the question of what the correct duration actually is. I get that the number of frames is just the number of frames no matter how fast they play back, but if the timeline says 40 minutes then it darn well ought to be 40 minutes. But it isn't!!!

Time to check this in a different program.

I put some audio below it and exported to Audition. It was longer than 40 minutes. Same thing when brought into After Effects.

So, why in the world doesn't Premiere Pro have a Drop-Frame timecode for 24fps? Or am I missing something else? What is the correct method to work with this footage if the timeline lies to us?

Very odd, and I thank you, James, for correcting me.

[jamesp2]

Far as I can tell, it's true that the time indicator in PPro's time-line isn't accurate -- it's based on a 24fps clock, not the actual time-base of 23.976.  So everything will be .1% off.  Doesn't amount to much -- a few seconds on a feature length movie -- and won't affect sync, but the discrepancy is there.

Some HD cameras record true 24fps, and there's doubtless software around which can play it at that rate (not 23.976), but PPro doesn't appear to be one of them(?)

[Steven L. Gotz]

It seems quite inconvenient.

I don't normally sync up external audio to my video in one long piece, so I am not sure I would have noticed.

My current project started with a 3 minute piece of audio and I am going to cut to that. The time difference probably would not have been an issue because I am cutting to the beat, more or less, but if I had to be dead on accurate, it could have been a potential problem.

I must be missing something. How have people put up with this all this time?

[jamesp2]

There should be no sync issue.  Virtually all "24p" material in the HD world is recorded at 23.976, so it's playing back in PP at the correct, real-time speed.  You'd only have problem if you were playing back true 24fps at 23.976, and your audio was running real-time.  In that rare case, you'd have to slow your double-system audio down .1%, to avoid drift.

In the film world, audio is routinely "pulled up" and "pulled down" .1% to account for these speed changes, going from video to film and vice versa, but in the world of HD acquisition, nobody has to worry about it any more.  Everything is 23.976, so everything plays back at the speed it was recorded.

[Steven L. Gotz]

...and your audio was running real-time.

Well, yes, I edited the piece in Audition to make it exactly 3 minutes long. If it had been important, I should have taken that into account. At least I will know for next time.

It just seems, so, well, I don't know, wrong?

If the audio had to sync to the video it would be really irritating. I am new to 24p, late to the party, so to speak. I really had no idea that this was "normal".

[tenorocity]

I'm also dealing with the same issue.  Without a dropframe timecode, how exactly does one know the real time of a 24p sequence (with 23.976 timebase)?  In certain commerical broadcast situations this is critically important. 

Going back to the sequence properties as I trim an edit is certainly not an option.   Has anyone figured a way around this? 

Thanks.

[JaysonM-Y]

tenorocity wrote:

...Without a dropframe timecode, how exactly does one know the real time of a 24p sequence (with 23.976 timebase)?

I'm not sure I understand the question.
If media 23.976 and sequence 23.976 then I export said file and bring it to a "true" 24fps timeline, I get the same duration as the exported clip. Then again it clips a frame, but hey, it's still the same time.

[neil wilkes]

jamesp2 wrote:

There should be no sync issue.  Virtually all "24p" material in the HD world is recorded at 23.976, so it's playing back in PP at the correct, real-time speed.  You'd only have problem if you were playing back true 24fps at 23.976, and your audio was running real-time.  In that rare case, you'd have to slow your double-system audio down .1%, to avoid drift.

In the film world, audio is routinely "pulled up" and "pulled down" .1% to account for these speed changes, going from video to film and vice versa, but in the world of HD acquisition, nobody has to worry about it any more.  Everything is 23.976, so everything plays back at the speed it was recorded.

It's not sync that is the issue here for me, it is accurate placement of chapter markers (or in a music title where it is critical - song markers).

Premiere also gets this one badly wrong in SD - it uses a 30fps base, but what is needed is 29.97DF.

I cannot understand this omission - it is the one thing that Vegas Pro gets done better than Premiere (and I mean the ONLY thing - Premiere knocks Vegas into a cocked hat in all other respects) as it offers the timebase in whatever timecode you need to use - so gives 24p, 23.976 (aka 24p drop frame), 30, 29.97DF, 29.97NDF etc.

Why can Premiere not give us the same flexibility, as converting supplied EDL to conform with Premiere's clunky approach is time consuming at best & damned annoying at worst

[Steven L. Gotz]

or in a music title where it is critical

You would think that this would have been solved a long time ago.

Now that I know about it, it won't ever be an issue for me. I would rather cut to music than design music to fit, so as long as the music is the correct duration, the video will come out OK. I just need to make sure I do it in that order.

Or, I suppose I could always create a full minute of silent audio in Audition and use it as a place marker to help me keep track of time when I work in 24P. Or maybe even put a beep every 60 seconds.

Is that what it is? Everybody is just supposed to know, and then we either ignore it or use workarounds? Odd.

[tenorocity]

@ Jayson,

I just re-created the test you made, with similar results. 

But this raises a whole host of other questions.

Let me explain what I did: 

I created a sequence with a 23.976 timebase and 24p timecode display in Premeire Pro CS6

I inserted a "10-minute" clip of footage.   By "10 minute" I mean the non-drop-frame 24p timecode read  00:10:00:00 at the end of the sequence. 

The whole question here is whether or not 00:10:00:00 equals 10 minute of "real" or "wall clock" time.   Theoretically it should not.  If the time base is 23.976 fps, the sequence should be somewhat longer in real time.  This is what we all have experienced with SD footage shot at  29.97 fps and is the whole rationale behind drop frame timecode, i.e, to make the timecode in the sequence match the real time.

And voila!  If in PP CS6 I right click on the sequence icon in the Project pane and look at "Properties," I'm told that the sequence is, in fact, longer than 10 minutes. I'm given the following length, expressed in drop-frame timecode:  00;10;07;15.  

Then I exported the file at h.264, with 23.976 fps setting, using one of the PP output presets.  When I opened it up in QT, the sequence length was exactly 10 minutes! Like you, I then imported this new .mov seqence back into PP, and put it into a sequence.   The 24p non-drop-frame timecode at the end of the sequence read 00:10:00:00. 

But now, if I looked at the Properties of the sequence, I get something close to 10 minutes, but not exactly, once again expressed in  drop-frame timecode:  00;10;00;18.  The exported sequence is marginally longer than the "real time."   

The good news for me is that a 23.976 timebase sequence with non-drop-frame 24p timecode seems to conform basically to real time once exported.  

But why?  

Is media encoder doing some extra math to make up for the disparity between a 24p non-drop-frame timecode and the 23.976 editing timebase?

And why the difference between the length of a sequence as read in Properties, vs. that read in the sequence.  And why is the timecode in Properties expressed in drop-frame if there is no drop-frame option for timecode in the sequence itse?

Bewildering.

[jamesp2]

tenorocity wrote:

Then I exported the file at h.264, with 23.976 fps setting, using one of the PP output presets.  When I opened it up in QT, the sequence length was exactly 10 minutes!

Unfortunately, that result doesn't prove anything.  QT is probably just playing back the sequence at 24fps, either because of a default, or a flag in the exported footage.

In the end, all you have to count are your frames.  Whether they're played back at 23.976 or 24, will determine the "true" length of the program, plus or minus .1%.  It's highly unlikely that the media encoder is, unprompted, converting 23.976 to 24fps, which could in itself create all sorts of problems.

[tenorocity]

@james2,

But does the length of the exported (and then re-imported sequence) shown in Properties reveal the real time?

"But now, if I looked at the Properties of the sequence, I get something close to 10 minutes, but not exactly, once again expressed in  drop-frame timecode:  00;10;00;18.  The exported sequence is marginally longer than the "real time."  

The good news for me is that a 23.976 timebase sequence with non-drop-frame 24p timecode seems to conform basically to real time once exported."

And the question still remains:  why not have a drop frame time code for 23.976 footage?  Was this an absurd engineering oversight or is their some rationale behind it?

And if there is no 23.976 drop frame, why is the length of the sequence expressed in drop frame (XX; XX; XX; XX) in Properties? 

[jamesp2]

On second thought, QT is almost certainly doing the same thing the PP time-line is doing:  using a 24fps count for a 23.976 time base because, again, there's no such thing as 24fps "drop-frame" time code. 

Played back in QT, your test almost certainly has a duration longer than 10 minutes, exactly as it does in PP.

[Guest]

23.976 is not used for broadcast, only 29.97.

I think that if you switch to show audio time units, you should get the real world clock.

[tenorocity]

@strypesinpost,

Thanks for the reply.  Guess this is a moot point for broadcast.   But now that I'm into the problem, I still have questions.

Getting back to the "10-minute" sequence I created in the 23.976 timebase with the 24p timecode, audio units indicate that the length is  00:10:00:600 (in millseconds). 

That's good to know since the 24p timecode shows 00:10:00:00  But, once again---even if I'm being purely academic here---this actually seems a little short considering that we're on a 23.976 timeline.  Shouldn't the real time be longer?  And what exactly does the drop-frame expression in Properties (00;10;07;15) indicate?

[jamesp2]

tenorocity wrote:

Getting back to the "10-minute" sequence I created in the 23.976 timebase with the 24p timecode, audio units indicate that the length is  00:10:00:600 (in millseconds). 

That's good to know since the 24p timecode shows 00:10:00:00  But, once again---even if I'm being purely academic here---this actually seems a little short considering that we're on a 23.976 timeline.  Shouldn't the real time be longer?  And what exactly does the drop-frame expression in Properties (00;10;07;15) indicate?

10 minutes, 600 milliseconds appears to be exactly correct, for a 10 minute sequence (as clocked at 24fps), when played back .1% slow (23.976fps). 

However, the 10;07;15 doesn't seem to make any sense.  Even if there was such a thing as drop-frame 24fps, for which semi-colons were appropriate, there's no way a 10 minute sequence runs slow by over 7 seconds.

[tenorocity]

@james 2,

Once again, thanks for the clarification.  

The drop-frame indication in Properties still remains a mystery.   Additionally mysterious is this:  if you customize your metadata in the project pane to include "video usage," you will also get a drop-frame indication of where clips begin in a particular sequence!  In fact, it was noticiing this that got me thinking about this whole issue altogether.

Is this some strange bug in PP CS6?  Or an intentional feature designed to drive us crazy?  

Try it for yourself. 

[ebenabbaan]

Have we found an answer to this issue yet?  I have a 1:36:04 feature film with burned-in timecode (via the effect and an adjustment layer) that is, apparently, 1:36:10.

A discrepancy of six seconds... what is that?

[nolanm88605216]

So I've been having similar issues. I'm still looking for a solution but here is the answer in this thread.

Re: Why is my exported file 2 seconds longer than the project in my timeline

[neil wilkes]

Did we ever get a definitive answer to this one?

I am finding that it is a PITA with Blu-ray discs and Chapter Mark placement, especially in an audio title.

Scenarist BD will happily accept both 23.976 and 24fps footage and uses a different timebase on each.

Ditto my Audio Editor, Nuendo.

If I set the DAW timebase to 23.976 one song enters (and these are tight segues so I need frame accuracy here) at 00:28:06:13

If I set the DAW timebase to 24, t he exact same location is now given as 00.28.08.06

This is a difference of almost 2 seconds, and the difference gets longer the further into a sequence I go.

Now - if PPro is at 24, then it's nomenclature is wrong as it is using colons so that implies it is telling me time at 23.976.

This matters - all my footage is edited and supplied to me at 23.976, and it is for Blu-ray so I need to use track points and I must use the right timebase or else I end up with incorrect values and the start of songs get nipped off.

Right now, simply because I cannot trust what I enter, I find myself in the ludicrous situation of having to render my production audio in W64 from Nuendo but at the same time I need to also render a WAVE file (PPro still cannot understand a W64 file for some stupid & unknown reason) purely for sync reasons to use in Premiere to get timings set up.

Talk about a workflow killer!