Skip to main content
Inspiring
August 21, 2023
Answered

Premiere Pro 2023 Breaks Media Start Metadata

  • August 21, 2023
  • 1 reply
  • 1007 views

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! 😅

This topic has been closed for replies.

1 reply

R Neil Haugen
Legend
August 21, 2023

Maybe @Matt_Stegner might be of help?

Everyone's mileage always varies ...
MyerPj
Community Expert
MyerPjCommunity ExpertCorrect answer
Community Expert
August 21, 2023
Inspiring
August 21, 2023

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.