Blackmagic & BM Timecode Accuracy (when will this issue be solved??)

[Alexander Falk]

you can do he same with a timecode identical dub to digibeta.

in my company we have a system called sd-x-way from dvs.
this is a “4 channel simultaneous lossless hard disk recorder to simulate a digibate deck”.

for hdcamsr edits i always use this one for checking timecode accuracy.
take the realtime sd-downconversion-signal from the deck to one channel including tc.
then check the timecode of the first edit.

if the developer of your product doesn’t give you the support you need, you need to create your own workarounds.

by the time you have to be fit to run to the machine room and back to check the result.

—–

4 x Avid Media COmposer Adrenaline 2.7
1 x Avid Media Composer 2.7
1 x Avid Symphony Nitris 1.6.3
1 x Avid DS Nitris 7.6

1 x Decklink HD Pro PCI-X 4:4:4
1 x Decklink HD Extreme
1 x Decklink SD Pro
2 x Decklink SD Extreme

1 x Workgroup Videohub
4 x HDLink

[Andrew Yoole]

Just chiming in with support here. I’ve had this problem for months and have posted my own threads and commented in others here, NEVER receiving a response from anyone at BM.

That the problem is within FCP, or temporarily unsolveable, or whatever, is no excuse for failing to publically recognize the issue within their support notes. Such a long-standing issue deserves clear disclosure.

Really, really disappointing support from a company I used to hold in high esteem. I’ve bought more than a dozen BM products since they started, but I’m forced to research and re-evaluate before my next purchases.

And in the meantime I have to allow double machine time for ETT functions, just in case the first pass is wrong.

[Keith Koby]

Your ETT latency will vary based on computer, storage and codec. cable length may affect latency, but I haven’t found that to be the case and we have computers ranging from 20 foot to 300 foot from the san/decks.

Working in DVCPRO HD, I’ve found that dual processor ppcs (on our xsan) work fine with the default 4 frame offset in the device control menu. However, the quad g5s need a 5 frame offset. We haven’t done any layback from our intel machines, but I wouldn’t doubt that they could also need some tinkering.

You can edit the device control preset for your codec by duplicating the setting, changing the latency setting and then create a new easy setup. This way you’ll always have the appropriate latency setting for your computer/storage/codec setup – EVEN IF YOU QUIT AND RESTART FCP! Just select your customized easy setup.

This is not a FCP or BMD bug!!! FCP and BMD have no way to figure out what your particular latency is going to be based on all the variables in your facility.

I agree, BMD should put up a knowledge base article on this because it takes a while to trouble shoot and figure out and in the meantime, they get blamed for it! And if you watch the first frame of your layback which comes in on time and notice that yes, my bars or my slate are accurate on the first frame of tape, but everything else is 1 frame late, it is difficult to figure out what is causing that.

As a poster mentioned above, as FCP prepares to lay back, it puts up the first frame of video while the deck is cueing. If your ETT latency is not set properly, you’ll get the computer and deck out of agreement on what is the first frame. The deck will record the static frame output from FCP on frame 1, then frame 2 will be actual video output. If you lay back bars and tone, check this on the tape by seeing that the video is on time, but the audio starts a frame later…

So, duplicate the device control preset, change the ETT latency setting (from 4 to 5 frames in your case), and save the new setup as a custom easy setup.

[Sam Goetz]

Keith,

Thanks for the input, you described the issue and it’s reasons PERFECTLY.

And indeed, you need to create a WHOLE NEW device control preset to stop FCP from resetting your latency. I’ve been using the default NTSC preset, which FCP resets everytime you reboot FCP.

I still wonder whether this issue is completely out of BM’s / FCP’s control. For one, can anyone confirm whether Kona users are having this problem? Also, the fact that the drivers changed the behavior of the latency (with older drivers the problem was random, with newer drivers the problem is consistent) seems suspicious.

And, finally, can anyone confirm whether this issue persists with FCP 6.0?

Thanks Creative Cow users for all the chiming in and back and forth! Please BM, do you have anything to add to this?

[Keith Koby]

Borjis,

Would that offset happen to be 3 seconds and 18 frames? We have seen this when not using ref to both cpu and deck and laying back to df tc tape. 3 seconds and 18 frames happens to be the difference between drop and non-drop in an hour.

I’ve seen this on DVW-2000s, DVWM-2000s, HDW-2000s, and AJ-HD1700s, but mostly it occurs on the DVW-A500.

In FCP you can check for this by hitting “go to in” before starting your layback. If it goes to the wrong time code, it will lay back to the wrong place. Then you need to re-enter your tc in the ETT window. Usually after re-entering tc, it goes to the right place and your layback will be correct.

kk

[Keith Koby]

We’ll test with AJA some point in the future. We won’t have 6 in for a few more weeks, but I’ll provide feedback on that when we do.

The problem has been persistent for us across various driver revs. I think it has more to do with hardware and codec complexity (decode when referring to ETT), as long as storage is the same across all platforms. I thought it strange that the quad, much faster than the dual G5, had 1 more frame of latency. However, it is completely different hardware and pci-e versus pci-x…

[Sean Oneil]

I don’t believe I’ve ever had this problem.

But what I have had to deal with is that since we started using a RS-232 patchbay, I have to change the playback offset from the default +.04 to +.05 on all of our systems.

This is especially annoying since every Decklink update overwrites the Device Control presets.

We have one AJA card (Kona 3). The default offset for that is +.01. With or without the patchbay, it never needs to be changed on any deck I’ve used so far.

Sean

[Chris Borjis]

[Sean ONeil] “This is especially annoying since every Decklink update overwrites the Device Control presets.”

thats what final cut rescue is for 🙂

[Chris Borjis]

[Keith Koby] “mostly it occurs on the DVW-A500.”

Thats the digibeta deck we have.

It doesn’t happen very often though, probably 3 times in a year.

Are you saying I can fix it permanently? how?

[Sean Oneil]

[Borjis] “thats what final cut rescue is for :)”

Not really. FCP Rescue saves your preferences. “Custom Settings” for your Easy Setups don’t fall into that category.

Sean