[Craig Anderson]

Hi,

I actually had to do this exact thing at my old job. We had an older infinit, so I’m not sure if it has improved at all. I believe the image files that the chyron uses are not your usual formats (tga, jpeg, tiff, etc…). It’s a proprietary thing. So I had 2 solutions:

1. I had the graphics department who actually created the graphics export me a targa – this would be the best solution as it will be far cleaner.

2. Before I got the raw files, I captured both the key and the fill channels of each key, and composited them together. The fill is basically what the super will look like, but over black. The key is a luminance version of the alpha channel. Lay the fill channel on top of the key channel in FCP, apply a luma travel matte, and export as an animation.

If the graphics have motion in them, I would recomend putting the two channels to two seperate VTR’s at the same time with slave time code so that you can line it all up without having to eyeball it.

Hope this helps!

Craig

[Craig Anderson]

Select the clip in the timeline, and apple + K will add an audio keyframe for you, wherever the playhead is. I’m not sure if that works in the viewer as well, but I would think it does.
This is mappable to any other key if you prefer something else.

Hope this helps!

Craig

[Craig Anderson]

Just throwing my two cents in. I once tried a similar procedure to what you’re describing with DVCProHD, with a Kona2 card. I found that with that codec, firewire wasn’t exactly frame accurate. If I captured the same clips twice, it would not be exactly the same 100% of the time. It was always within a few frames, but it was definately off.
Additionally, as we had the 1800A deck (with firewire and 422 control), i tried using 422 for deck control and firewire for input, and found that that was even farther off, presumably due to processing time in the firewire.

I would proceed with caution if you want to start mixing and matching firewire and 422.

Good luck!

Craig

[Craig Anderson]

Hi Luke,

Yes, I have tried both of these things, to no avail.
However, I did notice today that switching to the DV deck did not force it to drop off, so perhaps that is not the culprit after all (it still dropped, but not directly after capturing from DV).
Perhaps I need to start a log of exactly what I am doing whenever it drops off, though I haven’t noticed any pattern so far.

Any other thoughts?

Thanks very much,

Craig

[Craig Anderson]

Thanks for the response, Bob.

Unfortunately, you don’t actually see the hits while it is capturing, just when you play back from FCP (or even quicktime, for that matter).
As another possibility, do you think this could be a drive issue? We’re running a 4 drive raid through an ATTO SCSI card. The drives are Maxtor 10K SCSI drives, and it is running on two channels (2 ports on the card, each going to 2 drives).

Thanks again. Any thoughts are much appreciated.

Craig

[Craig Anderson]

It may sound obvious, but are you both on the same version of FCP? I once tried to open a file created in FCP 4.5 on a computer with only FCP 4.0, and got a similar error message to yours.

Craig

[Craig Anderson]

If you do not plan on going out to tape, I would strongly consider editing at 23.98 for a few reasons. Your disk space and render times will be shorter, as you have fewer frames to process, and you won’t be losing any information, as the extra frames are simply duplicates.
Secondly, if you are going to an SD DVD with it, you may find you get a better picture with 23.98 footage, since your bitrate can go up as your frame rate goes down. I believe that the DVD standard allows for 24 fps footage, and the set top player will pull that footage down itself for playback on 29.97 sets (correct me if I’m wrong here).

Craig

[Craig Anderson]

We have the kona2 card as well, and have discovered a few things.

We originally tried capturing through the HD-SDI off the 1200 through the kona, but found some pretty brutal pixellation on diagonal, high contrast lines. Capturing through firewire nixed this problem. My only beef with this workflow is that the deck control is so sloppy through firewire, as compared to 422. Has anyone else experienced this problem with the Kona? Aja’s response was that this was how it was supposed to look (a cop out, in my opinion).
On to another topic:
We normally capture to an XServe raid, but recently tried capturing to a LaCie Extreme Big Disk, and encountered all these phantom time code breaks you spoke of. I found that capturing to the raid and then transferring to the LaCie solved this problem (we were running both the deck input and drive through the onboard firewire bus). So a PCI firewire card is in our future to solve this so that we can capture straight to the LaCie drive.
I think the TC breaks are a function of not enough bandwidth on the firewire bus on the g5, as I haven’t experienced them at all going to the xserve.