Further misfortune occurred, when all the other camera, VTR and NLE manufacturers followed Sony's lead, and also use 24 fps timecode when in 23.98. They did not drop, and this meant timecode drifted away from reality just like 29.97NDF. Unfortunately, when Sony released the first 1080p/23.98 cameras, they decided to use 24 fps timecode. All you had to do was essentially a 24 Drop Frame calculation, and everything would work out. You could use simple 2/3 drop/add methods to convert between the two, and the hours. It was originally a great compromise for film vs NTSC TV production. NDF - use every frame (would be accurate if 29.97 was 30, but isn't at 29.97)ĭF - approximate the actual rate (30/1.001) by dropping 2 frames every minute, except the 10s For basic frame rates like 29.97 DF/NDF, 25 and 24, there were known rules everyone followed that made things very clear:Ģ4/Film - use every frame, always 24 a secondĢ5/PAL - use every frame, always 25 a second TcCalc was designed to be broadcast video calculator that work, at it's base, in frames. Darren Blackham alerted me to this thread and I though I would chime in. I am one of the developers who wrote TcCalc. Non drop frame SMPTE timecode counts all the frames and slowly goes out of sync with people-time because it's counting them at a slightly incorrect rate (assuming it's 23.976 or 29.97fps). It's people-time, but counting at the same incorrect rate as the non drop frame timecode immediately above it (24fps). and I'm already confusing myself thinking about this. It's not frames being dropped though, it's their timecodes. To keep it accurate in relation to human-time, SMPTE drop frame timecode counts frames at 30/24fps most of the time, but every now and then it only counts 29 or 23 frames in a second. Back when the frame rate was 30fps there was, naturally, a whole number of frames every second, but after the change to 29.97fps, the solution was to ignore the frame rate difference and keep counting at 30fps (or 24fps as the case may be). NTSC doesn't display a whole number of frames each second, so you can't count the frame numbers after "seconds" and have them "line up" for want of a better description. ie 13:54:04Īt the 20,000 frame mark, SMPTE would be about 0.2ms off. Is the "drop-frame" timecode the same as "Human time" then (other than the last frames are written in frames in stead of milliseconds)? It's 13 minutes, 54 seconds, plus four more frames.Ī colon means frame numbers at the end. However, 00:13:54:04 coming out as "drop-frame" timecode adds to my confusion, TBH. Thanks hello_hello for running the numbers. I'm sure TcCalc is a proper tool, but none of its options give me the time I'm after: 00:13:54:04.įor those of you that wanna check out the tool: There are more possibilities such as DF29.97, NDF30, PAL25 etc. There is also a "Film 24" window, which gives me the same result as the 23.98 window: 00:13:53:08. I probably don't fully understand the meaning of this 23TT mode too. It can (and probably will) be that this is the so-called "drop frame" timecode, but because I can't get my head around this dropframe thing (for now), I wouldn't know how to check if that's the case. Ok, in the TCCalc tool, when I put in 20000 at the frameswindow, the "23.98" window gives me 00:13:53:08. My numbers are confirmed by an online time-calculator. The conversion I do myself gives me a timecode (or should I say "running time") of 00:13:54:04, where the latter "04" is the last four frames. Okay, suppose I have a video that consists of 20000 frames. But this timecode I don't understand either.įor arguments sake, and as I am an example guy, I want to run the numbers with you guys with the following example, if you don't mind. This "TT" is supposed to be short for "True Time". Having read the article about the drop frame a couple of times, I am having trouble understanding it completely TBH.Īs said earlier, I probably misinterpret this "23.98" value.
0 Comments
Leave a Reply. |