Major FCP Log and Capture Issues

[trudd]

I've successfully imported 2 out of 10 hours of my footage from Honduras.

On tape 3 I went through and logged everything. As soon as I started to batch capture, I got errors about timecode breaks. It looked my like drop frames to me.

This being my first time to Log and Capture through FCP, I feel I must be doing something wrong. The only problem I found in the timecode was when it jumped from xx:xx:03;29 to xx:xx:04;01, which (please correct me if I'm wrong - I probably am) is a drop-frame.

Rig:
2.4ghz MBP SR
4gb RAM
Canon GL2 (used to take footage and as deck)
Scratch disk: LaCie d2 320gb

As a side note, I've discovered that if I plug my LaCie d2 into my firewire 800 port and the camera into the FW400 port, one or the other won't be recognized (either camera won't be discovered or HD won't mount). To remedy this I've plugged the camera into hte FW400 on the HD and the HD into the MBPs FW800.

Long story short, GL2 ->FW400-> LaCie d2 ->FW800-> MBP

P.S. I also re-installed FCP this morning (taking it back to 6.0 instead of 6.0.1). Last night I started getting the Preview Disabled screen of death and my footage won't show up on the Log/Capture monitor.

Lethal, I'm looking to you on this one

 

[trudd]

d'oh. Turns out I was just overloading the FW800 port on the computer.

I figured FW800 could handle it. Guess not.

 

[LethalWolfe]

The daisy chaining would've been my first guess. It usually plays nice, but not always.

Just as a clarification there is a difference between "dropping/dropped frames" and "drop frame timecode." Dropping frames means something is keeping FCP from capturing all the frames of video off the tape. Drop frame time code doesn't drop any frames, it just skips a number at regular intervals so the TC stays in synch w/real time. "Drop number" TC would be a more accurate name than "drop frame".

From Wiki

Drop frame timecode dates to a compromise invented when color NTSC video was invented. Basically, the NTSC re-designers wanted to retain compatibility with existing monochrome TVs. Unfortunately, the 3.58 MHz (actually 315/88 MHz = 3.57954545 MHz) color subcarrier would absorb common-phase noise from the harmonics of the line scan frequency. Rather than adjust the audio or chroma subcarriers, they adjusted everything else, including the frame rate, which was set to 30/1.001 Hz.
This meant that an "hour of timecode" at a nominal frame rate of 30 frame/s was longer than an hour of wall-clock time by 3.59 seconds, leading to an error of almost a minute and a half over a day. This caused people to make unnecessary mistakes in the studio.
To correct this, drop frame SMPTE timecode drops frame numbers 0 and 1 of the first second of every minute, and includes them when the number of minutes is divisible by ten. This almost perfectly compensates for the difference in rate, leaving a residual timing error of roughly 86.4 milliseconds per day, an error of only 1.0 ppm. Note: only timecode frame numbers are dropped. Video frames continue in sequence. i.e. - Drop frame TC drops two frames every minute, except every tenth minute.
Drop-frame timecode is used only in systems running at a frame rate of 30/1.001 Hz.

Lethal

 

[Peel]

Rather than adjust the audio or chroma subcarriers, they adjusted everything else, including the frame rate....

PAL was also obviously around before color broadcasts, so I guess that the PAL engineers did it the other way round, and adjusted the audio and chroma subcarriers, since PAL still enjoys an integer timecode?

 

[LethalWolfe]

PAL was also obviously around before color broadcasts, so I guess that the PAL engineers did it the other way round, and adjusted the audio and chroma subcarriers, since PAL still enjoys an integer timecode?

I'm not a format historian, but according to the almighty Wiki PAL wasn't rolled out until the late 60's which is well after color broadcasts started in the states so I don't think PAL had to shoehorn in a color signal like NTSC did.


Lethal