Premiere Pro 2023 Breaks Media Start Metadata

[Caleb Vetter]

I have a CEP plugin I've written that relies on the Media Start timecode of clips selected in the Project/Bin. It was just brought to my attention that audio wasn't using the correct timecode in my plugin. I did some digging, trying to solve what had changed, but it turns out that Premiere Pro 2023 doesn't have the correct Media Start timecode in its Metadata.

You actually don't even have to dig into code to see this. To reproduce, import an audio clip that has timecode. Open the Metadata pane and select the audio clip in the Project pane. You can see the Media Start in the Project pane is correct, while the Media Start in the Metadata pane is incorrect.

In code, when calling getProjectMetadata(), getProjectColumnsMetadata(), or startTime() on a ProjectItem, you get the same incorrect result (shown in the Metadata pane).

Here are some screenshots showing the descrepancy in timecodes.

Premiere Pro 2022

Premiere Pro 2023

Hopefully I'm not missing something dumb here! 😅

[R Neil Haugen]

Maybe @Matt_Stegner might be of help?

[MyerPj · Accepted solution]

I think we covered this recently:

https://community.adobe.com/t5/premiere-pro-discussions/importing-wav-results-in-incorrect-timecode-...

[Caleb Vetter]

So after a little trial and error math, it seems the discrepancy is the difference in hz/fps. For example 60hz = 59.94fps (or more exact: 60 / 1.001). This value, per the NTSC standard.

When examining the metadata xml, I see this:

<premierePrivateProjectMetaData:Column.Intrinsic.VideoInPoint rdf:parseType="Resource">
  <rdf:value/>
  <premierePrivateProjectMetaData:min>0</premierePrivateProjectMetaData:min>
  <premierePrivateProjectMetaData:max>-101606410594584000</premierePrivateProjectMetaData:max>
  <premierePrivateProjectMetaData:offset>3282371636544000</premierePrivateProjectMetaData:offset>
  <premierePrivateProjectMetaData:time_display>110</premierePrivateProjectMetaData:time_display>
  <premierePrivateProjectMetaData:frame_rate>10594584000</premierePrivateProjectMetaData:frame_rate>
</premierePrivateProjectMetaData:Column.Intrinsic.VideoInPoint>
<premierePrivateProjectMetaData:Column.Intrinsic.VideoOutPoint rdf:parseType="Resource">
  <rdf:value/>
  <premierePrivateProjectMetaData:min>-101606389405416000</premierePrivateProjectMetaData:min>
  <premierePrivateProjectMetaData:max>18307441152000</premierePrivateProjectMetaData:max>
  <premierePrivateProjectMetaData:offset>3282371636544000</premierePrivateProjectMetaData:offset>
  <premierePrivateProjectMetaData:time_display>110</premierePrivateProjectMetaData:time_display>
  <premierePrivateProjectMetaData:frame_rate>10594584000</premierePrivateProjectMetaData:frame_rate>
</premierePrivateProjectMetaData:Column.Intrinsic.VideoOutPoint>

It seems the most reliable way to get the start and end times in seconds would be the metadata's 

VideoInPoint/VideoOutPoint > offset value, then devide it by the constant ticks per second. I say reliable because it's the same value in both Premiere Pro 2022 and Premiere Pro 2023.

But we're still stuck with how to know when to translate between the hz/fps (divide/multiple by 1.001). Is there a sure-fire way to know this? I thought about the frame_rate value in the xml and comparing it to the sequence frame rate (timebase) value, but theycould be wildly different if, for example, the sequence was 23.976fps and the media file is 60fps. So then is the only way to make a map of possible values to a true/false of hz/fps conversion?

23.976 => true

24.00 => false

29.97 => true

30.00 => false

12.50 => false??

etc...

And then, bonus question 🙂 Why did the Media Start/Media End metadata calculations change between v2022 and v2023? It seems like a high-level data point that should be left to what people expect to find, and if you need that granular detail, you dig into the metadata further.

[MyerPj]

My guess is you should post over on the other thread, you've got 3 Adobe employees who have posted on it. Also, check the third thread on the bottom of the linked thread:

The thread with 3 employees:

Solved: Re: Importing WAV results in incorrect timecode an... - Adobe Support Community - 10863937

And a thread that one refers to:

Re: Discuss: New Metadata & Timecode Burn-in effec... - Page 2 - Adobe Support Community - 11972661

[R Neil Haugen]

Reading a book on video post, high-end stuff. There, it's noted that there are differences in computation for framerates & audio files depending on the specific framerate of the files. And that you cannot normally use dividing by the 23.976 or whatever numbers, for anything but a few frames, without getting drift. So they say all computations must use the full say 60/1.001 type calculations. Just as your post tells us.

What a ... joy.