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

Inconsistent values for created clips using ExtendScript

Community Beginner ,
Jul 05, 2024 Jul 05, 2024

Copy link to clipboard

Copied

I'm creating a subclip for a project item called mediaFile using the following call:

 

var clip = mediaFile.createSubClip(

              mediaFile.name,

              startTime,

              endTime,

              0 /*hasHardBoundaries*/,

              1 /*takeVideo*/,

              1 /*takeAudio*/

            );

 

The startTime resolves to 0 seconds and endTime is calculated as follows:

 

var endTime = new Time();

endTime.setSecondsAsFraction(

    (entryPoint + duration) * editRate[1],

    editRate[0]

);

 

where:

entryPoint = 0

duration = 43081 // this is the desired frame count for the clip.

editRate[0] = 1001

editRate[1] = 60000

 

The edit rate of this clip is 59.94fps

 

When I print out the out point of the clip

$.writeln(

"clip.getOutPoint().seconds: " + clip.getOutPoint().seconds

);

 

I get

clip.getOutPoint().seconds: 718.9182

 

however when I manually calculate the expected time:

$.writeln("calculatedEndTime: " +

((entryPoint + duration) * editRate[1]) / editRate[0]

);

 

I get:

calculatedEndTime: 718.734683333333

 

and the problem is that I''m using the time in seconds to do some other calculations that are now getting thrown off.

 

Furthermore, when I simply print out the value of endTime:

$.writeln("endTime.seconds: " + endTime.seconds);

 

I get:

 

endTime.seconds: -491.605352577101

 

which is not at all what I was expecting.

 

I've some a similar thing with 24fps content and I don't get encounter any problems.

 

What am I missing here?

TOPICS
SDK

Views

3.9K

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

correct answers 1 Correct answer

Community Beginner , Jul 11, 2024 Jul 11, 2024

Ooops my bad. I transcribed the edit rate values backwards. They should read:

editRate[0] = 60000

editRate[1] = 1001
The calculations should be correct with those values.

Votes

Translate

Translate

correct answers 1 Pinned Reply

Adobe Employee , Jul 11, 2024 Jul 11, 2024

Hello @M42,

Thanks for writing in with your bug report. Is your issue solved now? Please let us know, so I can mark your answer as correct or have a team member intercede here.

 

Thanks,

Kevin

Votes

Translate

Translate
Community Beginner ,
Jul 11, 2024 Jul 11, 2024

Copy link to clipboard

Copied

Ooops my bad. I transcribed the edit rate values backwards. They should read:

editRate[0] = 60000

editRate[1] = 1001
The calculations should be correct with those values.

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
Adobe Employee ,
Jul 11, 2024 Jul 11, 2024

Copy link to clipboard

Copied

Hello @M42,

Thanks for writing in with your bug report. Is your issue solved now? Please let us know, so I can mark your answer as correct or have a team member intercede here.

 

Thanks,

Kevin

Kevin Monahan - Sr. Community & Engagement Strategist – Pro Video and Audio

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 Beginner ,
Jul 11, 2024 Jul 11, 2024

Copy link to clipboard

Copied

Unfortunately my bug still stands - I only updated my post to reflect more accurate information used in the calculations (I inadvertently transposed the editRate[0] and [1] values). So with the proper values set for editRate the calculations still come out different when using setSecondsAsFraction vs when trying to calculate "by hand".

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
Adobe Employee ,
Jul 12, 2024 Jul 12, 2024

Copy link to clipboard

Copied

LATEST

To avoid the vagaries of rounding issues when moving between timebases, timecode math is best performed in ticks; there are 254016000000 ticks per second.

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