QT 23.98 video frame rate... timecode rate?

[dopplah]

I'm working on a show that has begun delivering 23.98 (HD?) QuickTime files for me to sweeten to.

Two questions-- does the PT need to be at 23.976 in the "Feet+Frames Rate" box?

And, am I OK running 29.97 DF timecode, or do I need to run 23.976 timecode?

dopplah

[minister]

if you are not running film, then you don't need the feet+frames.

i take it you are an LE system w/o DV TK which is why you can't run 23.976? if you can, you should.

drop frame is for broadcast only. why are you asking about drop? because the 23.98 is drop? if the 23.98 is ND then make the 29.97 ND as well.

QT will allow you to run 23.98 through FW to a 29.97 TV.

[StavrosSound]

Always run your session in the framerate your video source is. If its 23.98 ND, then your session should be too.

This will maintain sync with your timecode burn in. Hopefully you recieved the video source with a 23.98 burn-in at 2-pop with bars/tone at 00:59:58:00? If not, ask for that for the editor.

As minister said, ALWAYS run Non-Drop unless you are told to do so (for broadcast/TV).

[dopplah]

>I take it you are an LE system w/o DV TK which is why you can't run 23.976

Nope, I'm on an HD2, so 23.976 TC is available to me. I did the previous season at 29.97 DF TC, and we've vacillated back and forth between file-based and tape-based (digibeta), so I left the TC at the specs from last year.

The provided video did not have a burn-in. I'm sure I could request burned in TC, but it gets in the way of some visuals. I ask them to provide the file starting right on 1 hour. I then deliver a mix also starting right on the top of the hour.

My impression was that the FRAME RATE of the video and the TIME CODE RATE were exclusive to one another. As long as I'm not pulling down (or up) the speed, or frame rate of the video, I can assign any time code rate to it I please. It will change what timecode a specific point in the show is, but not what sound occurs at that location, so my sounds will remain in sync.

True????

dopplah

[minister]

if you are on an HD system then run the frame rate of the production. this should remain consistent through all steps unless the change is discussed and fully understood. why are you trying to run a different frame rate? because of the previous season? well, if this season is 23.976, then run this season at 23.976.

it is true that audio speed is governed by sample rate clock and video by frame rate -- btw, i don't understand your distinction between FRAME RATE AND TIME CODE -- but you are either putting a 23.976 QT into your 29.97 PT session or running 29.97 MTC or LTC to a VTR of some sort? you are asking for jittering. also, your frame boundaries will be off. what will your QT do with frame 25?

apologies if this seems terse, but your situation seems like a simple one : run 23.976 if that is indeed the rate of the program. if you are using elements from a previous season that were 29.97 D, then import them into your 23.976 session.

[z-plane]

Frame rate must be that of the video.
Timecode setting determines what the rulers diplay (grid).

Both set to same value gives snapping to frame boundaries.

If you have frame rates higher than 30 FPS then PT syncs
properly only if TC rate is set to half the frame rate.

The only problem you might run into with unmatched settings*
is that most (all?) Avid systems don't have resolution greater
than the frame rate setting. So if you intend to export your work
as OMF/MXF using the ''bounce to disk'' or the ''export regions as files''
commands then your regions will be offset to the nearest frame boundary
in an Avid system (media composer, adrenaline etc).

The ''export selected tracks as new OMF/AAF'' command fixes this
automatically by adding one frame files (OFFs) when you tick the
''quantize edits to fit frame boundaries'' option.

EDIT:
*if the regions in your session don't snap to frame boundaries

[dopplah]

Firstly, thanks for the help! Breathe easily-- I am running 23.98 timecode now, per comments above. However, I still have some questions I'd love to clear up.

> btw, i don't understand your distinction between FRAME RATE AND TIME CODE

I thought that frame rate was how many frames per second at which the video plays. Time code is used for synchronization and, I thought, did not HAVE to match the frame rate of the video. Of course my frames of audio would not directly line up with frames of video, but the relative position within each second would be fine. If it sounds good, it is good, right??!?

The main reason this has been so bewildering is that we have a client whose specs on ADR sessions have the video frame rate at 23.98 and the timecode at 29.97 NDF. When asked why, we got "it works fine that way."

> why are you trying to run a different frame rate? because of the previous season?

Arrggh! Perhaps I wasn't clear above. I was running 29.97 timecode because I had received multiple drafts of the same episode. OMF 29.97 DF TC, 1st video draft digibeta (29.97 DF TC), 2nd video draft QT 23.98 frame rate.

And now I've bored myself.

dopplah

[edboy7]

Firstly, thanks for the help! Breathe easily-- I am running 23.98 timecode now, per comments above. However, I still have some questions I'd love to clear up.

>

Arrggh! Perhaps I wasn't clear above. I was running 29.97 timecode becauseI had received multiple drafts of the same episode. OMF 29.97 DF TC, 1st video draft digibeta (29.97 DF TC), 2nd video draft QT 23.98 frame rate.

And now I've bored myself.

dopplah

I think you'll be having a synching prob here if you started working on the first two drafts. Its a rendering error on the video part. You may ask for new dub out with the correct framerates. HTH

[minister]

hi,

i am not trying to be snippy or difficult, but here is why you are so confusing :

Nope, I'm on an HD2, so 23.976 TC is available to me. I did the previous season at 29.97 DF TC, and we've vacillated back and forth between file-based and tape-based (digibeta), so I left the TC at the specs from last year.

season.

The main reason this has been so bewildering is that we have a client whose specs on ADR sessions have the video frame rate at 23.98 and the timecode at 29.97 NDF. When asked why, we got "it works fine that way."

ADR session.

> why are you trying to run a different frame rate? because of the previous season?

Arrggh! Perhaps I wasn't clear above. I was running 29.97 timecode because I had received multiple drafts of the same episode. OMF 29.97 DF TC, 1st video draft digibeta (29.97 DF TC), 2nd video draft QT 23.98 frame rate.

episode.

there are also times when you say DF and other times when you say ND. there is good reason to be really really precise about this. if you feed DF to a NDF VTR tape, you will have issues.

i THINK what you are saying is that the first 2 EPSISODES were done at 29.97 DF and NOW, episode 3 is a 23.98 QT. right? i would think that you should run the new stuff at 23.976.

talk to your editor, director, post super. straighten it out.

sending the wrong kind of FRAM RATE to a VTR because the AUDIO SPEED is the same is not a good idea.

here are a couple of books you might want to read :
SYNC SOUND
TIMECODE
PRO TOOLS FOR FILM, VIDEO, & MULTIMEDIA

[Stizz]

What we've got here is a failure to communicate.

season = he was referring to all of last years episodes of this program, which were all delivered on digibeta 29.97 DF
ADR session = a completely different job that was used as an example.
episode = the specific program that is currently being worked on.

i THINK what you are saying is that the first 2 EPSISODES were done at 29.97 DF and NOW, episode 3 is a 23.98 QT. right?

It seems he was saying that the first draft of the episode was delivered as a 29.97 DF OMF file.
The second draft of the same episode was delivered on digibeta at 29.97 DF.
The third and current draft of the same episode was delivered as a QuickTime file at 23.98

zplane said:

Frame rate must be that of the video.
Timecode setting determines what the rulers diplay (grid).

Both set to same value gives snapping to frame boundaries.

That seems to answer the question - if you match the time code to your frame rate, then the numbers displayed will match either the old digibeta, or the relative time that you have imported the quicktime to. Either way, I believe your audio should be in sync and fine, which actually never seems to have been a problem. right?

OK - now back to work everyone.