InsertClip adding strange offset in audio-only track-item for a particular audio file.

Report · Mar 11, 2024

Goal:

Using PP-Scripting Clone a subsequence (created using Sequence.createSubsequence()) in its raw clips form to create a target sequence. Multiple subsequences will be used to create the complete target sequence without using subsequences to avoid nested sequences.

Scenario:

Multiple cameras are used for footage, while their audios are not used. Audios are sourced from separate audio recording devices.
Adobe Premiere Pro 2024 (Version 24.2.1) Build 2
Windows 10

Method Adopted:

Looped over each video track in the source. Copied each clip and inserted it into the target, similar to the source, using insertClip(). Removed its audio part. Then, looped over each audio track in the source. Inserted each audio clip into the target, similar to the source.

Problem:

This worked fine for video tracks. However, for audio tracks, the first track clip (Track 2) with the Audio Item (Tr2.wav) seems to get inserted with an offset. The original subsequence had Track 2 at 0 ticks. Inserting it in the Target Sequence at 0 ticks yields a clip with a few seconds offset.

Important Note:
- The problem does not occur when a .prproj file is downgraded for opening in Premiere Pro 2023 and saved. Processing this saved .prproj file, even with Premiere Pro 2024, yields the expected result (clip insertion at specified start time-ticks).

Comments:

I am not sure if this is a bug in Premiere Pro 2024, a problem in the approach used, or some error in the code. Maybe I forgot a terminator 😄

Code: (For audio-tracks cloning portion)

    // Loop through each audio track in the source sequence
    for (var i = 0; i < src_seq.audioTracks.numTracks; i++) {
        var audioTrack = src_seq.audioTracks[i];
        var targetAudioTrack = target_seq.audioTracks[i];

        var clipOffset = 0; // Initialize clip offset

        // Process each clip in the current audio track
        for (var j = 0; j < audioTrack.clips.numItems; j++) {
            var clip = audioTrack.clips[j];
            var clip_projectItem = clip.projectItem;

            var inPoint = clip.inPoint;
            var outPoint = clip.outPoint;
            var clipDuration = clip.end.ticks - clip.start.ticks; // Duration in ticks

            var newClipStartTime = lastEndTime + clipOffset; // Calculate new start time

            targetAudioTrack.insertClip(clip_projectItem, String(newClipStartTime));            
            
            var targetClipIndex = targetAudioTrack.clips.numItems - 1;
            var targetClip = targetAudioTrack.clips[targetClipIndex];

            var curr_end_sec = tick_to_sec(newClipStartTime + clipDuration);

            // Set the in and out points for the target clip
            targetClip.inPoint = inPoint;
            targetClip.outPoint = outPoint;
            targetClip.end = curr_end_sec; // Adjust the end time

            targetClip.disabled = clip.disabled; // Copy the disabled state

            clipOffset = clipDuration; // Update clip offset for the next iteration

        }
    }

Report · Mar 14, 2024

Nice details; we'll have a look.

Is there a possibility that the offset, is the result of PPro moving to a frame boundary?

>The problem does not occur when a .prproj file is downgraded for opening in Premiere Pro 2023 and saved

How are you performing that downgrade?

Report · Mar 14, 2024

Hey Bruce,

Thanks for responding. I am not sure what you mean by,

Is there a possibility that the offset, is the result of PPro moving to a frame boundary?

The downgrade was done simply by opening the saved .prproj using Premier. Pro 2023. It gives the dialogue that it seems the . prproj was saved using a newer version of Premier pro and proceeds to save a downgraded version to be able to open it with Premier Pro 2023. This new .prproj is saved with I think a subscript of ._1.prproj.

Report · Mar 14, 2024

My untested theory was that PPro may have been creating that offset, to align with frame boundaries within that sequence .

And yes, I just wanted to make sure you weren't using some dodgy 3rd party utility to downgrade the .prproj.

Report · Mar 20, 2024

My untested theory was that PPro may have been creating that offset, to align with frame boundaries within that sequence .

For context: Problem was that the trackitem being inserted using insertClip using a source ProjectItem and a start time doesnot get place in the expected start time. (which is 0 seconds in this case)

I ran some tests to try to isolate the source of the problem.

The problem occurs in the following cases
a) Original Sequence that has some effects applied on the audio and have been processed by autopod extension
b) New created sequence in the same .prproj where we simply drag and drop the same media from Projects Window. But as we are getting from Project Window. No cuts/extension have been applied

The problem didnot occur when,
a) A new vanilla prproj is created and the same media is imported to create the sequence similar to the new created sequence in the previous case. (This time again no cuts/extension applied)

| Sharing here the result of each test. |
1. Original prproj + timeline
a) Track1 Audio Insertion at 0 sec - 0 ticks

b) Track2 Audio Insertion at 0 sec - 0 ticks

2. Orig Prproj but new timeline with same media imported from Project Window
a) Track1 Audio Insertion at 0 sec - 0 ticks

b) Track2 Audio Insertion at 0 sec - 0 ticks

3. Vanilla prproj created with same media imported from disk to create timeline.
a) Track1 Audio Insertion at 0 sec - 0 ticks

b) Track2 Audio Insertion at 0 sec - 0 ticks

4. Vanilla prproj (with source ProjectItem InPoint for both audio manually set to 200 sec for testing)
a) Track1 Audio Insertion at 0 sec - 0 ticks

b) Track2 Audio Insertion at 0 sec - 0 ticks

Related Content:
- For more information, I am attaching here the following
1) Effect_controls window of problem sequence for both audio tracks in the original .prproj.
2) Exported XML of the Problem Sequence for deeper look of the files.

Report · Mar 20, 2024

Related Content:
- For more information, I am attaching here the following
1) Effect_controls window of problem sequence for both audio tracks in the original .prproj.
2) Exported XML of the Problem Sequence for deeper look of the files.

Report · Mar 21, 2024

@Bruce Bullis Kindly have a look if you can. I have been stuck on this for a while.

Report · Mar 21, 2024

Will do...

Report · Mar 22, 2024

You said:

The problem occurs in the following cases
a) Original Sequence that has some effects applied on the audio and have been processed by autopod extension
b) New created sequence in the same .prproj where we simply drag and drop the same media from Projects Window. But as we are getting from Project Window. No cuts/extension have been applied

In those cases, had speed changes or time remapping been applied? If so...those changes (in the effects layer) will not be reflected in the trackItem in/outs, or duration.

[I presume you're already accounting for the sequence's start time offset (Sequence.zeroPoint), and projectItem.startTime...?]

Also, because you're passing the time as a String, this line will always introduce rounding error from 'timecode' (frames) to ticks:

targetAudioTrack.insertClip(clip_projectItem, String(newClipStartTime));

Report · Mar 22, 2024

You said:

The problem occurs in the following cases
a) Original Sequence that has some effects applied on the audio and have been processed by autopod extension
b) New created sequence in the same .prproj where we simply drag and drop the same media from Projects Window. But as we are getting from Project Window. No cuts/extension have been applied

In those cases, had speed changes or time remapping been applied? If so...those changes (in the effects layer) will not be reflected in the trackItem in/outs, or duration.

I have shared the effect controls window and Exported XML of both audio tracks. You can see there is no speed changes or time remapping applied.

[I presume you're already accounting for the sequence's start time offset (Sequence.zeroPoint), and projectItem.startTime...?]

I didn’t account of the zeroPoint before. Does it affect all tracks or one track specifically. Here, Offset is only see in audio on Track2 (TR2.WAV) when using insertCLip.
- Src Sequence ZeroPoint (secs) = 178.79
- Target Sequence ZeroPoint (secs) = 0
This value doesnot match the offset (145.95) seen in Track 2, the only place it occurs.
Can you explain how do we account for projectItem.startTime. I have it printed for each audio and its a very large number. (42987 secs) I thought insertion location of any clip is determined by ‘start_time’ as the 2nd argument of InsertClip. How does ProjectItem.startTime factor into this?
- Also, this is the first clip i am inserting in Target Sequence (Audio-Track2) and insertion (start-time) is 0 sec or ‘0’ ticks. So it should be inserted right at the start.

Also, because you're passing the time as a String, this line will always introduce rounding error from 'timecode' (frames) to ticks:

targetAudioTrack.insertClip(clip_projectItem, String(newClipStartTime));

Rounding error would be 1 frame? I am getting 146 sec of offset which surely cannot be said as a rounding problem.

One pattern that i found was the clips that show an insertClip offset from the starttime specified, have their respective projectItem inPoint different/modified (meaning non-zero)

Video 1 (Untitled_CAM_1.MP4)
Audio 2 (Tr2.WAV)

Report · Mar 30, 2024

Possible Bug?

Report · Apr 01, 2024

I spent some time looking into this; I don't think there's any way to see the behavior you're seeing, without the actual .prproj and media in use.

I see no issues with the .xml, referring to ZOOM0004_Tr1.WAV...but I don't have any steps to follow. 🙂

The code snippet you sent won't run; lastEndTime doesn't exist, and clipOffset doesn't accumulate offset, it just resets it to the duration of the most recently encountered trackItem.

Why do you find it desireable to use a timecode string, rather than a (much more precise) Time value, to set the insertion time?

The two cases in which you said the problem occurred:

When effects have already been applied : Yep, guaranteed to have non-accessible time change values, and...
...projectItems can also have speed changes applied.

Again, with an actual .prproj and media that replicates the failure case, I might get further, but there's not much I can do with the code and partial info available.