MOTUnation.com

I recently acquired the DP7.01 upgrade in order to accommodate 23.98 SMPTE frame rate (23.976 rounded) favored by film editors working on AVIDs, etc. It turns out that, while the software operates correctly, the MOTU interfaces have issues with generating the SMPTE audio code for striping a track. I am doing remote ADR and need to be able to drive the remote session, which is slaved to me via ISDN. Is there an alternative way to generate 23.98 SMPTE audio code that doesn't cost hundreds of additional dollars? Actually, I would love to generate SMPTE audio code on the fly and skip the striping step. Any ideas out there?

Are you referring to LTC signal? I don't know of any hardware that will generate 23.976 fps LTC, but you can generate 24 fps LTC, record it to a 48kHz audio file, and then hack the sample rate on the file to 48048Hz. Then when you play that back, the playback engine in DP (or FCP or Avid) will sample-rate-convert it to the playback rate, which will slow it down to the appropriate rate to match NTSC rate differential (1000/1001), you have 23.976 fps LTC. You can then even edit it into a DP (or FCP, or Avid) sequence, and play it back to an output channel, or do whatever other striping you need. I've done this before, and it works fine.

Fortunately, there is no such thing as 23.976 drop, otherwise if you needed 23.976 drop, you would not be able to do this trick (because there is no such thing as 24 drop, so the frame counting would be wrong)...

Oh, and BTW while 23.98 is an approximation for 23.976, even 23.976 is an approximation for the true rate, which is 24 * 1000 / 1001, which is actually 23.976023976023976(repeated)... But hey, that's mightily splitting hairs...

Hope this helps...

Brilliant! Thanks for that, as I wouldn't have thought of it. Yes, LTC. But on the point of approximations, all the literature I've seen states that the differential is .1% (not 1000/1001) this also being the diff between 30fps and 29.97fps. As you say, it's splitting hairs. But it leads to other questions. Is there some lit that explains the basic reason for these differentials?

The literature you site is not the SMPTE spec, then...

The difference really is 1000/1001, and it is for 29.97 as well (which is actually 29.97002997002997(repeats)...). It does increase the frame period by exactly 0.1%, because period is the inverse of rate, so the ratio is 1001/1000 for period, but the frame rate ratio is 1000/1001, which 99.9000999000999(repeats)% by the specification (and actual electrical behaviour, for analogue) for NTSC video, which truly has a rate of 30 * 1000 / 1001.

The SMPTE spec is not online, of course, but you can find this in various articles online (like <http://www.philrees.co.uk/articles/timecode.htm>) and it is glossed over in other articles (like the Wikipedia entry for NTSC, which states that the rate is "approximately" 29.97).

This also actually makes it much easier for audio, BTW, since at the true NTSC rate, audio has exactly 1601.6 samples per frame (note that samples/frame is the frame period in samples), or, more to the point, 8008 samples per 5 frames, repeating as the pattern {1602, 1601, 1602, 1601, 1602}, which you may hear referred to as the "SMPTE cadence". Whereas if it truly were exactly 29.97 fps, then audio would run at 1601.601601601601(repeats) samples per frame, which (for all practical purposes, given the 24-hour limit of timecode) "never" resolves to a useful number...

Of course the error creep due to this subtle difference is gradual, and for video is largely inconsequential, since you would not be off by a full frame until after 1,000,000 frames, which is about 9 hours... But for sub-frame accuracy (which is more a concern for audio), you will be off by 1 sample after 1,000,000 samples, which (at 48kHz) is just 20 seconds, and off by about a tenth of a frame after "just" an hour...

While most video-related apps (such as FCP, Avid, and I think Premiere) deal with this correctly, a surprising number of DAWs (even the ones purporting to be used by audio-for-video folks) do not. DP used to do this calculation incorrectly (even as late as 5.13, IIRC), but nowadays (since maybe 6.0) they do the math correctly. You can verify this by setting the frame rate in DP to 29.97 non-drop (makes the calculations of TC to frame count easier...), and then set the TC to exactly 300,000 frames (i.e. 02:46:40:00 in non-drop TC, since the timecode rate (not frame rate!) of non-drop is 30fps). Set DP's other counter to samples, and you'll see 480480000. That is precisely right, whereas if the frame rate were truly (exactly) 29.97, then the sample count would be 480480480(.480(repeats)). So DP is (correctly) using the true NTSC frame rate of (30 * 1000 / 1001), rather than the approximate NTSC rate of 29.97. Another test is to set the _non_-drop TC in DP to 00:00:20:25 (625 frames), and note that the sample count is 1001000; again, if the frame rate were truly 29.97, that would show 1001001 (i.e. 625 frames / 29.97 fps * 48000 samples / second = 1001001.001001(repeats)).

Hope this helps clarify...

Awesome dp-user! You have just given me more clarification on this topic than any source I have found prior. Thanks so much. Also, good to know DP is "up to speed" on this issue.

MOTU's mk3 FireWire interfaces can send and receive LTC
at 23.976, 24, 25, 30 drop, and the standard frame rates.