[Steve Braker]

Thet’s entirely between you and the people you’re delivering to. You need to ask them. No matter what we all say, it will be the wrong answer for one or more of your outlets.

[Steve Braker]

See my post above. That’s normal.

You’re viewing interlaced video on a device that doesn’t display interlace. It’s that simple. You are being shown two fields, witch represent two slices of time, at the same time.

Just because that’s normal doesn’t mean you’re in the clear, though. You won’t know whether you have interlace related problems unless you monitor it as intended – which in this world is still a CRT.

[Steve Braker]

If you want a blackburst signal for some reason, just load up and output Slug. Blackburtst is literally just a normal video signal with the entire image black.

But as mentioned above that’ won’t be any consolation to an “out of sync monitor”. And it doesn’t have any relevance to anything else in the world because you can’t output more than one signal from FCP.

[Steve Braker]

Doesn’t necessarily mean there’s anything wrong with the bars in FCP.

You don’t way how the image is getting to the vectorscope. Blackmagic, Aja, Matrox devices? Firewire through a deck or converter? Any of those devices could be shifting chroma, and some of them may have their own calibrations.

You don’t say what the vectorscope is calibrated to. If it’s the deck output from a certain sourcde of bars then it could be the deck or those bars. Etcetera.

Not saying there isn’t something wrong in FCP, but without info on the rest of the system nobody can tell.

[Steve Braker]

That’s certainly not normal.

Assuming you’re looking at it on an external CRT (from FCP or from tape or DVD), if you’re seeing jaggies with motion you probably are getting fields reversed. If this is the case you would also see unusual jaggies on diagonal lines when there’s little or no motion.

If you’re looking at FCP canvas or viewer or any kind of computer display, then that is normal for intyerlaced video to display that way. It’s ugly but that’s the way it is. You can get rid of it in those distribution channels be deinterlacing (losing some vertical resolution in the process).

[Steve Braker]

If they were clipped in digital recording there’s really nothing you can do.

If it was distorted on analog tape you may be able tp reduce the effect with careful EQ slotting out the frequencies that make the room wobble. But you can’t bring it back, it’s still going to sound like it was… distorted.

If there’s only an ioccasional analog distortion you may also want to try dipping the level at those exact points.

[Steve Braker]

> So, forgive me for thinking that when you say you are setting the User Bits to Time of Day, what you actually doing is setting VITC to time of day, and probably not setting the UserBits at all… they can be a bit of a bear to find on most systems.

I do forgive you – one last time – but I said what I meant. User bits, in VITC, LTC, or both, recording the march of time. Incrementing, iterating, moving. User bits, distinct from the time code. Time of Day reco4rrded in user bits while tape time goes in the regular code. Perhaps I’m not clear enough.

Don’t knock it until you’ve tried it. Don’t say it isn’t done or possible until you’ve tried it. Don’t use it if you don’t need it. Believe it or don’t. I think my work is done here.

[Steve Braker]

> There is a big difference between “user bits” and Vertical Interval Time Code, which appears to be two terms that some people are freely interchanging

VITC and LTC are just two different ways of transporting the exact
same data. Which includes user bits, which can be used to record
time. It’s been done since the beginning of time… code. Very
common to put TOD in the user bits, as I said I used to do it all the
time. You can put GPS data in there if you’re so equipped.

> They are intended to convey information, not time. The information usually is a date, or a machine number, a reel number, or anything else that can be identified with the numerals 0-9 and the letters A-F. (It is hexadecimal, after all — and if you don’t understand that, I really am flogging an expired equine.

Well, this dead horse has used it many times. The letters aren’t used
for time, of course. We tell time with numbers.

> Iterate means: the numbers change, progressing. User Bits don’t do this. They are locked to whatever you enter them as.

Well yes, they do. If the generator has that capability, and the
operator in charge of it tells them to. My trusty old EECO
does-everything TCRG here even has a button for “Jam User Bits”. It
does exactly that – jam syncs to the incrementing time on the incoming
user bits.

Wondering why I’m writing this.

[Steve Braker]

Well, if you have an RS-422 or MIDI hookup that would be a way to get it out to _something_ and find out whether FCP trashed the user bits. Assuming the camera even recorded them. I just don’t even know if DV and HDV support user bits at all.

I don’t know this machine but there’s no way it has a TC out port. Is there any such thing as an HDV deck? As for how to set TOD code that’s a question for your manual.

Sorry, I’m not hopeful.

[Steve Braker]

You don’t say anything about your sequence settings or acquisition format. It sounds like a simple situation: your sequence settings don’t match the source material.

Find out what it is you’re shooting and set the FireStore and FCP sequence accordingly.