So if you download the developer kit SDK 20 and install version 1.0 my hunch is that you'll get a better result. I haven't had any new footage to capture using the MBP yet, but there was NO WAY I was going to install Version 1.3 on the MBP because I've heard of glitches using versions of DVHSCap later than 1.0. I captured two weeks ago using OS 10.5.8, but I picked up a new MacBook Pro with Snow Leopard straight after that and one of the first things I did was install DVHSCap Version 1.0 on it. So William, my first advice to you would be to trash Version 1.3 and install Version 1.0 of DVHSCap and see if you get a better result with that. But it's always a good idea to stop DVHSCap from capturing before you get to the data break when you stopped recording at the end of each take. I captured a project this way two weeks ago and it went smoothly and perfectly (ClipWrap can also convert to ProRes. mov file with ClipWrap is pretty much a no-brainer these days. However, capturing HDV1 from the tape using DVHSCap Version 1.0 and then turning it into an HDV720p. Just drag the files into the Browser and edit away in FCP! Then you try again and it might capture the whole clip perfectly! That's why a lot of people turned to things like capturing with ProRes, using capture cards, etc.Īnd it's why Tim Dashwood kept "pestering" Mike Woodworth until Mike developed and released "ClipWrap" which finally solved the problem of getting HDV1 captured natively and working in a native timeline with FCP.Īnd I guess the FCP capturing problems are why, in the end, JVC abandoned HDV1 utterly (HDV1 is 720p footage captured to Mini DV tape) and why their latest models (HM100 and HM700) now capture to solid state media using XDCAM codec which is already wrapped in a. Then you try again and it might now capture that portion fine but perceive a data break later in the clip. There is no drop-out, but it perceives a data break anyway. FCP will perceive a "data break" when there isn't one and only capture part of a clip. Gee, this topic makes me all nostalgic for the "good old days" of trying to capture HDV1 using FCP.īelieve me, Pete. Are there any suggestions for an alternative m2t stream capture program? ![]() It also has errors if the time code breaks (one of the cameras was on "Free Run"). I haven't used this program since before 10.4 and while it's working, it crashes after finishing a capture of HDV. This most recent multi camera shoot didn't have multiple FireStores so everything went to tape. Transferring files from the FireStore either directly or thru ClipWrap Shooting on any tape plus the FireStore set to HDV m2t file streams (the FireStore has never messed up these files)Ĭapturing as HDV in FCP (clip breaks in the middle of takes are the worst problem)Ĭapturing as ProRes in FCP (fewer unwanted clip breaks but it still happens)Ĭapturing in DVHSCap and converting with ClipWrap (usually flawless but timecode breaks can befuddle ClipWrap) Shooting any tape plus the FireStore set to QuickTime HDV (the Firestore very rarely messes up the QuickTime wrapper resulting in a useless file) Shooting FireStore only (only did that once, it was nerve wracking) Shooting HDV tape only (I've had more more severe problems with HDV tape than DV) I have found over the years of using my JVC HD100 camera with a FireStore and FCP that I had problems in this order of lessening severity: ![]() So that particular tape was captured in two pieces. Perhaps something more drastic happened on the recording that I didn't see as well, but recapturing after the time code switch was flawless. The AJA made excellent ProRes files from the HDCam but as I said the time code switch made the capture unusable from that point on in the tape. ![]() I send the crash report to Apple each time but I have a feeling that it has something to do with Snow Leopard. Fortunately I was able to capture the remainder of the tape separately and assigned it as camera four so as I switched in multi-cam mode I could continue the switch without stopping.Īnyway I am just finishing up the capture of the concert today and while DVHSCap crashing at the end of every capture is annoying, the resulting files are fine. On one tape somebody switched the VTR's time code from non-drop to drop-frame during recording and this drove the AJA IO HD box I was using batty. I just edited a 2 1/2 hour three camera project from a conference that was shot iso in HDcamSR. It's concert with tunes lasting from 3 to 5 minutes long and it's a help that I get the entire tune from each camera in one piece so using multi-cam in FCP is as simple as possible. I'm not capturing multiple cameras at the same time (but that's a very interesting idea for the future), just each iso tape from the four cameras separately.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |