23.976 sequence and total running time

We're cutting a 13 episode series, finishing in HD at 23.976. We're editing offline in FCP in sequences set at 23.976 and going to online out of house, ending up on HDCAM SR. The question I have is...
How does one accurately assess total running time in a 23.976 sequence?
Anyone have a suggested workflow for this issue? I feel like I am missing something...something simple....?

Do you do a lot for broadcast? All broadcast is 29.97. Get your TRT from the sequence...

I've done tonnes of broadcast and a bunch of film. This is the first time working towards a 23.976 finish though.

Our delivery spec is for a 23.976 HD master. The broadcast HD, NTSC and PAL masters will be pulled from locked 23.976 HDCAM SR masters.

So...in FCP if I am cutting at 23.976 my sequence TC will not be an accurate representation of clock time. That, perhaps, is a better stating of my question. I can always dump a 23.976 sequence, nested, into a 29.97DF sequence to check length but I was wondering if anyone had another, better, workaround.

ak

Someone please correct me if I'm on the wrong track.

30 minutes at 29.97fps works out to 30 minutes.

30 minutes at 23.98fps works out to 30 minutes.

30 minutes at 3fps works out to 30 minutes. (Thirty minutes of a painfully slow webcam.)

So, whatever your sequence reads for the TRT, is the TRT. If you convert it to something else, it will have the same TRT. If you throw it in something else without converting it (I don't know if this is even possible in FCP), you will get the wrong TRT, and video that's been speeded up by a ratio of 3:2. (Or, in the case of your webcam... 10:1.)

I would love to stand corrected on this as it would make my life easier, but as I see it
The 30:00:00 mark of a 29.97 DROP FRAME sequence is not the same duration as
The 30:00:00 mark of a 29.97 NON DROP FRAME sequence.
The Drop Frame sequence is accurate 'clock' time because of the skipped frame numbers, which make up for the frame duration not being an integral division of 30.

I took it for granted that the same would apply to 23.976 Non Drop TC. It's counting 24 frames per second but not playing 24fps, therfore your sequence time is not the same as actual running time.

I think that makes sense...

Mike you are on the wrong track, kind of!

Yes 30 minutes of time is 30 minutes of time regardless of the frame rate. However 30 minutes of program on a 29.97fps timeline if started at hour 1:00:00:00 would not end at hour 1:30:00:00. In this case your 30 minutes of "clock time" would actually be up at around 1:29:28:06 on the timeline timecode. In other words if you finish your program at hour 1:30:00:00 on a NDF time line the program would actually be about 30 minutes 1 second and 24 frames long. That is why DF timecode was created, to compensate for the fact that NTSC video runs at 29.97 fps which is .03 fps slower than 30 fps so each frame in 29.97 is a bit longer than 1 second. We needed a way for the timeline to accurately reflect "clock time" for broadcast purposes so drop frame TC was introduced.

Mike Watson Wrote:
-------------------------------------------------------
> Someone please correct me if I'm on the wrong
> track.
>
> 30 minutes at 29.97fps works out to 30 minutes.
>
> 30 minutes at 23.98fps works out to 30 minutes.
>
> 30 minutes at 3fps works out to 30 minutes.
> (Thirty minutes of a painfully slow webcam.)
>
> So, whatever your sequence reads for the TRT, is
> the TRT. If you convert it to something else, it
> will have the same TRT. If you throw it in
> something else without converting it (I don't know
> if this is even possible in FCP), you will get the
> wrong TRT, and video that's been speeded up by a
> ratio of 3:2. (Or, in the case of your webcam...
> 10:1.)

Andrew, I think your best bet is to get a timecode calculator so you can accurately work out where your breaks need to be and total run time for broadcast. Just do a google search for timecode calculator. There are a lot of them available for free or a few dollars.

So, as there is no capability in FCP for 23.976 Drop frame sequence TC that I could find, how are people checking duration other than running 23.976NDF times through a TC Calculator?
ak

EDIT: just saw your post Frank. Thanks, I guess that's the way to go.

I work in thirty second commercials and 1:15 news packages, so I'm talking (mostly) out of my ass here.

But if drop frame was created to match real time,here's an explanation, and you're converting 30 minutes of 24 fps drop frame to 30 fps drop frame... why wouldn't it still be a half hour? They're both drop frame timecodes. I understand they may be a few frames off because of the conversion, but...

I don't get it.

There is no 23.976 Drop frame TC in FCP.
It's Non-Drop all the way, as far as I can tell.

Hi,

Not new to the forum, but new to the new version of it. Currently no idea at what part of the thread it will show up.
With NTSC you got either DF or NDF and always slow seconds - sometimes not displayed. So it's not that difficult to calculate run times
23.976 is NDF and slow seconds.
29.97 video is DF and displays real seconds.
30.00 is NDF and real seconds
29.97 audio maybe DF and real seconds or maybe NDF and slow seconds.
59.94 is NDF and slow seconds.

To get the real world time in hh:mm:ss just open the final movie in QT Player.
To get the real world time in TC download my readXML and open the final movie there, it will show you all times.

Kind regards
Andreas

Using the Pomfort FrameCalculator I just found, a show like ours that is supposed to time out at 22:15 including 3 ten second blacks and all packaging, would in a 23.976 sequence that ended at 22:15:00 actually be 22:16:08 in realtime ( I just got the TC Calc, and I think that's right but I haven't read the How-to yet)

Thanks everyone...

Mike Watson Wrote:
-------------------------------------------------------
> I work in thirty second commercials and 1:15 news
> packages, so I'm talking (mostly) out of my ass
> here.
>
> But if drop frame was created to match real
> time,here's an explanation, and you're converting
> 30 minutes of 24 fps drop frame to 30 fps drop
> frame... why wouldn't it still be a half hour?
> They're both drop frame timecodes. I understand
> they may be a few frames off because of the
> conversion, but...
>
> I don't get it.

Mike,
no one said anything about going from 24DF (actually 23.976) to 30 DF (actually 29.97).
What Andrew is talking about is trying to accurately determine the correct run time in a NDF sequence. The timeline readout in a NDF sequence is not accurate to wall clock time so you need a TC calculator to work out what your timeline readout would be at the end of the program in a NDF sequence to accurately reflect "real clock time".

Andreas Kiel Wrote:
-------------------------------------------------------

> 23.976 is NDF and slow seconds.
> 29.97 video is DF and displays real seconds.
> 30.00 is NDF and real seconds
> 29.97 audio maybe DF and real seconds or maybe NDF
> and slow seconds.
> 59.94 is NDF and slow seconds.

>
> Kind regards
> Andreas

Andreas you are mis-informed on this.
29.97 video in NTSC can be either NDF or DF.
There is no such thing as a slow second. A second is a second!
In NTSC video, 1 frame is a bit longer than 1/30 of a "real second" because it runs at .03fps slower than 30fps.
You need to think of timecode more like a labelling system for each frame rather than actual 'real time" or it is easy to get confused.

Frank, I have worked with Andreas on some issues we had with his highly useful, and crucial to our production, BWF2XML utility and after a bit of confusion I came to understand his use of terminology which was actually helpful in describing the issue to a non-tech person who was getting caught up in all the numbers and acronyms.
By 'slow seconds' he means that one second of TC would be longer (slower) than a wall clock second. Sort of another way of putting what you were describing earlier to Mike with your

Quote

In other words if you finish your program at hour 1:30:00:00 on a NDF time line the program would actually be about 30 minutes 1 second and 24 frames long

but filtered through a guy who knows his stuff from a primarily PAL land and does pretty well in what I think is his second language after German(?) Hi Andreas!

We're all talking about the same thing right about now and I am going to use a TC calc to solve my problem...so unless anyone has any other suggestions we're done here.
Thank you all for all your help, Frank, Mike, Andreas .
ak

Cool, glad you got it sorted out.

Hi Andrew,

I just started to write an answer on Frank's reply and to explain again the slow time stuff, you were faster, I saved time ;-)
Glad you solved it Andrew, good luck.
And again download the free "readXML"; the movie player of it will give you all "times" you ever need without the need of calculating numbers.

Kind Regards
Andreas