Copy link to clipboard
Copied
H=1;
M=0;
S=3;
F=20;
SecondsShouldBe=(H*60*60) + (M*60) + S + (F/23.976); //3603.834167500834
Copy link to clipboard
Copied
Is the footage also at 23.976 frames/sec?
Copy link to clipboard
Copied
Hi Dave,
Yes, the source footage is also 23.976. In fact, the Comp was created by "New Comp from Selection", so it contains only one source / AV Layer. The start TC and frame rate are inherited from the start TC of the original source clip., so the Comp and source footage TC and frame rates match exactly.
Copy link to clipboard
Copied
Drop frame vs. non drop frame?
Dan
Copy link to clipboard
Copied
Hi Dan,
Effectively NDF, but there's really no such distinction in the land of 23.976.
Copy link to clipboard
Copied
I'm no expert, but the reason I mentioned it is that a quick calculation showed that the discrepancy between 23.976 and 24 over that period of time would be about 3.6 seconds, which seems to match your results. Just a thought...
Dan
Copy link to clipboard
Copied
Oh, good call. I wonder if AE calculates the seconds based not on 23.976 but 24, even when it knows the frame duration is 1 / 23.976
I'll play with that as soon as I have a moment free.
Copy link to clipboard
Copied
Your math is flawed. You have to count frames when the frame rate is not a whole number. Footage that is one hour, three seconds and twenty frames would contain 86492 frames.
One frame lasts for 0.033366700033367 seconds (1/23.0976). Multiply that by 86492 frames and you get 3607.440774107440774 seconds.
That is exactly what the Extended script reports.
The difference between the fractional part of a frame that doesn't make up an even second is where the problem lies. The error is cumulative and that accounts for the three-and-a half-second error in your calculations. You have to count frames then multiply them by the frame duration. That is the only way to accurately turn a frame rate that is not a whole number into hours, minutes and seconds.
It was easy for me to figure this out because when I started in this business in 1969 and we shot 16mm and 35mm film at 24 fps and had to put it on TV using 3:2 pull down to get the frames to match interlaced TV at 29.967 fps. I hated editing when I had to cut on those blended frames where the even scan lines were from one frame and the odd ones were from another. In 1974 I worked with a man named Clive Tobin who was developing crystal motors. We put one on my film camera that would run at 29.97 fps so we could run the telecine at 29.97 and avoid the dreaded 3:2 pulldown. A bunch of major advertising agencies loved my work because my film looked better than anyone else and I got a lot of DP and editing work and I won a bunch of awards. That is when I learned you have to count frames and multiply the total number of frames by the frame duration to get seconds that you could turn into hours, minutes, seconds and frames. I never forgot.
Copy link to clipboard
Copied
->
Copy link to clipboard
Copied
Rick_Gerard, somehow I missed your story about counting frames and the 'dreaded 3:2' pulldown. Thanks for sharing! -- the harrowing hours and painfully esoteric details are painfully familiar. The first time I encountered it I was a student. I'd shot on film at 24fps but edited on video. When later I tried to conform the film, I sat there with a calculator endlessly wondering why I was always a frame or two off. I'd never heard of 29.97.
I think in this case the difference of opinion is here:
"you have to count frames and multiply the total number of frames by the frame duration to get seconds"
Because we're working in a 23.976 Comp, our actual frame duration is not the 0.033366700033367 (1 / 29.97) that you point out but 0.04170837504170838 (1 / 23.976)
Also, you mention "the fractional part of a frame that doesn't make up an even second"
But in ExtendScript we're working not with even seconds but fractional seconds.
So I think that in this case the After Effects ExtendScript method Comp.displayStartTime() does indeed miscalculate, because it presumes the 0.033366700033367 frame duration even for 23.976 Comps.
There's another method Comp.frameDuration() which accurately returns 0.04170837504170838 for 23.976 Comps
In other words, AE 'knows' the proper frame duration, but the Comp.displayStartTime() nonetheless calculates a 0.033366700033367 when converting the entry in the "Composition Settings" dialogue to the ExtendScript context.
Happy to be proven wrong on this, but I think there really is an error on Adobe's side.
Copy link to clipboard
Copied
Rick_Gerard -- I take it back. You were right and so is Adobe. There were a few typos in your post which, along with my screwed-up logic, threw me.
The typos:
"0.033366700033367 seconds (1/23.0976)"
It's 1/23.976 (not 1/23.0976), and the result of that is 0.04170837504170838, (not 0.033366700033367, which is 1/29.97)
The typos don't matter much. Your overall logic is spot on.
Maybe this helps for clarification purposes
If we're looking at TC (say 1:00:03:20) that's 29.97fps drop-frame TC or 24fps or even 25fps, you can actually trust that the hh:mm:ss:ff are all accurate values.
But that same TC represented in a 29.97fps non-drop TC or 23.976fps, then the hh:mm:ss:ff are not accurate to real world time, and that inaccuracy represents the cummulative offset that you and others have pointed out. So the equation I originally posted is inaccurate in that way.
Here's another way of stating what you did. LMK if I've got it right yet.
//Assuming hh:mm:ss:ff of 01:00:03:20
H=1;
M=0;
S=3;
F=20;
//for 23.976
FpsApparent=24;
FpsActual=23.976;
Secs=((H*60*60*FpsApparent) + (M*60*FpsApparent) + (S*FpsApparent) + (F)) / FpsActual;
//for 29.97ndftc
FpsApparent=30;
FpsActual=29.97;
Secs=((H*60*60*FpsApparent) + (M*60*FpsApparent) + (S*FpsApparent) + (F)) / FpsActual;
//for all others it's more wysiwyg
Fps=29.97; //dftc, not ndftc. Also for 24fps or 25fps
Secs=((H*60*60) + (M*60) + (S) + (F/Fps));