[Keith Koby]

My bet is that it has more to do with latency of the hd codec vs. sd codec you are using.

Go to A/V settings. Go to device presets. Duplicate your HD device control. Change the ETT latency setting from the default 4 to 5 frames. Then save your setup as a custom setup with the new device control.

Check to see if your laybacks are then consistently frame accurate.

[Keith Koby]

Sorry, I don’t know why it happens myself. I have a theory that when ref is provided to both devices, it doesn’t happen. However, most of the time we are syncing to incoming sdi…

The deck does beta sp and digi, so I think that the analogue components still want sync even when working with sdi source. Without the external ref, it wants to default to ndf even though a tape striped with df black and code is in the deck. It doesn’t make a lot of sense, but I think something here is messing with the communication between FCP, the card and the deck. The math is getting messed up or the signal is getting corrupted by one device asking for ndf…

I haven’t found a way to fix it permanently. You can check to see if will happen before laying back by hitting the “go to in” button in the ETT window. If it cues to the appropriate time code, you are ready to go. If it goes to the 3 sec and 18 frame offset, simply re-enter the time code in the “in” field, hit enter and hit “go to in” again. Check to make sure it cues appropriately this time. After re-entering the “in” time code, the problem usually clears up.

I’ve spoken with several people at Apple about this and no one has an answer.

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…

[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]

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.

[Keith Koby]

What version of the BMD drivers are you running?

[Keith Koby]

see my post below about my experience with audio when upgrading to 6.2…

Check the capture preset in the a/v settings menu. Try setting audio device to none, and then back to decklink.

[Keith Koby]

Do you need to boost or reduce gamma when exporting for a PC in WMV (through episode)?

[Keith Koby]

No problem. Hopefully BMD is working this out for 6.3.

[Keith Koby]

You are not using the AU plugin version in protools, but FCP wants to load them. Just move the AU versions to a different folder and then FCP will not see them on start up. We do that here and it works fine.