CAPTURING HDV AS PRORES...VIA FIREWIRE

Before I go into this, if you haven't read Chris Poisson's article at the Creative Cow on how to capture HDV as ProRes 422 via firewire please do so now.

I'll wait.

...

Alright, let's talk about what I am doing now.

I have been hired to edit a 5-10 min "Teaser" for a documentary...a teaser that will be used as a fund raising tool to solicit more money to finish shooting and editing this documentary. This documentary was shot on HDV at 1080i 29.97 using the Sony VU1 HDV camera...with another one as b-camera, and at one point a small DV camera for minor pickup shots. When I mix the footage, I might treat the DV to look really grainy or something else to set it apart. That I captured natively with my DSR-11 deck. But the HDV footage I have set about capturing as ProRes via firewire. And thus far (on the second to last tape...it is finishing the encode as I type) it has been pretty smooth.

I rented a Sony HVR-1500 deck that is FLUSH with connections. Yes, I could have captured via HD SDI or HD Component...but because I am running an older Dual 2.0Ghz G5 (PPC), I can't capture it as ProRes via my Kona LH. You can only capture as ProRes with a capture card if you are running an Intel Mac. And I don't want to capture as DVCPRO HD...the old way of dealing with HDV...because I'd lose some resolution. Sony HDV is 1440x1080 (anamorphic)...and DVCPRO HD at 1080 is 1280x1080...I'd be losing 200 lines of resolution! Well, that's just not acceptable, not with ProRes out there. And ever since the FCP 6.0.2 update, you can capture HDV as ProRes via firewire even if you are running and older PPC Mac, like I am. How cool is that? Pretty cool in my book.

Now...my first question was...why ProRes and not the higher quality ProRes HQ? Well, when I captured a couple short clips and compared...I couldn't see any difference. Yes, I used my HD CRT to judge them. I'm guessing that this is because the HDV format is already highly compressed...and that the HQ ProRes is for higher end HD formats like HDCAM and HDCAM SR...where you can tell the difference. And because ProRes was 15.1MB/s and ProRes HQ was 22.3MB/s...I opted for the lower bit rate one...since there was no visible difference. And the Caldigit S2VR Duo that I am capturing this footage to is handling it all beautifully. (FYI, I wil be backing up all of this footage onto my homemade RAID tower, that has been designated as footage backup.)

So as the article describes, when I start capturing, the actual capture window does lag behind by 33%. And it plays back in slow motion...this is I wager is because it is transcoding HDV into ProRes. So to monitor the footage, I connected the deck to the HD CRT via the SUPER out, so I could see timecode. When the tape ends, I press stop, and then the system takes about 30-45 min to finish the encode. This would be shorter on a faster Mac, I am sure.

And as advertised it breaks up the footage at the start and stop points on the camera. When the tape is full of interviews, that is fine. There are about 1-4 clips to deal with. But when we are talking about b-roll and scenings...suddenly I have 65 clips to deal with. But, this is no different than with P2...footage is broken up at the camera start and stops. While I might be used to this, it doesn't mean that I like it. I don't...I really really don't. I like my b-roll of the desert and the desert sunset to be in 10-20 min chunks, not 5 sec to 1.5 min bits and pieces strew about. This makes scrubbing thru footage a BIG hassle. I'll probably end up linking them all together either as a sequence, or more likely as a self contained QT file. Although that is dangerous, as the new QT file won't contain the original tape timecode. Gah..what a pain!

So I do what the article states, delete the CLIPS (not the media, just highlight the clips and press delete) from the Browser and then on the finder level in the Capture Scratch folder, open and rename the footage more descriptively. Then re-import that into FCP and organize it.

NOTE: There are a couple issues with this workflow that I'd like to point out. When you capture this footage, FCP does not assign it a reel number. This is a pretty important piece of info to have on the clip. Fixing that is simple enough, just add it in the Browser. You'll be warned that you are "Changing the source timecode on the file," that's fine...just click OK.

Hmmm...this brings up a concern. When you do this capture, you do it pretty much as a CAPTURE NOW. Roll the tape and let it go. There is no LOG AND CAPTURE, no place to add REEL numbers. So let's say that you lose a drive, and your footage is lost. How will you get it back? With logging and capturing, simply BATCH CAPTURE your footage and it will reconnect in the Browser and timeline. But with this method, CAN you batch capture? Because of the camera starts and stops will the recapture start on the exact same first frame and last frame? If you have to recapture the footage and try to reconnect it that way, how can you assure that you get the same TC start and end times...and the same clip names?

The more I think about it...the more this workflow makes me nervous. This is why I am backing up my footage.

I think if I have the time, I will also capture the footage (only 8 tapes) via HD SDI as DVCPRO HD 1080i 29.97 and see how things look. At least with this format, I can log and capture, label my clips, assign reel numbers as I capture, have the ability to capture the b-roll as one long clip. And piece of mind that I can re-capture via "batch capture" in case footage is lost.

Sometimes I think slight loss in quality might be preferable when it comes to a proven stable workflow. We'll see...still figuring this out. What are your thoughts about this?