I posted over at the Logic Pro Help forum last night and moderator ski responded with a very definitive answer:
Hi Doug!
The answer is "no", QT cannot distinguish. This is because 29.97nd and 29.97df are the same frame rate -- both running ever so slightly slower than 30 fps. The difference between df and nd is simply how the frames are numbered (striped) with timecode and not a difference in speed. Explanations to follow.
At 29.97 there are still 30 frames in each "second" of SMPTE units (HH:MM:SS:FF), although in this case each unit of SMPTE seconds runs slightly longer (slower) than real time seconds.
With 29.97 (df or nd) it's not like there are 29 full-sized frames and one that's slightly shorter than the others (i.e., one frame that's .97 of a frame long), all of which combined span an actual second of time. Rather, all frames are the same length, and as mentioned, there are 30 frames in each unit of SMPTE seconds. But here's the rub: with non-drop, frames are numbered with sequential timecode values, so over time, the timecode burn's count of elapsed time will be seen to drift away from real time. (See note below).
As you know, a timecode burn is simply a sequential series of timecode numbers painted on each frame of film (a video overdub, if you will). To compensate for the time drift, the 29.97 drop frame timecode number painting scheme (ingeniously) calls for a few frames of timecode numbering to be skipped at regular intervals to make up for the time discrepancy. Here's how it works:
At the first second of every SMPTE minute, frame numbers 0 and 1 are skipped (except when the SMPTE minutes value is divisible by 10). This would account for why you're seeing a drift of 2 frames in your film.
So in a 29.97df timecode burn you'll never see the SMPTE values for 01:00:00:00 or 01:00:00:01. These values are simply skipped. Again, it's not like there are frames being cut from the film. Instead, the SMPTE numbers are fudged. For example, when the time wraps from the 59th minute to the first hour, the frame numbering will be:
00:59:59:28
00:59:59:29
01:00:00:02
Note: When working at 29.97nd the timecode burn doesn't express actual running time or elapsed time. Drop-frame timecode numbers, however, express a more accurate picture of actual elapsed time. In short, when working at 29.97 frame rates, it's best to think of the timecode numbers as "frame identification numbers" and not a way of gauging absolute running time.
HTH.
