1 person found this helpful
Let me explain. This is going to get a little long so let me first start by saying that NO frames are lost, blended or dropped when you run at 29.97 fps. The only thing that changes is the way you count frames. This info will be part of an upcoming white paper on my new website.
When color television came along the engineers needed to add some lines in the blanking part of a TV signal to send along the color information. It is called color burst. The number of new lines they needed took .03 seconds to add to the signal. Since everything countries that run 60 Hz electricity runs at 60 Hz, and television at the time was interlaced with one pair of even and odd scan lines make up a frame so rather than speed up the time it took to draw each scan line the decided to reduce the frame rate to 29.97 fps to keep things running at an even multiple of 60 cycles. This would keep old Black and White TV sets working without problems. Changing the time it took to paint a scan line would foul things up for older sets. PAL Countries figured out a better way to add color information by using some existing lines that were not being used for anything so they eliminated the problem.
Did that make sense? They had to slow down the frame rate because they needed to add some lines to the signal so color TV's would know when they were supposed to show the program in color. The larger number of lines still had to fit in 60 cycles so if you added more lines you must playback fewer frames per second.
Now here comes the problem. How do you count that odd number of frames and make it work with a real time clock. Drop Frame timecode was the solution. Drop Frame timecode does not drop frames, it just doesn't count them all because when the standard broadcast half hour is 28 minutes, nobody is going to care about a missing frame number... NOTE: I did not say missing a frame.
Let me say this again. NO Frames are ever dropped or squished or shortened in any app that is used to edit or manipulate video. The only thing that happens is that certain frame numbers skipped so the hours, minutes and seconds displayed on the timer is always accurate.
You can get funky things happening with individual frames or fields when you put 24 fps footage from a movie in a 29.97 fps video sequence - but they worked that out already. The same thing happens when you add PAL footage to an NTSC program. When 24 fps footage is put in a 25 fps PAL video format they just play it back a little faster so they don't have to do funny frame blending.
Let's get back to the time display in your AE timeline when you have a 29.97 (or any of the standard fractional frame rates like 59.94 or 23.976) The default time display should be drop frame timecode which drops frame numbers as it counts but does not drop frames. With DFTC (indicated by the ; between the hours, minutes and seconds) is used when the timeline says 30 minutes then it is going to take 30 minutes exactly to playback your video. You can check this out for yourself by stepping through a timeline with Drop Frame Timecode displayed one frame at a time. Select the timecode window and top in 10000 (1 minute no seconds no frames) You will end up at 0;00;59;28. Step forward one frame to get to 0;00;59;29; and then one frame farther and you end up at 0;01;00;02. No frames were dropped, only the frame numbers of 0;01;00;00 and 0;01;00;01. The displayed time is accurate to within the duration of a frame, which doesn't make much difference when you are dealing with one minute but it makes a huge difference if you are dealing with an hour.
There is an option for Non-drop frame timecode but in practical times this is useless because the time indication in the timeline is always wrong. The longer the program the larger the error. Drop frame timecode gives you the correct time with a maximum error of a frame and a half. In an hour program you are off by about 4 seconds. That's not significant for a youtube video, but it would disastrous for network programing.
You can check this out for yourself. Start a new comp and make the duration 1 hour. Add a solid layer and then press o to go to the out point and you will see that the timecode is 0;59;59;29 frames. Don't get confused here because it doesn't say 1 hour. Remember that the last frame still needs to play for the program to end because the CTI stops on the last visible frame. Now hold down the Ctrl/Cmnd key and click on the time indicator in the timeline and you will see 107891 frames. One word of caution, if you are looking at the timecode display and you change the comp or project from drop frame to non drop frame timecode you will change the length of the composition and the number of frames.
Now go to the Project settings in earlier versions or the Composition Settings in the latest releases and select Non Drop Frame from the timecode display. Check the frame numbers - They are exactly the same. Now Ctrl/Cmnd click on the time indicator again and you'll see 0:59:56:11 --- If you were creating an hour long program and you had the timecode set to Non Drop Frame your program you would want to add about 4 seconds to your program. Imagine your surprise when it played on TV and the last 4 seconds was cut off.
Thanks for the in-depth response! Took me a while to wrap my head around it, but I think I've got it. So NDF for 29.97fps would always show exactly 30 frames per second for every second on the timeline, but the indicated seconds would never line up (except for at 0 seconds) with the actual real-world time elapsed. And the more time that went by, the more it would be off.
Whereas with DF 29.97fps, the indicated seconds would still be different from real-world elapsed time a little bit for some points on the timeline (as you said, a max error of a frame and a half), but at other points it would line up perfectly. Does this sound correct? And is the frame-and-a-half max error only for 29.97fps or would it apply to all standard fractional times? Also, what happens with non-standard fractional times? I tried some out and it seems AE only allowed for NDF. So they would just get off track as more time went by?
My biggest takeaway from this is that I can't trust the second markers to be exactly correct, no matter if it's NDF or DF. NDF is much closer but can still be off. I doubt this will be an issue very often, but it's good to know. So if I wanted to display a digital clock animation on the screen and have it be 100% exactly in sync with real-world time, I wonder if there is a way to actually do this exactly via code (an expression?) of some kind?
Anyway thanks and sorry for asking so many questions.
You missed it. Non-drop frame timecode always displays the time accurately to within a maximum error of one and a half frames. This air is insignificant and automatically correct every one minute. It's exactly like leap year. Every four years February has 29 days so the calendar stays accurate. The seconds counter is always right on. There is no reason to ever use non-drop frame kind code.
No frames are ever dropped.