[Joseph Owens]

I might not be directly helpful in addressing your issue with SRW-1… in fact I own/operate an SRW-5500 through a Kona3 card and it works great. Some strange little behaviours on a semi-occasional basis but nothing that a quick re-set or simply re-booting the Edit-to-Tape window doesn’t fix.

JPO

[Joseph Owens]

Yes, setting the “SYSTEM” on an HDCamSR deck is a bit of a chore. It is in the “Installation” manual, not the operator manual. Pages 1-20,21. It involves the [SHIFT][Diag] then [SHIFT] [F8] (Maintenance Exec) then [F9] Others check… then [F9} again is when you finally get to the System Menu. And then you get 4:2:2 or 4:4:4 (with the Dual-Link card), 1080×1920 or 720×1280. F2 (System scan) sets interlace, progressive or PsF. and F3 for System Frame 23.98 thru 59.94, F5 for HDCamSR vs HDCam, frame conversions (with the HKSR-5001 option), active lines (only in 4:2:2 1080×1920 Interlace 29.97 or 30.

Easy.

Previous HDCam decks required the use of a paperclip inserted in a hole in the control panel to get into the maintenace menus.

JPO

[Joseph Owens]

I had a bigg-ish (more than ten pounds) project entirely originated on HDV. Ingested tape-at-at-time in native Sony 1080i60 via FireWire, breaking the material into clips at the stop-starts. I re-connected the material to the off-line sequence (this was a conform), media-managed to UNCOMPRESSED in a new project, colour corrected under FinalTouch, and there it was. It did take some tweeking to match the images with the off-line as I did experience some timecode wobble, up to plus/minus 4 frames in some cases. I was also suspicious of the audio sync coming down the FireWire (!), but eventually all issues resolved.

This kind of worked for me, but its probably not for everybody. Going the uncompressed route was mainly done to avoid a succession of codec translations, and eventually the whole works needed to be exported as a dpx sequence anyway. Which I’m doing as I write this…

JPO

[Joseph Owens]

All good questions…
I can’t be authoritative, but here’s what I have observed. Many of these 24p formats are handled differently in capture situations and are brought in as i60 or other with pulldown — beware that there are different cadence sequences — some are traditional 2:3:2:3, and there are variations including the very clever 2:3:3:2 Advanced Pulldown. You should edit on a 24 frame timeline, though to avoid cadence incoherence.

If you actually shot at 1080i then I strongly doubt that a progressive codec will help you. I also have my doubts about exactly how “interlaced” HDV is, considering the Long-GOP MPG structure…

You may not experience any quality differences between the HDV and HDV Apple Intermediate — there is also a SONY HDV codec just to add to the confusion.
Use the one that works. Whats worse? Out of sync capture is bad enough… I have to wonder if HDV is entirely sync-stable as a format, though.

Capture and edit at low resolution? How low is low? HDV is already nearly the same as standard def DV as far as bitrate is concerned. What you do need is the processor power to crank it back up to 1080. Maybe the thing to do is to take the clips off-line, down-rez to 720×480 anamorphic and go from there…. anybody else? proxies?

JPO

[Joseph Owens]

Actually this is really easy as an old colourist’s trick. Export your clip to Final Touch…

Okay, if you’ve got this far…. Go to secondaries, create a vignette around the little girl. “Colour pick” her coat. Refine the qualification, knock the colour out of the rest of the scene, fix the red if you have too…. done. 😉
Render. Export.
$300 please.

JPO

[Joseph Owens]

We are actually sort of on the same page. I’m just under the impression that the white data lines at the top of the screen are being blanket termed “User Bits” when that’s the wrong nomenclature.
We agree that VITC and LTC can serve as different transport mechanisms for the same data, with some differences due to reading technicalities.
The LTC/VITC time code word is subdivided into different areas. One area carries time code, TOD, PRESET, REGEN’ed whatever you want it to do, as you say.
Another intervleaved area carries a fixed set of data, and there are also interspersed flags set to identify DF/NDF code and other things about the video.
User bits can be embedded in both Longitudinal Code as well as VITC, but LTC can never be used to identify fields, since motion is required to read it. Also for this reason, sometimes it is unreliable to read VITC in PLAY_REVERSE.
Within the 80-bit word in either VITC or LTC, the “frames (units)” are carried as bits 1-4, first UB is bit 5-8, “frames (tens)” are 9,10 (because it never has to count past 2), then there’s the drop frame flag, the colour frame flag (You’re really old if you know what that’s for), then the second UB group, etc.
The whole listing follows:

Chapter 2) SMPTE Time Code 80-Bit Longitudinal Bit Assignments

BIT) description

1 BCD Frames Units
2 BCD Frames Units
4 BCD Frames Units
8 BCD Frames Units
Bit 0 of 1st Binary Group (User Bits)
Bit 1 of 1st Binary Group (User Bits)
Bit 2 of 1st Binary Group (User Bits)
Bit 3 of 1st Binary Group (User Bits)
10 BCD Frames Tens
20 BCD Frames Tens
Drop Frame Flag Bit
Color Frame Flag Bit
Bit 0 of 2nd Binary Group (User Bits)
Bit 1 of 2nd Binary Group (User Bits)
Bit 2 of 2nd Binary Group (User Bits)
Bit 3 of 2nd Binary Group (User Bits)
1 BCD Seconds Units
2 BCD Seconds Units
4 BCD Seconds Units
8 BCD Seconds Units
Bit 0 of 3rd Binary Group (User Bits)
Bit 1 of 3rd Binary Group (User Bits)
Bit 2 of 3rd Binary Group (User Bits)
Bit 3 of 3rd Binary Group (User Bits)
10 BCD Seconds Tens
20 BCD Seconds Tens
40 BCD Seconds Tens
Bi-Phase Mark Phase Correction Bit (0)
Bit 0 of 4th Binary Group (User Bits)
Bit 1 of 4th Binary Group (User Bits)
Bit 2 of 4th Binary Group (User Bits)
Bit 3 of 4th Binary Group (User Bits)
1 BCD Minutes Units
2 BCD Minutes Units
4 BCD Minutes Units
8 BCD Minutes Units
Bit 0 of 5th Binary Group (User Bits)
Bit 1 of 5th Binary Group (User Bits)
Bit 2 of 5th Binary Group (User Bits)
Bit 3 of 5th Binary Group (User Bits)
10 BCD Minutes Tens
20 BCD Minutes Tens
40 BCD Minutes Tens
Binary Group Flag Bit (0)
Bit 0 of 6th Binary Group (User Bits)
Bit 1 of 6th Binary Group (User Bits)
Bit 2 of 6th Binary Group (User Bits)
Bit 3 of 6th Binary Group (User Bits)
1 BCD Hours Units
2 BCD Hours Units
4 BCD Hours Units
8 BCD Hours Units
Bit 0 of 7th Binary Group (User Bits)
Bit 1 of 7th Binary Group (User Bits)
Bit 2 of 7th Binary Group (User Bits)
Bit 3 of 7th Binary Group (User Bits)
10 BCD Hours Tens
20 BCD Hours Tens
Unassigned Address Bit 58 (0)
Binary Group Flag Bit (0)
Bit 0 of 8th Binary Group (User Bits)
Bit 1 of 8th Binary Group (User Bits)
Bit 2 of 8th Binary Group (User Bits)
Bit 3 of 8th Binary Group (User Bits)
Bit 0 – Binary Sync Word (0)
Bit 1 – Binary Sync Word (0)
Bit 2 – Binary Sync Word (1)
Bit 3 – Binary Sync Word (1)
Bit 4 – Binary Sync Word (1)
Bit 5 – Binary Sync Word (1)
Bit 6 – Binary Sync Word (1)
Bit 7 – Binary Sync Word (1)
Bit 8 – Binary Sync Word (1)
Bit 9 – Binary Sync Word (1)
Bit 10 – Binary Sync Word (1)
Bit 11 – Binary Sync Word (1)
Bit 12 – Binary Sync Word (1)
Bit 13 – Binary Sync Word (1)
Bit 14 – Binary Sync Word (0)
Bit 15 – Binary Sync Word (1)

Per 80-Bit Frame, there are 32 User Binary Spare Bits, 16 Sync Bits, 31 Assigned Bits, 1 Unassigned Bit.

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.

JPO

[Joseph Owens]

This may be beating a dead horse, but if anybody’s interested:
https://en.wikipedia.org/wiki/SMPTE_time_code

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.
User bits are part of the 80 bit word that comprises the time code package. 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.

Iterate means: the numbers change, progressing. User Bits don’t do this. They are locked to whatever you enter them as. True, the time marches on in HRS:MINS:SECS:FRMS in both Longitudinal and Vertical Interval time codes. But USER BITS are NOT time code. It is true that you can preset the VITC and LTC to be different. Ordinarily this is a bad thing and is grounds for rejection of a broadcast master. But I have seen people do it as a rough visual conform device: Edit tape LTC shows record time, and (shutting off internal VITC and passing through source VITC on unblanked vertical interval) inserted VITC is Source, so that a burn will yield a (manual) cut list guide that you could write down. We may have to go back to this with wobbly formats like HDV.

And on the subject of DV. Standard Def is 720×486 — ie Digi-Beta — and DV is 720×480. It does NOT support VITC, because the active Vertical Interval lines do not exist. Ask anybody who has requested a master telecine transfer tape with embedded Evertz/Aaton codes. No is the answer.

JPO

[Joseph Owens]

Or complain bitterly to the transfer house and get a decent telecine.

JPO

[Joseph Owens]

Have you tried importing it into Quicktime and done a QT conversion out from there?…
and if that doesn’t work, hmmm… what else will open AVI? Shake? AE? Premiere? RealPlayer…?

JPO

[Joseph Owens]

Aha.

So you were in effect trying to “jam-sync” the two cameras…

User Bits do not iterate. They are a hexidecimal code designed to represent dates, machine numbers, that kind of thing. Multiple streams of meta data (such as telecine transfers which include source time code, audio code and keycode / film edge numbers) require outboard generators/inserters. Or my understanding of User Bits / Time code is flawed. I think this is why you only see the one stream of (wild?) timecode. Never fear.

If you can find a common frame between the two cameras, and the start/stops are not too numerous, you should be able to gang-sync (MAKE A MULTICLIP) between the two sources in FCP. It would, of course, have been better and easier if the the two cameras had been jammed to the same (external) time code master source generator.
But I’m thinking that you’ve got two wild sources with the same User Bits and different time code as an end result.

Please tell me I have the wrong perception…. it would be a lot less work for you! 🙂

JPO