Can I control this?

[Jeremy Garchow]

Sounds like frame rate to me. What frame rate are the tapeless files? (My guess is 24p) and your captured files are 59.94. 60/24=2.5 | 35*2.5= 87.5 That’s right around where you are right now.

Jeremy

[Ron Craig]

Hi Jeremy,

Your analysis is close. The frame rate is probably the source of this. I shoulda thought of that. The tapeless files are 29.97. By your equation my HDV files should be just 2 times larger than the tapeless. So I guess there is another factor at work, as well.

I’ve never understood why the Kona 3 doesn’t offer an option to import 720p footage at 29.97. What’s the deal with that? Seems strange to me.

[Jeremy Garchow]

[Ron Craig] “By your equation my HDV files should be just 2 times larger than the tapeless. So I guess there is another factor at work, as well. “

How may channels of audio are you capturing? The Kona defaults to 16.

[Ron Craig] “I’ve never understood why the Kona 3 doesn’t offer an option to import 720p footage at 29.97.”

You can for certain tape formats, but there’s requirements. The SMPTE spec for 720p footage is 59.94 (we’ll call it 60). So whenever you are watching footage on a monitor, you are actually watching 60p video. 720pN24 or 30 (or any off-speed frame rate) format only exists as data which is why tapeless cameras can hand this data off. When played back through an NLE, pulldown is added to form a 60p stream. This will be a very simple explanation to a more complex process, but on certain 720p tape formats, there is a separate data stream that flags frames as ‘on’ or ‘off’, or 1 or 0, or live or dead, yin or yang, you get the idea. If you capture a 60p stream, you will capture all of the frames, no matter if they are ‘on’ or ‘off’. If you capture with a VFR setting, the Kona will capture only the frames that have been flagged ‘on’. The trick is, this data stream has to exist on the tape (it’s called rp188). For most 1080i cameras, there’s no rp188 data stream, so the Kona has to capture @ 60Hz and 720p60 is the way to do this as it will only capture the base-band video without the rp188 stream to drive the capture process.

So for now, you can edit in a 720p59.94 timeline. Your captures will be 720p59.94, and your tapeless material will have 2:2 pulldown added to it to get it up to 60p. The motion characteristics will vary a little as you will have 30p and 60p video in the same timeline, but you can always conform one to the other when the edit is complete.

Hope that all makes sense.

Jeremy

[Ron Craig]

Well, it took me a few reads but I think I got it. Here’s one remaining question that I couldn’t figure out from your detailed response:

When my cameraman is shooting his Panasonic HDX 900 camera and recording on Firestore, the readout on the Firestore screen shows the format as 60p. But when I bring that material in to FCP, it shows up in the browser as 29.97. I understand from your explanation HOW that can happen, due to the rp188 frame flagging, interpreted by FCP. But I don’t understand WHY it happens. Since the video is actually recorded at 60p I would expect it to import at that frame rate (or 59.94). I’m doing nothing that I know of to specify that I want a conversion to 29.97 but that’s what is showing in the browser. Can you tell me why? Actually, that frame rate is fine with me but I’d like to understand why it’s happening.

[Jeremy Garchow]

[Ron Craig] “When my cameraman is shooting his Panasonic HDX 900 camera and recording on Firestore, the readout on the Firestore screen shows the format as 60p.”

Not sure as I have never used a firestore before, but perhaps the firestore is removing the redundant frames when it records the file, but since 60p is coming out of the firewire, it reports 60p.

Jeremy

[Ron Craig]

Thanks for taking the time, Jeremy. At least it’s all working!

Now I’ll go research the difference between 60 and 59.94.

Have a good day.

— Ron

[Jeremy Garchow]

[Ron Craig] “Now I’ll go research the difference between 60 and 59.94. “

Don’t worry about it too much. When something says 60, it usually means 59.94, which is simialr to 29.97 vs 30. When something is truly an even frame rate, you will usually see 60.0 or 30.0, unless of course your edit in 50Hz, in which case they have for real even frame rates 25=25.0. Lucky ducks. It has to do with the invention of color tv, not kidding.

Jeremy

[Ron Craig]

It has to do with the invention of color tv, not kidding.

Yeah, I figured it must be essentially the same as 30 vs 29.97 (Caused, as I recall, by the slightly longer time it took to scan a frame or field in color vs B&W, or something like that.)

I’ll just continue treating 60 and 59.94 as the same thing. I guess that’s safe.

Thanks again.

[Jeremy Garchow]

29.97*2=59.94

[Doug Beal]

Back in the day…there was more data in the color stream and FCC would not allow the required 4% increase required in bandwidth to maintain frame rate so the frame rate was slowed down and the data fit in the allowed bandwidth.
Of course now we have DTV, it’s all better, hard of hearing have caption trouble, stations randomly dropout with OTA antennas, and stations now have 4 times the bandwidth they once had to sell all that much more advertising to pay for the transition. Haven’t you noticed how many more spots you’re cutting? and we still have our legacy frame rate

Doug Beal
Editor / Engineer
Rock Creative Images
Nashville TN