Program TC overlay displays incorrect timecode

the workaroundfrom below did the trick for me:

The workaround is two-part:

Set the "Indeterminate Timebase" preference to "23.976"

Leave all of your 23.976 WAV files set to "Default" under "Timebase Display Format".  DO NOT FORCE TO 23.976.

but is it fixed yet?

Hey! Thank you. I'm going to go back to your workaround when I need to compare timecode overlays with separate production audio on my next project.

Having the same issue here, and it's been a bug since Premiere Pro 2023.  We have a workaround at our place that seems to work.

The issue, in our case, happens when using WAV's recorded at 23.976. 

Premiere has a setting under "Preferences / Media / Indeterminate Media Timebase" which is, out of the box, set to "29.97 fps Drop-frame".   Under this default setting, the WAV files show up with 29.97DF timecode, which is useless, since the WAV timecode, as jammed to the camera, and according to the file's own metadata, is 23.976. 

(It's important to note that "Indeterminate Media Timebase" is a system-level preference rather than a project level setting, which means that the displayed timecode will change depending on what the system preferences are on the  machine opening the project each time.)

That being the case, our traditional workflow has always been to force the display timecode of the WAV files to the 23.976 setting by right clicking the clip(s) and setting "Modify / Timecode" and setting "Time Display Format" to  23.976. This has worked seamlessly.   Until Premiere 2023.

Since Premere 2023, forcing timecode display of the clip to 23.976 results in the issue described by others in this thread.  Timecode will look correct in the bin, but will show up incorrectly in the timeline.  What's happening here is that for some reaons the TIMELINE is showing the timecode interpreted at true 24fps rather than 23.976.  So, for WAV's with timecode close to 00:00:00:00, the difference is a few frames, getting gradually greater the closer the timecode of the clips gets to 23:59:59:23, where it'll be around 90 seconds off.

This issue is evident regardless of the "Indeterminate Media Timebase" preference mentioned above.  With this current bug, forcing 23.976 timecode display on a 23.976 WAV will ALWAYS show correct timecode in the bin and incorrect (24) timecode in the timeline.

The workaround is two-part:

Set the "Indeterminate Timebase" preference to "23.976"

Leave all of your 23.976 WAV files set to "Default" under "Timebase Display Format".  DO NOT FORCE TO 23.976.  Even though that's the appropriate setting, this triggers the bug.

The good news is that just applying the above workaround should fix any projects having this issue - you shouldn't need to start fresh with newly imported media or sequences.

Very interested to know if this works for others, and would love for Adobe to fix it.

Did this get solved in any recent builds? I'm still on 24.1 and try not to update during projects unless absolutely necessary. But this bug is frustrating. Thanks!

I'm also seeing the same incorrect audio timecode Overlay bug in PP 24.0 on a my other Mac Studio M2 Max.

I have the same exact issue. First time working in PP 23.6.2. On Mac Mini M2 Pro - Ventura OS 13.5. I'm attaching a screenshot that also shows the same issue; roughly off by :40 when using TC Overlays in the Program Monitor. I'm glad others are also speaking up about this bug or issue.

Thanks, excellent image.

@Fergus H or maybe even @WesHowellPPro  ...  any ideas what's happening here?

Here is a screenshot that I marked up to show the discrepency in the V1 and A1 overlays.  I've also highlighted the actual timecode which I achieved by clicking on the audio track in the timeline to open in the source window. 

Adding some screengrabs of the way this displays would be helpful ... 

One more note to add to this.  I just tried adding a transparent video layer over the timeline and then added a metadata/timecode effect to see what results I received from that way of looking at the timecode.  As expected, the Camera timecode is displayed correctly but the audio timecode is also displayed incorrectly when using this method as well.  It is very incorrect when I used the option of framerate from source and then when I select 24fps manually on the effect then it is still wrong but at least it then matches the incorrect overlay.  I then tried to offset the timecode effect to resolve the descrpency but adding all of the negative offset possible only got us within 10 seconds of the correct timecode.