First, 30/1.001 is not an irrational number since it is exactly equal to 30000/1001 and an irrational number is a real number that cannot be expressed exactly as a fraction n/m of two integers.
But more practically if you started with 24fps video and just regularly counted frames, always dropping the last one out of every 1001 then it seems that, at least in the long run you would be exactly correct, with no cumulative errors. And it would also be exactly correct every 41.8 (1001/24) seconds or so. Wouldn't that be better than every 2 minutes?
So I don't understand the fancier stuff, unless you just want to force it into a repeating exact pattern of minutes for some reason.
- Tom John Shutt wrote:
----- Original Message ----- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>Yes, but I didn't get why 23.976 is not the way this is always done. Drop either 1 frame on 1001, or 1 frame in 1000, in a 24 fps stream, and the resulting frame rate will be either 23.976023976023976023976023976024 or 23.976000000, respectively. So why is this 23.976 frame rate a surprise?We're not dropping frames, Bert, we're dropping frame counts. Color NTSC is not really 29.97. It has a framerate of 30/1.001 which is anirrational number. "NTSC friendly" 24p has a framerate of 24/1.001, also anirrational number. Both are shortened to "29.97" and 23.976" because for most cases it's close enough, conveys the true meaning behind it, and is easier to say and write than "30/1.001" or "24/1.001" all the time. For frame accurate editing, the only criteria is that each and every framehave a unique and predictable number associated with it. You can (and earlyediting systems did) just number the frames from 1 to n. If you are at frame number 2,405, you know that the next frame will be 2,406. Or you can count by using HH:MM:SS:FF. If the current frame is 12:14:06:28, you know the next frame will be 12:14:06:29. 30/1.001 (29.970029970029 as you say) can also use the same HH:MM:SS:FF frame counting, and often does. This is non-dropframe timecode. The only problem with non-dropframe timecode is that although the timecodenumbers uniquely and predictably identify each and every frame of video, the hours minutes seconds scheme no longer reflects the actual time it will taketo play back in real time.This is not a problem with :30 spots, but a 30 minute program will be off bya few frames. In 30 minutes, there are precisely 54,000 30 fps frames. In the same 30 minutes, there are only 53946.05395 29.97 fps frames. So, if you just used the normal non-dropframe timecode scheme to assign a value to every frame in that "30 minute" program, the timecode of the last frame of the 30 minute 29.97 fps video would be "00:29:58:06", even though it took exactly 00:30:00:00 to play the video back. Therefore, if you want the timecode values to correctly reflect the amount of time it would take to play the video, you need to adjust the timecode numbers so that the 29.97 fps video keeps relative lock with real time. If you do, then when the first frame count is "00:00:00:00" and the last frame count says "00:30:00:00," you know it will take exactly 30 minutes to play it back. There are approximately 1.7982 fewer 29.97 frames per minute than there are 30 fps frames. (1800 vs. approximately 1798.2018.) Therefore, in order for the timecode count of 29.97 fps frames to line up with the real time it would take to play back those frames, you need to skip some numbers. The easy way is to see that there are 17.982018 fewer 29.97 frames every 10 minutes than 30 fps frames. Therefore, in a ten minute period you need to skip counting 18 frames (nearest whole number, since you cannot count a fraction of a frame in timecode) every ten minutes. Remember, earlier I said one of the criteria of drop-frame timecode is thatit has to be predictable. This is so editing controllers can calculate time and find the proper frame for in and out points. So the drop frame rule is:"Drop two frames every minute except every ten minutes." So, if you start at zero, when you get to a timecode count of 00:00:59:29(HH:MM:SS:FF), the very next frame of video will have the count 00:01:00:02.You skipped the counts of 00:01:00:00 ad 00:01:00:01. You skipped two frames.The same thing happens at 00:01:59:29, 00:02:59:29, 00:03:59:29, etc. Untilyou get to 00:09:59:29. At that time code, the very next frame of video will have the count 00:10:00:00, because you do not skip any counts every ten minutes. Therefore, in ten minutes you've skipped 18 frame counts, and the drop frame timecode lines up with the real time it takes to play back the video.Last, if you are using non-dropframe timecode, it is customary to denote all colons in the timecode. If you are using drop frame, a semicolon is used toseparate the seconds and frames: HH:MM:SS;FF Sometimes all of the punctuation is replace with semicolons: HH;MM;SS;FF With 24/1.001 fps video, the concept of drop-frame timecode is the same: You want the timecode numbers on the video to match the real time it would take to play back that video. I presume that Russ' customers want the running timecode numbers to match the actual running time of the material, but as far as I am able to tell there are no hard and fast (thereforepredictible) rules for calculating drop frame timecode for 24.976 fps video.So let's try to make one. There are 1440 24 fps frames per minute, there are only approximately 1438.561439 23.976 fps (or more accurately 24/1.001 or 23.97602398) frames. Therefore, in order to keep the timecode count in alignment with real time, you need to drop 1.438561 frames per minute, or 14.38561 frames every ten minutes. Not as simple and elegant a problem as we had with 29.97 fps video. What Russ came up with, and what I independently came up with, was to dropone frame in the first minute, two frames in the second minute, one frame inthe third minute, two frames in the fourth minute, etc. In this way, you will drop 14 frames in the first ten minutes, 15 frames in the second ten minutes, 14 in the third ten minutes, 15 in the fourth ten minutes, etc. Your desired number of frames to drop every ten minutes is 14.386 frame, so you are "bracketing" the target number.However, after a certain time, you drift away from real time because you aredropping an average of 14.5 frames per ten minutes, when you really want to drop only 14.386 frames every ten minutes. Russ came up with a list of exception minutes and hours that when taken together would have corrected to within one frame per 24 hour period, but I thought the list of exceptions was unwieldy and hard to memorize. I came up with a simpler rule that said to drop only one frame instead of two frames every odd tens place of minutes (1x, 3x, 5x, etc.), and to droponly one frame instead of two frames every odd hour. This scheme is easy toremember, easy to calculate or predict what the next timecode count should be, and keeps you within 4 frames in a 24 hour period. My rule: "Drop one frame every even minute, drop two frames every odd minute, except drop one frame every odd tenth minute, except drop one frame every odd hour." Therefore, at count 00:00:59:23, the next count would be 00:01:00:01, skipping one frame (frame number 00:01:00:00.) because the minute was odd (at 01 minute.) At count 00:01:59:23, the next count would be 00:02:00:02, dropping two frames, because the minute was even. At count 00:09:59:23, you might think you need to drop two frames because the next minute mark would be "10" which is even, but the tens digit of theminute count is odd, so you would drop only one frame. The next count wouldbe "00:10:00:01." Ditto at count "00:59:59:23." You might think you need to drop two frames, because the tens column of the minutes is even (0 is treated as even), but because the hour count is odd (01) you drop only one frame. The next count would be "01:00:00:01."However, at "01:59:59:23", the next count would be "02:00:00:02" because theones of minutes column is even, the tens of minutes column is even, and the hours column is even. Confusing, but predictable and I think workable if you use it daily. With this scheme, you're off by 4.472 frames at the end of a 24 hour day. As I said, with 23.976 HD video being shot daily, a formal SMPTE/EBU scheme for drop frame timecode is sorely needed, and would make an excellent paper for the SMPTE. ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways:- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.
-- Tom Barry trbarry@xxxxxxxxxxx ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways:- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.