drop frame setting in scenarist

[jamieg]

hi guys,
ive just encoded a movie using the new updated guides and i got a question.when you import ntsc assets why do you have to set drop frame?i did a movie and all was good and then i did another and forgot to set drop frame so it was on non drop frame.it still seems fine though plays ok.so basically i suppose my real question is what is the differance between drop frame and non drop frame,and when do wwe use them?
cheers

[pngoc]

Basically, drop frame is 30 and non drop frame is 29.97. Anyway, most encoding now are 29.97 Drop frame will be drop 1 frame for every 10 minutes. I believed the drop frame is for broadcasting to match the lock time.

[SomeJoe]

Drop frame and non-drop frame timecodes are two different ways of labeling frames of NTSC video.

It is important to note that these are labeling methods only. The frame rate of the NTSC video does not change (always remains 29.97 fps), and the number of frames does not change (no frames are lost or added in the video stream). Only the way each frame is labeled is different.

For example, say I have 5 objects, and I number them using the set of "natural numbers":


Objects: X X X X X
Numerical Label: 1 2 3 4 5


This is simple enough. However, I can change my numbering system to use the set of "whole numbers" instead:


Objects: X X X X X
Numerical Label: 0 1 2 3 4


The way the objects have been labeled has changed, but the quantity of the objects has stayed the same.

Non-drop frame timecodes are in the format HH:MM:SS:FF, where H, M, S, and F represent the hours, minutes, seconds, and frames of video. The frames counter goes from 0 to 29, seconds from 0 to 59, minutes from 0 to 59, hours from 0 (sometimes 1) and up. The advantage of non-drop frame timecode is that it is easy to count, and easy to make calculations with. You can easily convert a non-drop frame timecode to a frame number and back, which facilitates easy addition & subtraction of timecodes. The disadvantage of non-drop frame timecodes is that the counter does NOT exactly correspond to real, wall-clock time. At exactly 1 hour into the video, the non-drop frame timecode will be 00:59:56:12, off by about 3 and half seconds. This is because the video actually runs at 30000/1001 = 29.97 frames per second, not 30.

Drop frame timecodes are written in the format HH:MM:SS;FF (note the semicolon before the frame counter to signify drop frame format). A drop frame timecode gets its name because certain timecode values are skipped when counting. In drop frame timecode numbering, frame numbers XX:XX:XX;00 and XX:XX:XX;01 are skipped on every minute boundary, except minutes which are evenly divisible by 10. For example:


00:06:59;28
00:06:59;29
00:07:00;02
00:07:00;03


That would be a proper drop frame timecode sequence. On the 10-minute boundary, it looks like:


00:09:59;28
00:09:59;29
00:10:00;00
00:10:00;01


The skipping of certain frame numbers has the tremendous disadvantage that calculations with drop frame timecodes are extrordinarily difficult. Converting a drop frame timecode to a frame number or vice versa has no neat mathematical relationship, and typically has to be done with some table lookup. However, offsetting this problem is the advantage that drop frame timecodes correspond EXACTLY with real wall-clock time. At exactly 1 hour into the video, the drop frame timecode reads 1:00:00;00.

A large problem with many tools is that they don't pay enough attention to the difference between the two timecode formats. Inevitably, this leads to multiplexed content where one stream slowly loses sync with another stream, whether it's audio, video, or subtitles. If you ever run into this situation, it's generally because one of the streams is marked non-drop frame and the other is marked drop frame. When the authoring or multiplexing software tries to put the two together using the timecodes as a reference, the two streams will slowly lose sync.

Some tools even label their timecodes incorrectly. Soft Encode, for example, will add timecodes to an .ac3 stream (which is good ... it allows authoring software like Maestro to perfectly synchronize the audio and video using timecodes). But, (as far as I can tell), the timecodes it adds are drop frame, but marked as non-drop frame. This leads to the warning message in Maestro of "video and audio timecodes are different formats", even though the streams will actually be synced anyway.