Program TC overlay displays incorrect timecode

[kristines23037864]

I imported shots with double-system audio recorded 32-bit float having jammed an FX6 from a MixPre6ii.  I can sync camera (with guide track) and audio clips in the timeline via TC with no problem.  Here's the oddity: Suddenly the TC overlay in the Program window displays incorrect TC for only the audio clips (up to a minute off), but PPro seems to read the proper TC because I can still sync clips using TC in the timeline.  Also, I had TC properly displayed in a couple of timelines, but when I went to another timeline and then back to the timelines that had correctly displayed the TC, they now also displayed incorrect TC, i.e. the display went bad in seconds.  I had correct TC displayed in these timelines for weeks until this anomaly occurred.  I know because I did a test shot shooting the display of the MixPre, which displayed the same TC as the PPro Program overlay.   I uninstalled and reinstalled PPro: same problem.  On another computer: same problem.  Is this PPro having problems with 32-bit float?  Something else?  [I'm on a trashcan Mac Pro, OS 12.6.6, PPro v23.5]  Thoughts?  Thanks

[Jonah27108818o0jq]

Same thing started happening with my system.  Any solutions?

[Greg Day]

Same issue here. Big hassle.
iMac Pro, OS 13.4.1, PPro 23.5.0

[R Neil Haugen]

@mstegner,are you in today? Not sure audio TC is within your purview  ...

[Tim Snider]

I'm experiencing this exact same problem on Premiere 23 and 24 on Windows.  I can sync via timecode and everything Syncs but when looking at the video and audio timecod e in the editing overlay (to confirm sync after a tricky edit) we discovered that the audio time code is off by over 40 seconds.  However, more research has concluded that it's not really off, if you click in the timeline and open the wavefile in the source window it shows that the audio has the exact same timecode as the video track reports in the overlay.  But the Audio overlay is diplaying a much later timecode then what it is actually at.   You can also tell this if you go to the beginging of a clip in a timeline.  The overlay shows you one timecode but when you look in the bin the actual start time is a completely different timecode.  This has made what should be a really easy fix (to correct some possibly slipped edits) into a really difficult task.  

[Tim Snider]

I would like to add that this behavior does not happen with Camera sourced Audio Tracks.  It only seems to be appearing on seperately imported audio files.  In our particular case that we are dealing with right now these are .wav files created by a SoundDevices Recording.  And as I mentioned yesterday, the timcode does seem to be read correctly as it will Sync correctly but the editing overlays display the wrong timecode.

@Fergus H Can you recoemed someone who might be able to help look into this with us?

[Tim Snider]

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.  

[R Neil Haugen]

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

[Tim Snider]

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. 

[R Neil Haugen]

Thanks, excellent image.

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

[Collin K]

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.

[Collin K]

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

[Steve28487991gcoy]

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!

[micahyo]

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.

[Collin K]

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.

[robbiemo82]

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?

[editbreath]

Did not work for me. 

Wav 5-channel recording in the field via a Sound Devices 664 as the master timecode source supplying 29.97 ndf timecode to Tentacle Sync Master Transmitter and 3 Tentacle Sync Camera Slaves.  In Premiere, the Program monitor overlay display does not match the timecode of the clip when matched to Source as others have reported. I have Preferences/Media/Indeterminate Media Timebase set to 29.97 fps Non-Drop Frame. My original source starts around the 10hr 20min mark and is about 38 seconds off. Premiere's create multi-cam source sequence syncs the wav file by timecode to the video clip perfectly, just displays the wrong time code in the overlay. This is good as far as it goes, but makes matching the audio to a random clip later nearly impossible. 

I deleted and re-imported the wav media file multiple times trying various permutations. When Indeterminate Media Timebase is set to 30 fps, then the display and the source timecode match, but Premiere can't sync by timecode--its off a few seconds--via the multicam sequence creation.

A large measure of persistence yielded the following WORKAROUND:

In a moment of digital desperation, I created a 5-channel sequence 29.97ndf, 48kHz and dropped in the field wav file, setting the sequence Start Time to match the wav file start timecode. Then I exported that same 5-channel sequence as a ProResProxy movie [black video] with 5-channel uncompressed audio tracks. When I reimported that ProResProxy video file and laid its audio tracks into a sequence, the overlay display and the source timecode matched. Yay! Premiere had no trouble using create multi-cam source sequence to match audio either. Now my audio tracks and original camera recordings' video tracks have matching timecode and I can edit as expected, save for having the extra step of creating new video movies from each wav audio file. Arggh. 

PPro 23.6.4

Mac 11.5.1 Big Sur

[mcx#5000]

That workaround worked for me for 29.97NDF timecode as well. 

[Kevin-Monahan]

The status of this bug report has been updated.

[Kevin-Monahan]

Hi kristines23037864,

I'm Kevin, one of the moderators here. You filed this bug over a year ago. Are you still experiencing this issue? Please let the community know.

Thanks,
Kevin

[Collin K]

I'm still experiencing incorrect time code showing in Overlays on the timeline as of last week.

[cmaikai]

I'm experiencing this bug at the moment. Very frustrating.

[ilivedinvegas]

I am also experiencing this bug in v24.5.0. The workarounds above do not work.

[kristines23037864]

Problem remains.  (I'm on v23; my trashcan MacPro can't upgrade to v24-- if that matters). 

[Kevin-Monahan]

Hello @kristines23037864,

Thanks very much for the response. I am so sorry that this issue remains for you.

Can anyone else on the thread @ilivedinvegas, @cmaikai, @Collin K, @mcx#5000,  verify that this bug is still occurring in 24.6 with its support for LTC timecode in audio tracks? Please let the devs know what you find. My apologies for this issue. I hope the team can address this issue soon.

Take Care,
Kevin

[mcx#5000]

Hi Kevin,

It looks like this might be fixed for me in 24.5. I don't have time for detailed testing now, but I just worked on a project that I believe had that problem previously with 24.3, and now the TC seemed to match. I can try more testing later if that'd be helpful.

-Jim