Timecode <==> frame number tool?

[Ennio]

Hi all,

Does anyone of you know if there is a simple, standalone tool to do timecode/framenumber conversion, and vice versa?
I know VirtualDub shows both of a loaded video, but I just want a tool for quick calculation purposes.

[smrpix]

Google "timecode calculator." There are dozens of good options -- online, desktop and phone.

(At this point I do conversions within my NLE(s) so I haven't used one for years and have no specific recommendation.)

[Ennio]

Thanks smrpix. Found one that's reasonably intuitive, TcCalc.

cheers

[Julia34]

Thanks smrpix. Found one that's reasonably intuitive, TcCalc.

cheers

Which one did you use?

[Ennio]

Like I said, TcCalc. ??

[jagabo]

For constant frame rate video:

time = frame_number / frame_rate

rearranged:

frame_number  = time * frame_rate

[Ennio]

I understand the math, working the numbers isn't the issue. They can be done with pencil & paper, if need be.

I was more after the convenience of a handy tool to make these conversions quickly. Speaking of which, I thought I had one...

In TcCalc, there is this "23.98" timecode. I thought this was for 24000/1001 fps, but the numbers are wrong. I checked several times. Manually and also with online calculators and find that A: TcCalc is wrong, or B: I misinterpret this "23.98" value. The latter probably being the case.
Anyways, whatever I try with this tool, I can't get the numbers right for 24000/1001 framerate. So, time for finding another one.

[jagabo]

In TcCalc, there is this "23.98" timecode. I thought this was for 24000/1001 fps, but the numbers are wrong.

Maybe it' using "drop frame" timecode. See if there's an option for that.

https://en.wikipedia.org/wiki/SMPTE_timecode#Drop-frame_timecode

[smrpix]

In TcCalc, there is this "23.98" timecode. I thought this was for 24000/1001 fps, but the numbers are wrong.

Maybe it' using "drop frame" timecode. See if there's an option for that.

https://en.wikipedia.org/wiki/SMPTE_timecode#Drop-frame_timecode

I suspect jagabo is right (he usually is.) That could give the appearance of two missing frames a minute (except on the 10s.) It would be interesting to hear in what way TcCalc is getting it wrong. There are also broadcast conventions such as calculating the outpoint as last frame +1.

[Ennio]

Having read the article about the drop frame a couple of times, I am having trouble understanding it completely TBH.
As said earlier, I probably misinterpret this "23.98" value. There is also a "23 TT" timecode. This "TT" is supposed to be short for "True Time". But this timecode I don't understand either.

For 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.

Okay, suppose I have a video that consists of 20000 frames. Constant framerate is 24000/1001.

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.
Or, with seconds in decimals: 00:13:54.16666666666 etc. My numbers are confirmed by an online time-calculator.

Ok, in the TCCalc tool, when I put in 20000 at the frameswindow, the "23.98" window gives me 00:13:53:08.
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.

The "23TT" window gives me 00:13:54:00. Now, this also differs. I probably don't fully understand the meaning of this 23TT mode too.

There is also a "Film 24" window, which gives me the same result as the 23.98 window: 00:13:53:08.
There are more possibilities such as DF29.97, NDF30, PAL25 etc.

I'm sure TcCalc is a proper tool, but none of its options give me the time I'm after: 00:13:54:04.

For those of you that wanna check out the tool: https://www.drastic.tv/productsmenu-56/videoiosoftwarelist/76-videosw/utilities/181-tc...ode-calculator

[hello_hello]

TcCalc seems to be a little off, but maybe there's something about SMPTE time-code I don't understand.

Avisynth says.....
frame 20000 at 24000/1001 fps.

Top: Human time (milliseconds)
Middle: SMPTE drop-frame timecode
Bottom: SMPTE non drop frame

BlankClip().killaudio().Loop(1000)
AssumeFPS(24000,1001)
Info()

ShowTime(y=200)
ShowSMPTE(y=250)

AssumeFPS(24)
ShowSMPTE(y=300)
AssumeFPS(24000,1001)

[Attachment 55900 - Click to enlarge]

[Ennio]

Thanks hello_hello for running the numbers.

Glad to see the "Human time" confirmed. However, 00:13:54:04 coming out as "drop-frame" timecode adds to my confusion, TBH.

Is the "drop-frame" timecode the same as "Human time" then (other than the last frames are written in frames in stead of milliseconds)?

[jagabo]

For those of you that wanna check out the tool: https://www.drastic.tv/productsmenu-56/videoiosoftwarelist/76-videosw/utilities/181-tc...ode-calculator

Isn't that pulldown near the top right where you select between DF and NDF?

[Ennio]

I'm not sure I understand your question, jagabo.

Here is a screenshot of the tool with the options:


[Attachment 55903 - Click to enlarge]

Can you please rephrase your question or have I answered now?

[smrpix]

Getting back to basics: your material does have an actual number of frames. In order to do the timecode > frame number calculation properly you need to determine the time base of the specific material you are working with. Using milliseconds (what you are calling human time) is interesting but is only a distraction from the math problem at hand.

[hello_hello]

Thanks hello_hello for running the numbers.

Glad to see the "Human time" confirmed. However, 00:13:54:04 coming out as "drop-frame" timecode adds to my confusion, TBH.

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.
A colon means frame numbers at the end. ie 13:54:04
A dot means milliseconds. ie 13:54.166
At the 20,000 frame mark, SMPTE would be about 0.2ms off..... I think.....

From memory....
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. 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). 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. I can't remember how often. It's not frames being dropped though, it's their timecodes.

If it helps..... and I'm already confusing myself thinking about this..... I've added another time to the pic. It's the bottom one. It's people-time, but counting at the same incorrect rate as the non drop frame timecode immediately above it (24fps).


[Attachment 55905 - Click to enlarge]

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).

Getting back to basics: your material does have an actual number of frames. In order to do the timecode > frame number calculation properly you need to determine the time base of the specific material you are working with. Using milliseconds (what you are calling human time) is interesting but is only a distraction from the math problem at hand.

I just navigated to a specific frame (frame number 20,000) and told Avisynth to display the timecodes (at 23.976fps).
The calculator only displays SMPTE time, so you can either navigate to a specific frame number, or to a specific SMPTE timecode, but it does appear to be getting the calculation wrong. That's what Ennio was wanting to do. Enter a frame number and find the corresponding timecode. Personally, I'd rather work in human-time, but that's just me.

[jagabo]

Drop frame time code is based on 24 fps.

20000/24 = 833.3333 sec = 13:53.3333 = 13:53 + 8 frames

[hello_hello]

This calculator agrees with Avisynth.

http://www.zapstudio.net/framecalc/

[James Brooks]

Hi All

I am one of the developers who wrote TcCalc. Darren Blackham alerted me to this thread and I though I would chime in. TcCalc was designed to be broadcast video calculator that work, at it's base, in frames. For basic frame rates like 29.97 DF/NDF, 25 and 24, there were known rules everyone followed that made things very clear:

24/Film - use every frame, always 24 a second
25/PAL - use every frame, always 25 a second
NDF - use every frame (would be accurate if 29.97 was 30, but isn't at 29.97)
DF - approximate the actual rate (30/1.001) by dropping 2 frames every minute, except the 10s

Then came 23.98 (24/1.001). It was originally a great compromise for film vs NTSC TV production. You could use simple 2/3 drop/add methods to convert between the two, and the hours. minutes, seconds would always line up. All you had to do was essentially a 24 Drop Frame calculation, and everything would work out. Unfortunately, when Sony released the first 1080p/23.98 cameras, they decided to use 24 fps timecode. They did not drop, and this meant timecode drifted away from reality just like 29.97NDF. 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. Because of this, TcCalc always uses 24 fps timecode when you select 23.98. We did, however, want to be able to calculate proper durations in a way similar to 29.97DF, so we added the 23.98 TT (true time) that calculated the 23.98 with frame dropping to more closely approximate the actual 24/1.001.

When you use multimedia/non broadcast calculation, they tend to just use the actual 24/1.001 (23.97602397602398) which gives perfectly accurate frame counts, but can not be used for repeatable dropping for frames and known spots that editing requires. None of TcCalcs calculations use the true frame rate, as which frame is dropped, or not, must match with other NLE, VTR or cameras, or the final edits and outputs will not match up.

Hope this explanation helps!

Cheers, James

[Ennio]

Hi, James, thanks for dropping by. Quite a surprise, I must say.

Coincidentally, I am reading this document: https://www.connect.ecuad.ca/~mrose/pdf_documents/timecode.pdf
I must say this is an eye-opener for me, now that I'm in the process of understanding the whole drop-frame concept. I just couldn't get it. I'm still not there though. But, now that it's becoming more and more clear, I think a big chunk of my confusion layed in not understanding the difference between "what happens in real-time" and "the use of which meta-data to keep up with that real-time".

This, and reading your post, make things more and come together. Whereby reading about the history of video gives one more grasp.
I will have to read some things over a couple of times before I'll fully get this.
Furthermore, it's nice to read and also more understand why "my numbers" don't show up in the TcCalc tool. Makes me feel more confident.

Again, thanks for pulling over and taking the time for your explanation.

[James Brooks]

Hi Ennio

Happy to! I have landed in this forum before while googling in the past. Glad I finally had something to add

Cheers, James

[Ennio]

As the fogs are dissolving around this whole drop-frame thing I've come to realise, that I have been busy with drop-frame timecodes all this time, without knowing it, haha.
When you throw in the fact that I did not understand anything about "drop-frame", all together it made for a quite a psychedelic trip, I must say. Like a mad dog chasing his own tail
Your post definitely contributed to my comprehension of it all. And understanding of the TcCalc tool.

Cheers James, thanks.

[hello_hello]

Thanks James.

I think what my brain was expecting were frame rate choices such as:

30 / 29.97 NDF (Apparently Premier says it's a thing)
29.97 DF
25
24 / 23.976 NDF
23.976 DF

So does 23 TT mean 23.976 DF? Or to be more specific, 23.976fps counted at 24fps using DF timecode?
I've tried to get my brain to accept 23.98 means 23.976 NDF, but it keeps defaulting to expecting DF timecode. In principle, should 23.976 always be DF unless otherwise specified? I'm thinking that's why my brain won't reset and I kept confusing myself.

I'll play around some more tomorrow.

Cheers.

Edit:
Here's what Avisynth says for frame number 20,000:

30			00:11:06:20
29.97 NDF		00:11:06:20
29.97 DF		00:11:07:10
25			00:13:20:00
24			00:13:53:08
23.976 NDF		00:13:53:08
23.976 DF		00:13:54:04

I assume the TcCalc equivalents are these (minus 29.97 NDF)

NDF 30			00:11:06:20
DF 29.97		00:11:07:10
25			00:13:20:00
24	 		00:13:53:08
23.8 			00:13:53:08
23 TT			00:13:54:00

So if I've got that correct it's still the "23 TT" calculation I don't understand. At frame number 2,000 it's only 1 frame behind what Avisynth reports, but by frame 20,000 it's behind by 4.
I checked again and this calculator says 00:13:54:04 for frame 20,000.
http://www.zapstudio.net/framecalc/

Mind you I managed to compare NDF timecode with DF timecode so many times I've finally realised I'm mentally challenged, so maybe I'm still not looking at it correctly.

[James Brooks]

Not sure if you are meaning to, but you keep switching between 23.98 and 23.97. There is only one frame rate, 24.0/1.001, which some call 23.97 and other 23.98, but it all refers to 23.97602397602398. From there, you have
- broadcast 23.98/97, which is actually 24 fps
- drop frame 23.98/97, where frames are dropped at specific points to compensate for 0.999 difference
- actual 23.98, where frames are dropped randomly to most closely match the actual 23.97602397602398
TcCalc only supports type 1 and 2. Most 'exact' conversions actually use type 3.
I would say, if you are worried about actual duration, then type 2 and 3 should be within a frame or two. If you are going to be using an NLE, the you want to stick with type 1.
J

[Ennio]

According to the document I linked to, with NTSC a "10 minutes cadence" is applied to make up for 18 "dropped frames" per minute. Like every minute the first two frames, except every tenth, makes 9 x 2 = 18.

As the number of NTSC (29.97) frames are even at exactly 00:10:00:00, it makes one wonder why there wasn't agreed on a "9 frames each 5 minutes cadence". Is it because the amount of frames is odd at that point? You could do something like "2-2-2-2-1" every 5 minutes. Or has it something to do with the equipment of those days and the reason is more technical?

- drop frame 23.98/97, where frames are dropped at specific points to compensate for 0.999 difference

I'm wondering what cadence is used with 23.976? If my logics are correct, these 18 frames (running 24/30 slower) have to be dropped on a (10min x 30/24 =) 12.5 minutes period. Or 36 frames every 25 minutes, or... etc. Again, if I'm right... still a bit nooby with this.

[Ennio]

At the 20,000 frame mark, SMPTE would be about 0.2ms off..... I think.....

If you rounded off 0.167ms, I'd say you're right, hello_hello. And given that 00:13:54:04 is the right DF timecode.

If I understand it correctly, the "13:54" in DF 00:13:54:04 timecode is not exactly 13 minutes and 54 minutes. Of course, reading these values, we calculate with them.
Therefore, the difference with real time (real time minus DF time) would give me

834.166666666 - (834 + 4 x (1001/24000) = 0.00016673sec = 0.167ms.

where

834.16666666 is the real time

834 are the seconds taken from the "13:54" part of the DF timecode ((13 x 60) + 54)

4 is the last frames in the DF timecode

1001/24000 being the running time of a frame

Of course, this is given that 00:13:54:04 is the right DF timecode. Which I doubt. The "23TT" window of the TCCalc tool gives 00:13:54:00. So, there is a difference. Maybe it's lying in the cadence, which of course cannot be the same as with NTSC.

Again, I hope I'm right with the numbers.

[hello_hello]

James,
I used 23.8 and 23 TT because those are the TcCalc options, but I assume it all means 23.976 fps.

- broadcast 23.98/97, which is actually 24 fps
- drop frame 23.98/97, where frames are dropped at specific points to compensate for 0.999 difference
- actual 23.98, where frames are dropped randomly to most closely match the actual 23.97602397602398

I'm still confused.
Originally I thought you said TcCalc's 23.8 was following the Sony convention of using non drop frame timecode similar to 29.97 NDF, which I interpreted as 23.976 NDF, and as far as I can tell that's what it is, and I took "23 TT calculated with frame dropping" to mean it'd be 23.976 DF. I don't understand the distinction between random frame dropping and specific frame dropping.

Maybe I'm just stuck thinking the way Avisynth does, where 23.975 fps – 23.977 fps is assumed to be 23.976 and DF timecode is used, but that's why I'm trying to clarify the rate at which TcCalc counts the frames for "23 TT", and whether it outputs 24000/1001 DF timecode, because a difference of 168ms by frame #20,000 (four frames) compared to what I assume would be standard 23.976 DF timecode, seems to indicate it's doing something else for reasons I don't understand.

If you rounded off 0.167ms, I'd say you're right, hello_hello. And given that 00:13:54:04 is the right DF timecode.

Ennio,
I mightn't have been clear enough, but I was only referring to it being out by something like 0.2 ms. Rounding off to 834 seconds doesn't round off 0.167 ms, it rounds off 0.167 seconds, which is a lot rounding, if that's what you meant.

834 seconds, 166.6667 ms (real time at 24000/1001, if you don't round to a whole millisecond)
vs
834 seconds, 166.8333 ms (00:13:54:04 DF timecode, or 834 plus the duration of 4 frames at 24000/1001)

Avisynth isn't very informative about the pattern used for 23.976 fps.
http://avisynth.nl/index.php/ShowFrameNumber#Drop-Frame_versus_Non-Drop-Frame_Time_Code
I don't know if there's a standard one, but if you'd care to go pattern hunting, here's a couple of Avisynth clips displaying each flavour of timecode for you.

[Ennio]

Thank you for the clips, hello_hello. Can you show me how you do this in AviSynth? I am terrible with cli.

[hello_hello]

Do you use Avisynth at all?

If not, to get you started, install Avisynth+ and copy the following into Notepad and save it with an avs extension. Name it whatever you like.

BlankClip().killaudio().Loop(1000)
ConvertToYV12()
AssumeFPS(24000,1001)
ShowSMPTE()

You can change the frame rate in the AssumeFPS line and re-open the script, but it should work in anything that'll open therm (MPC-HC, VirtualDubMod2, AvspMod etc).

Once you've got that working, you can try the one below if you like. Unfortunately I wasn't expecting to share it, so it requires bits from a plugin and three other functions, which in turn mostly use built-in Avisynth functions. The TimeCodes() function is the one cobbling it all together. I added some stuff so it'll only try displaying DF timecodes when it's supposed to, and it'll tell you why when it isn't. Hopefully that's working properly. There's no options for configuring the TimeCodes() function (yet), but there's probably not much need anyway.

LoadPlugin("grunt.dll")
Import("Subtitle2.avs")
Import("Position.avs")
Import("TimeCodes.avs")

BlankClip().killaudio().Loop(1000)
ConvertToYV12()

AssumeFPS(24000,1001)

TimeCodes()

Grunt.dll can be found in the zip file here: https://github.com/pinterf/GRunT/releases
The three functions are in a zip file attached below.
Don't mix 32 bit and 64 bit. You want to install the 32 bit version of Avisynth, open scripts with 32 bit VirtualDub, and use grunt.dll from the x86 folder in the zip file etc. Or use 64 bit versions of everything.
If you put the files in the same folder that should work as- is, otherwise you'll probably need to specify full paths.

Import("D:\Some Folder\Another Folder\TimeCodes.avs")

Anyway, put the avs files and grunt.dll in the same folder, copy the above into Notepad and save it with an avs extension to the same location (t doesn't matter what you name it), then try opening it with Virtualdub or something......

That should get you started without too much trouble. The timecodes are displayed over a blank clip, but you can add the function to a script decoding video the same way. Sorry if I've been stating the obvious at you, but I'm not sure if you're an Avisynth user.

Edit: To be clear.... install Avisynth+, not classic Avisynth. The latter has been abandoned.
https://www.videohelp.com/software/AviSynth-Plus

[Ennio]

Do you use Avisynth at all?

I was not completely oblivous and unfamiliar with Avisynth.
Of course viewing scripts in notepad gives one an idea. Not even scratching the surface, I have been able to type a few simple scripts myself for basic needs such as cropping, framerate-change etc.

Thanks for your elaborate explanation, links and scripts.