Forum Replies Created

  • Erik Talbert

    December 1, 2009 at 1:00 am in reply to: Multiclip “OPEN”

    Thanks James, I had the same problem and tried your solution (turning off the video track) and that corrected the problem. Indeed, it seems to be the auto render that changed this in the first place. I was about two minutes into troubleshooting this (and beginning to get frustrated) when I decided to turn to the Cow. Just want to let everyone know this thread has helped more than one person. Much props!

  • Erik Talbert

    July 1, 2009 at 5:12 am in reply to: FCP is attempting 1:26 pre-roll to capture

    I got on the forum to find an explanation for what I believe is a similar problem. I shot HDV 1080i with my Canon XH-A1. I’m capturing with the HDV codec, NOT an intermediary like ProRes (although I may change my mind on that). During a batch capture of previously logged clips, I get the “error locating TC” warning with the option to continue or stop. I too thought this might have to do with preroll not being enough to get to “speed” (although I did not note the specific time of the preroll). I simply chose “continue” when I got the warning and I managed to get all my clips captured. HOWEVER, I often had to click “continue” several times for a single clip. Usually by the third attempt, it would work. I wasn’t changing anything else.
    I’m suspecting this has to do with the device control and/or the long GOP structure of HDV. I’m using my camera as the playback device, so I imagine the motors and parts that read the tape are not as precise as a dedicated deck (maybe some sales guy told me that when explaining why decks were so expensive). Anyway, I found persistence paid off in my case. Still, I’d like to find a better solution because mine means I have to sit and monitor the batch capture, which sort of negates its advantages.

  • Erik Talbert

    December 4, 2008 at 7:48 pm in reply to: Batch Capture Errors

    RE: capture now
    Check your scratch folder to see if there is a second source file with the rest of your footage. I’ve seen FCP presumably go through a whole capture and no master clip is created in the bin. Generally this happens after and error and/or abort. Although no master clip was created in the Browser, the source media was indeed created in the capture scratch folder. Then, it’s just a matter of importing the file. This may not be what happened in your case… and even if it is, it still doesn’t explain why FCP is breaking up “capture now” clips (in your case) or “batch capture” clips (in my case; see above).

  • Erik Talbert

    December 3, 2008 at 10:59 pm in reply to: Batch Capture Errors

    I just had a similar problem batch capturing logged (but not previously captured) clips using my Canon XH-A1. I too am using an external firewire drive as my scratch disk. In my case, the “cannot locate timecode” warning came up during the batch capture. I had the option to continue or abort… I clicked continue.
    When it was all said and done, about half of my clips captured as expected. The other half captured, but were broken up into two (only two clips). So now my bin has several clips with “clipname-1”). It does appear these breaks occurred on a start/stop… but the timecode is consistent. I end up missing 2-5 frames between the “clipname” and “clipname-1”, but in my case I will work with that.
    I’m guessing it has something to do with the throughput on the FW bus. I’ve read some stuff about this. In my case, I’ve got my scratch drive attached w/ FW400 to the front port on the MacPro, a second hard drive on the rear FW800 port, and my camera (acting as a deck) on the rear FW400 port.
    Once while using an AJA capture card I had a similar problem. The AJA rep rightfully advised to capture to a non-firewire drive because the capture card needed all the “throughput” on the port to do its thing. I’m wondering if two externals plus deck control is similarly bogging down the business…
    I’m capturing using the standard HDV codec (not an intermediary). OS 10.5.3, 2 GB RAM, 2X 3 GHz Quad_Core Intel Xeon processors, FCP 6.0.3.

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy