Logic Pro 8 QuickTime's inspector and frame rate

Anyone know if QT inspector can distinguish between drop and non-drop? I opened up a movie that the BITC had shown as drop (with the 00;00) and opening it in QT it shows 29.97, not 29.97 drop. Wondering what's up.

Update: I opened the movie in STP and Final Cut and both showed the frame rate of 29.97, not 29.97 drop. In Logic the final frame is spot on using 29.97d frame rate as opposed to 29.97, where I'm about 2 frames off on a 65 second clip.
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:


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.