smpte timecode to timecode dat from PT LE 6.2.2

[shake]

hello everybody,

quick question for anyone who can help...

i am editing music and dialog for a television show (29.97df @ 48khz). i have to deliver a time code dat as my finished mix.
i was looking into getting the DV Toolkit, motu midi express xt, and a fostex d-25 time code dat machine. i will be receiving quicktimes (with burned in timecode) for video reference.

so... to deliver a final mix on timecode dat,i want to generate mtc from PT and send it to the midi express xt (via midi) which will convert it to smpte. from there it goes into the timecode in on the back of the dat machine. dat machine's clock will be set to slave (via spdif) and PT will be clock master.

will this work? or is there a better setup that i havent considered?

any and all help will be appreciated!

thanks!
Dave

[Rail Jon Rogut]

Sounds like it should work - loaction via MTC and speed via S/PDIF. You may have some small discrepancies due to MTC being only quarter frame accurate.. but it should work fine.

Rail

[shake]

i understand about MTC being 1/4 frame out... its no different than a SyncIO and USD though...
they just convert MTC to smpte anyway....

has anyone tried this setup or a similar one?

[Rail Jon Rogut]

The difference is that in the USD and SyncIO the leading edge of the SMPTE is aligned with the word clock.. here you're using separate boxes. You'd have to test how your setup works with multiple transfers - and see what it averages out to. By using separate devices for SMPTE and S/PDIF the SMPTE is not going to be synchronous.. you could try using a MOTU DTP.

Rail

[Bob Olhsson]

The quarter-frame accuracy business is an urban myth from the folks who want to sell us an additional synchronizer with every piece of gear. Most video gear refreshes way less often than that!

What counts is what's called the frame rollover and MTC is every bit as accurate as any other kind provided the time code has been resolved and frame-aligned with a synchronizer. I've used both a Sony 7030 TC DAT machine and DA-88s or 98s very successfully as synchronizers. Just slave PT to the machine's clock and then chase the machine's code. The interval of refresh only affects how quickly something locks up. You WILL need to test and calculate a sample-offset to put the rollover on the money anyhow because all devices have slightly different time code latencies.

[Rail Jon Rogut]

Far from being an urban myth.. it takes multiple MIDI messages to get the full time code message.. which has a worst case scenario of taking a quarter frame.

Link

As I wrote before.. by using separate boxes.. his SMPTE isn't going to be synchronous with his digital clock.. which means the trigger point could be slightly off -- he needs to see how far off this is. It'll definately be less than a quarter frame.. but it's not going to be as good as a device like a USD which sends out synchronous SMPTE and clock.

Rail

[Bob Olhsson]

It actually takes multiple FRAMES to pass the entire color-sync message in a video system.

Lock only happens on the sync word at the frame rollover AFTER the complete location address has been received no matter how long that takes. The only difference taking longer to receive the entire address makes is to the length of time it takes to achieve lock. You could even use smoke signals IF the sync word and frame rollover are right on the money! Faster data communication does not make sync more accurate. It just makes it happen faster.

You only need or even want ONE synchronizer in a system and that might as well be the one that's built into his time code DAT machine. This is not explained very well in documentation or books, sadly.

[Rail Jon Rogut]

I think what you're saying is consistent with what I said.. that the synch words are what's important in synchronisation.. most systems merely phase lock to the SMPTE synch words anyway -- my point is (and I think you're agreeing) is that by using different devices the SMPTE synch words are not synchronous with the Video fields or leading edge of the digital word clock. The problem then is that the trigger point isn't lined up with a leading edge.. and causes inconsistency.

<font class="small">Code:<hr /><pre>
Unsynchronous:

SMPTE |----|----|----|----|----|
CLOCK |-----|-----|-----|-----|

Synchronous:

SMPTE |-----|-----|-----|-----|
CLOCK |-----|-----|-----|-----|

TIME 1-----2-----3-----4-----5
</pre><hr />

As you can see if we trigger off the 3rd synch word with the unsynchronous code - playback will be different than with the synchronous code - by using a simple/cheap MTC->SMPTE box the speed of the SMPTE will be nowhere close to consistent, which is the point I was trying to make.

Rail

[Bob Olhsson]

The point I'm trying to make is that his TC DAT machine HANDLES this. The only thing left to deal with is the latency of the timecode to MTC to MIDI interface system which is a sample-offset in the session setup window. This always needs to be calculated in ANY system because it varies with each particular CPU, DAT machine, video sync generator phase, etc. Timecode can never be "plug 'n play" you've got to align it.

[Rail Jon Rogut]

Sorry Bob,

By using the right hardware and ensuring that my SMPTE and Video/WC is all synchronous.. I've never had to worry about changing the SMPTE offset in Pro Tools.

The value would never be consistent with a cheap MTC->SMPTE box anyway. Even higher end SMPTE boxes like the TimeLine Lynx would drift over time with thermal changes unless they were referenced to black burst.

Rail