[Eric Johnson]

Curiosity mainly.

Under tight schedules it seems like big stills always end up being last minute fixes to get the show to render or to export. Even when care is taken to recreate moves in AE, Things get missed in the rush.

Also have an editor that insists on making his own images and doesn’t like hearing that FCP has limits.

So, like I said, mainly just curiosity. It’s generally not an issue until it is, you know what I mean.

[Eric Johnson]

You should try re-importing the files from the finder. Sometimes FCP does some strange things…

If you re-import it should be fine, if not, you may have to re dig. the files. Also, re-importing them shouldn’t cause you any trouble as long as you’ve been giving the tapes Reel #’s while capturing.

[Eric Johnson]

What codec are you using? It sounds like you are dropping frames (which should not be happening with Pro Res (Proxy) or photo jpeg), when your picture is freezing. But it also sounds like you have timecode breaks, not a whole lot you can about that. As far as I know at least.

[Eric Johnson]

Not totally sure about the Render times (though I think they would be), but drive space on SD Pro Res (HQ) is about half that of 8bit uncompressed SD.

[Eric Johnson]

For the capture, the deck and the Kona are setup normally. Nothing changes. Likewise for the device control settings in FCP. Your downconversion, will happen by changing your capture preset.

Here’s a good example, this is what we do on the show I’m working on right now:

Tape: HD CAM 1080Psf 23.98

Finishing Format: Pro Res (HQ) 1080PsF 23.98 to HD CAM 1080Psf 23.98

Offline:

Capture Preset: Custom Photo-Jpeg For HD through Kona (Read as whatever your codec of choice is)
Device Control: Sony VTR B 23.98 (A and B are pretty much interchangeable, as far as I know)

Online:
Capture Preset: AJA Kona3: 1080PsF 23.98 Pro Res (HQ)
Device Control: Sony VTR B 23.98

As far as Reference and any deck settings, they should remain the same for both captures to reduce any frame drifting.

Hope that helps clear things up.

[Eric Johnson]

You could also export whatever you’re trying to export from the sequence. Set IN and OUT points around what you need to export and when you bring it back in it will have the TC from where it was exported from in the timeline.

[Eric Johnson]

Most important: Keep it all at 24 if you can. Did you shoot 24 24 or 23.98 24? You can either use the offline RT (384×216 35% Photo jpeg @ 24 or 23.98) in FCS2, or use the Pro Res (Proxy) in FCS3.

If you are using the offline RT then you get about a GB/hr of footage @ 23.98, probably the same at 24.

I haven’t used the Pro Res (Proxy) but it’s a 1080 frame at about 2-4 MB/s, which is around 10 GB/hr on avg if you are comparing to DV which is 3.4 MB/s and almost exactly 10GB/hr.

Do you know what you will be finishing to at the end? There are other workflows, but I would avoid DV if you can, especially DV at 23.98(24) because it’s not a true SMPTE TC, so there is a huge potential of extra work during the finishing process. There is a lot of 1-3 frame slipping during the online of 23.98DV to 1080Psf23.98.

The Photo Jpeg you could probably edit on a FW400, it’s crazy small, so FW800 is great. Pro Res (Proxy), based on data rate could also be done on a FW400 so if you are looking at going with FW800 drives, both would be great on one of those. And if you are looking at a 2 drive RAID enclosure then you will not be wanting for speed or space in either situation.

[Eric Johnson]

The Pillar boxing is most likely because your Pixel Aspect Ratio’s (PAR) are different. The PSD is most likely Square pixel and the timeline is DV (which is lightly anamorphic).

In sequence settings (apple-0) note your PAR and apply it to your PSD.

Or,

Bring your PSD into the viewer and adjust the aspect ration in Distort in Basic Motion. Square to DV is usually something like -12.5.

In the future when you start a PSD, set your PAR to match your sequence.

[Eric Johnson]

I am using the one in your link. I’ve actually been using that calculator for some time for other purposes for some time. And unless it does days:hours:minutes:seconds instead of HR:MIN:SEC:FR then yes it’s set to 44 minutes.

After I got the two machines to get similar results 44:47:08 is what we got also. Appreciate the confirmation.

[Eric Johnson]

Now I’m confused further. Using the timeline method, which I had tried but abandoned due to different machines getting different answers.

We got it sorted out and came up with 2s19f to be removed from the 23.98. Are you saying 3s14f per 60m actual? Or 3s14f per hour of programming, approx 45m actual?

And no, I meant 9 minutes. 44:50:00 23.98 NDF came out to 35:54;04 29.97 DF. LIke I said, if it does work then I’m doing it wrong, but don’t know what I’m doing wrong.

Thanks for the help.