Timecode breaks where there are none? Problems with FCP or Cameras or Decks?

[Rendertainmentllc]

We have 4 different FCP suties where I work, and each bay is different. One gets a lot of timecode breaks when it captures, 2 get them occasionally, and (luckily) my bay rarely gets them. Once in a while it does happen in my bay though. There will be no timecode break on the master, but FCP will “detect” one, stop, say “Locating timecode break” and search backwards. Then after a couple minutes it will start capturing again, but with a 5 second gap between where it “found” the first timecode break and the new clip. Very annonying, because if you go back and capture that 5 second gap later (with handles to hard cuts on both sides) there’s no timecode break detected.

Sometimes it is a problem with the tape though. The other day I was capturing an old movie from the early 90’s to format and edit for TV and FCP kept detecting many, many timecode breaks. The movie (which we had received from the company that sends us a lot of these type of movies) was on a new digibeta tape. I looked at the timecode as it played in the digi deck and didn’t see any inconsistencies. The breaks were so numerous though, I decided to restripe the tape with new timecode. Set it up, put new timecode on the tape, and it ended up capturing the whole movie without a single break in timecode. Go figure.

[Bob Flood]

Hi

I have some advice to help you all, but first i must rant:

Unreal

Here is a workflow that apple endorses “capture the whole tape and seperate the clips after the fact” and actually this makes a lot of sense, in the case of beta, dbeata and other real formats, you save wear and tear on the tape by not having to shuttle around to mark in and outs etc. in the case of firewire formats like dv, hdv, dvcam etc its faster cuz shuttling those formats takes forever.

so yeah, this is a great idea! except for one thing: IT DOESNT WORK!!!

I mean this isnt like “oh media manager ate my footage” or “oh the mark out isnt like the avid, where it does not include the outpoint” NOOOO this is: THE PROGRAM DOES NOT CAPTURE VIDEO CORRECTLY”

now you know why you only pay 1500 for an edit program
I guess its true: you get what you pay for

on a more constructive note: SMPTE timecode was never great. it was always prone to errors. even the slightest dropout or dropped bit can trip off sensitive TC readers. the better timecode readers have very robust error correction.

when ever we old timers had issues like this ie bad code, or what the editor percieves as bad code we usually did this:

1. make sure all your machines are getting house sync ie feed video black from a stable sync generator to the reference ins and video ins of the vtr’s and to the ref ins of the capture cards/devices. also make sure said capture cards, devices, and vtr’s are locking to that black or ref in, they call it genlock

2. restripe the videotape, or clone the videotape and nake sure you are regenerating timecode, not just copying, (the recording vtr should have provisions to regenerate code based on an external tc source) It would be nice if you could regenerate the timecode over the rs422 interface. An edit systme we once had used a video connector for timecode in. when we had flaky code on tapes, we would take a “jam sync” continuous updateing timecode generator, and put it inline between the vtr and the editor. this would take the timecode off the tape, regenerate it w the same numbers, and pass it to the edit system. (for those who care, it was a montage)

3. log and digitize seperate clips like days of yore

4. Complain to Apple. A Lot.

Hope this helps

[Anders Haavie]

Almost exact same setup. Xsan.. 12 clients.. capturing dv though firewire. Lately we are having the exactly the same problems !!! We have been using 2 hour tapes, but are switching to 1 hour tapes cause I thought that would be cause of the problems.. well.. hmm. Maybe this is an xsan 1.4 issue ?

Anders

[Glenn Chan]

I’m also seeing this, no XSAN. When FCP sees a phantom TC break, it will skip over several seconds but now the timecode will be slightly offset in comparison to the tape (about 2-3 frames).

DSR-1500, capturing over SDI into a Blackmagic card DV codec to an external firewire hard drive.

[David Eells]

You so old, I bet you used to edit on CMX!

[Glenn Chan]

Does anyone know if “mark long frames” will be useful in detecting actual timecode breaks? It doesn’t seem to detect phantom TC breaks… so perhaps it is useful for determining which is the case.

Otherwise, my workaround would be:
Set FCP to warn about timecode breaks instead of make new clips.
Manually capture a test clip from the end of the tape. You can plop this into a test timeline and line up the timecodes. Set the top clip to composite mode “subtract” and scrub through the footage to see if everything matches up. Verify audio sync too.

[Ben Wharton]

Glenn –

I still don’t think the warning about timecode breaks is something suitable for professional environments. Fine for one real break, but what if there are 3 real breaks? Or more? Not that unusual unfortunately. You’d get the end section correct with your method. Then you’d have to rewind back to some unspecified point or points to redigitse again and line up. Then again… Meanwhile you have 80 tapes to digitise all from 30-55 minutes in length with 4 editors and 3 producers and an exec breathing down your neck…

Looking at this ever growing list of people with the same issue – both on DV and 422 control with downconvert and no conversion, with Xsan and no Xsan involved, I think we can safely conclude that is:

A SERIOUS SERIOUS BUG IN FCP.

I admit to be very new to FCP but this is really unacceptable.

Forum leaders, what are the procedures for reporting bugs to Apple and actually getting them adressed (if not,then at least admitted to)? The offical Avid forums do a good job of hounding Avid about bugs after every version revision and often getting them fixed. It can be slow but it’s something.

Is there anything similar in the Apple community? I have yet to get acquainted with their forums.

Ben

[Glenn Chan]

Ben, I agree that this is a serious bug in FCP.

Until the bug gets fixed, one would have to figure out the best workaround unfortunately.

[Ben Wharton]

Glenn –

The only work around I can think of is pretty grim:

Dub the tape and digitising from the dubbed tape at the same time with “Uncontrollable Device”
and then typing in beginning and end media on the captured clip via the modify timecode dialogue.

Again, unacceptable.

SO, again, Community leaders, is there a correct way to report this bug? To know if it’s being dealt with?

Ben

[Connie Simmons]

Dear Ben – Did you ever find a solution to this? I have HDCAM tapes that i am trying to bring into FCP using a JH-3 deck and an AJA IOHD, an esata 5T raid, and AJA Gen 10 and MAcPro 3gig 8-core. I’m getting 2 minute clips with phantom timecode breaks, also losing 5 seconds of footage.

I used the altdisable txt file from AJA (put is HD, Library, Application Support, Final Cut Pro System, Plugins)but it didn’t help.

The thing is – it worked for a few hours, now doesn’t.

Wondered if you ever fixed problem.
Best, Connie