• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Comp.displayStartTime - inconsistencies between seconds and hh:mm:ss:ff

Enthusiast ,
Dec 05, 2019 Dec 05, 2019

Copy link to clipboard

Copied

I've got a Comp with a start time of 1:00:03:20 / fps 23.976 (according to the Composition Settings dialog box)
Extendscript's Comp.displayStartTime property shows that in seconds as 3607.4772689356
 
Per my calc 1:00:03:20 at 23.976 converts to 3603.834167500834
Calc would be (from H:M:S:F of 1:00:03:20)

 

H=1;
M=0;
S=3;
F=20;
SecondsShouldBe=(H*60*60) + (M*60) + S + (F/23.976); //3603.834167500834

 

That's a discrepancy of over 3 1/2 secs.
Am I misunderstanding something?
TOPICS
Error or problem , Scripting

Views

1.5K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Dec 05, 2019 Dec 05, 2019

Copy link to clipboard

Copied

Is the footage also at 23.976 frames/sec? 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 05, 2019 Dec 05, 2019

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 05, 2019 Dec 05, 2019

Copy link to clipboard

Copied

Drop frame vs. non drop frame?

 

Dan

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 05, 2019 Dec 05, 2019

Copy link to clipboard

Copied

Hi Dan,

 

Effectively NDF, but there's really no such distinction in the land of 23.976.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 05, 2019 Dec 05, 2019

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 05, 2019 Dec 05, 2019

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 05, 2019 Dec 05, 2019

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 05, 2019 Dec 05, 2019

Copy link to clipboard

Copied

->

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 13, 2019 Dec 13, 2019

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Dec 13, 2019 Dec 13, 2019

Copy link to clipboard

Copied

LATEST

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

 

 

 

 

 

 

 

 

 

 

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines