-
Timecode Not Accurate on Edit to Tape with HDCAM Tape
Time for the wisdom of the Interwebs!
We have a client that gave us DVCPRO HD tapes at 1080/60i. We digitized the tapes, did some formatting for broadcast, then output via HDSDI to HDCAM, and also downconverted to Digibeta.
Our procedure for output:
We blacked about a minute of tape, then did an Edit to Tape – Assemble Edit.The Digibeta outputs worked fine, but on the HDCAM tapes, our timecode is all over the place.
We output 17 tapes before we realized there was a problem, so we have a fairly large sample to pull from… There was no discernible pattern to the timecode mistakes. The first frame of video was consistently early, (happening before 1:00:00;00), but was not early by the same amount (anywhere from 2 to 6 frames early), and throughout the rest of the tape, the timecode was off, but not by the same amount, so we dont’ think it is an “offset” issue.
We have black holes in the program, so we were able to compare the timecode on first frame of black at several points throughout the program.
So, for example, on the FCP timeline, the first frame of black might be at 01:10:00;00, but the first frame of the same black on the TAPE might be on 01:09:29;15. On the NEXT black, the first frame would be off, but not by the same number of frames.At first I thought we might have screwed up a 24 vs 30, but we don’t think that is the case because the problem does not get progressively worse throughout the program.
We have an associate in LA who is having a similar problem with an HDCAM SR deck and Final Cut Pro and AJA Kona card.
Our “Easy Setup” for the HD output is: AJA Kona LH – 1080i 29.97 – DVCPRO HD
Sony HDCAM Deck (I don’t remember the model number, unfortunately!) was set (by the rental house) for 1080i 59.94
Our timeline is set to DVCPRO HD 1080/60i
Octocore Mac Pro, AJA Kona LH (5.1), Final Cut Pro 6.0.4
Any ideas?
—
Brent Altomare
Groovy Like a Movie -
7 Replies
-
This is probably an issue with RS422 Device Control settings. There are a bunch of options. Try a different one.
Sean
-
[Brent Altomare] “The Digibeta outputs worked fine, but on the HDCAM tapes, our timecode is all over the place. “
Then something is up with the HDCAM deck. If this was an FCP issue, the DigiBeta would be off too.
[Brent Altomare] “Sony HDCAM Deck (I don’t remember the model number, unfortunately!) was set (by the rental house) for 1080i 59.94 “
I believe that should have been 29.97 to match your timeline. 59.94 can be NDF or DF. Was the deck set in Non-Drop Frame?
Walter Biscardi, Jr.
Biscardi Creative Media
HD and SD Production for Broadcast and Independent Productions.STOP STARING AND START GRADING WITH APPLE COLOR Apple Color Training DVD available now!
Read my Blog!
-
My understanding, and my experience, is that sync methodology – i.e. 9 pin control vs simple timecode chase – introduces different latencies in HDCAM vs DBeta. Indeed, 9-pin setup is crucial. I’ve dealt with houses for layback that had no idea this was an issue. Took 2 different layback sessions for them to figure it out. How much of a difference is there? And is the difference identical on all HDCAM tapes?
Reid C
-
Deck was set in drop frame[walter biscardi] “Then something is up with the HDCAM deck. If this was an FCP issue, the DigiBeta would be off too.”
That was my thought as well, but since I had another (more experienced) editor who had an identical problem with his HDCAM SR deck, I was leaning towards a setting within FCP (although I suppose we could have both had similar settings wrong on our Sony decks!)
[walter biscardi] ”
I believe that should have been 29.97 to match your timeline. 59.94 can be NDF or DF. Was the deck set in Non-Drop Frame?”Deck was set for drop frame. The timeline is actually “DVCPRO HD 1080/60i” (which it the default for our easy setup, which is “AJA Kona LH – 1080i 29.97 – DVCPRO HD”)
—
Brent Altomare
Groovy Like a Movie -
[Reid Caulfield] “How much of a difference is there? And is the difference identical on all HDCAM tapes?”
Anywhere from a few frames to a few seconds. It does seem to get worse later in the tape (the average differential is worse at the end of the program than it is at the beginning).
Part of what has us scratching our heads is that the difference seems to slide all over the place. There is no pattern that we can discern.
—
Brent Altomare
Groovy Like a Movie -
If you still haven’t solved it, consider my earlier reply. Go into your Device Control Presets and try some different options. One option in the AJA Sony Preset is “Default Timecode” which is set to non-drop by default. Maybe change this to drop.
Sean
-
OK
I am going to jump in here, as I see 2 issues and they possibly explain your issue
1) you mention “holes” in your project, are they the blank areas for the commercial breaks?
If so, how is that space indicated in the FCP timeline – did you use a slug, is there any thing there or did you just leave the space blank with no media what so ever?Leaving the area in the breaks “empty” can cause rendering issues ( especially with compressed audio in the timeline) since the rendering engine does not see anything there it can( and often does) just jump over that area when running under the RTE engine – then when laying off the “empty” area still need to be output, but momentary pauses as the Seq goes from RTE > Nothing > RTE cause TC slippage when timelines are set for Dynamic playback.
2) in the Kona Control panel, in the timecode pane, in the lower part called output make sure you have the “Use QT Timecode” box checked and the “Burn-in” set to off.
Since QT can be a tad ah, um, ah, FLAKY for lack of a harsher word – I have been lead to believe this setting was included to force output via the card to adhere to SMPTE TC specs, something the FCP is woefully lacking on its own.
gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows
Inside look at the IoHD
Reply to this Discussion! Login or Sign Up