Footage without existing fps metadata always uses 25fps timebase instead of one specified in audio timecode

[Aweinberg1]

When I update the timecode in Premiere with the CSV file from Tentacle Sync Timecode tool. It updates the timecode with the wrong timecode. The CSV file shows the correct timecode, it just does not update in Premiere Pro correctly. It does not use the file TC or Audio TC from the CVC. For example, File TC 21:49:39:22, Audio TC 21:49:39:21, Timecode it synced to in premiere after hitting start. 21:48:21:08

[Agrarvolution]

I haven't tested in Premiere for a long time, after I've discovered that the changes in Premiere are mostly non permanent, I moved my focus over to Bridge and directly changing the meta data. But can you provide what framerate the timecodes are in? Have you checked, whether the sync is also off by a minute? This kinda looks like an issue related to drop frame framerates. You might also want to check in what fps the TC is displayed, but that shouldn't make a difference in how the TC is handled by Premiere.

If all fails, you can always edit the XML metadata of your video files to fix that - it's basically what the Bridge version of this plugin does. The Premiere version is more error prone, since it basically converts the TC into frames and sets a new start time for that footage / project item.

I can't promise when I can look into that issue, since I barely have enough time to fix the bugs in the Bridge version.

[Aweinberg1]

The framerate the timecode is in is 23.976, I tried the Bridge extension and same problem. It updated and the Alternate Timecode showed the correct timecode in Bridge. However when I dragged the file from Bridge to Premiere the timecode was wrong. When using the Tentacle Sync Timecode tool and exporting out all my files with passthrough (and making duplicates of all my files), Premiere Pro sees the corect timecode and works as it should. The CSV file is also showing the correct data, before running the extension so I wonder where the metadata is getting messed up. Let me know if I can help in anyway or if I can provide sample files. Thanks, Alex

[Agrarvolution]

Thanks that's very insightful. What framerate is the timecode displayed in in Premiere? (You can check in the timecode panel.)

This might be an oversight on my side, since I've always tested with 25fps timecode from the tentacles with both 25fps and 30FPS DF timecodes of the footage. This one minute difference really looks like a conversion error. In the case of Bridge I might write the metadata wrong, but I'm not sure why Premiere is wrong too, since all it does is update the start frame count. 🤔

Have you tested if, when you sync your audio with video, the offset is wrong by that amount too? Because it might still work, despite Premiere displaying the frames in the wrong FPS format.

I remember encountering a similar issue in Bridge mixing 25fps and 29,97 fps, but it kinda "went away" by setting the correct metadata.

I will look into that in a few weeks.

[Aweinberg1]

In Premiere Pro the Time Display format is set as Use Default Time Display on the clip, but changing the setting to something else does not effect how it is displayed. The problem is definitely with the framerate. After I use the Bridge Extension or Premiere extesion same reults for both, If in Premiere I right click the clip and go to interpret Footage and change the clip's framerate to use 24 FPS instead of 23.976 it displays the timecode correct. However the clips are actually 23.976 so it does not sync properly just shows the correct media start time. The clips show the proper Frame Rate that they are in Premiere 23.976. The fix broken XMP time values in the Bridge plugin does not change the framerate as no matter what I set it to and click update the framerate shows the clips orginal framerate. So the disconnect in metadata is for sure in the frame rate as Alternate Timecode shows the correct start time that is misinterpreted in Premiere from the framerate.

Here you can download a couple test files I made that are 23.976 FPS with audio timecode https://we.tl/t-9KwtjR39iH

[Agrarvolution]

Ah thanks. Even better.

Yeah we will see what the error is.

The fix TC option only "re-adds" missing framerate metadata. This sometimes happened to me while testing that I had to bulk change the metadata framerate to fix a timecode. This bug seems unrelated to that. Since the timecode update doesn't change the framerate metadata.

On another note - did you have a performance hit when you bulk updated a lot of files in the bridge plugin? Cause I want to try and make it less process blocking in a future update. (Especially on slow computers I noticed that reading the metadata can be rather slow and Bridge freezes until the process is finished.)

[Agrarvolution]

I've just taken a quick look. 005.mp4 was changed by my plugin, but it set that the timecode-fps to 25fps for some reason. Since your footage doesn't contain original timecode, the plugin added that part. Why do I think this happens? I default assume 25fps, when I don't know the fps. The plugin might not read the metadata for footage fps the correctly here, and thus the code goes to defaults. Additionally I don't assume the footage fps from the timecode source, because otherwise you can't mix framerates with one timecode source.

This is what is wrong: (also the timecode is corrected for 25fps because of that) <xmpDM:timeFormat>25Timecode</xmpDM:timeFormat>

These are the parts where you can infere the fps: 004.mp4

         <xmpDM:startTimeScale>23000</xmpDM:startTimeScale>
         <xmpDM:startTimeSampleSize>1001</xmpDM:startTimeSampleSize>

005.mp4

         <xmpDM:startTimeScale>12800</xmpDM:startTimeScale>
         <xmpDM:startTimeSampleSize>512</xmpDM:startTimeSampleSize>

I'm not sure if Premiere wrote those into the files, but both are wrong.

I've tested something similar with audio files without timecode, but they work differently. That's why I've added the Fix TC option, which now in hindsight should be renamed to "Change Timecode FPS".

I guess the easiest fix would be to just use the fps provided by the audio timecode as default if default timecodes / fps are missing. But I have to take a closer look, when I have more time again.

[Aweinberg1]

I haven't had a performance hit, but I have a really strong computer 24 core processor and 256 gigs of RAM. Using the fps provided by the audio timecode could work.

LTC Convert (AUXTC) which I don’t have a license for but a demo version can be downloaded for free from: https://www.videotoolshed.com/product/ltc-convert-auxtc/ the only restriction of the demo is you can only work with 2 clips. They have the option to pick the LTC FPS.

I don't know if that is a better option than what you suggested, but being able to select the default timecode FPS could be a good idea if the FPS is missing from the file. Then the correct FPS would be added if it is missing from the file.

[Agrarvolution]

I will let you know, when I try to fix it. Current pace it, that I try to get that done over Christmas.

[Aweinberg1]

Sounds good, appreciate it!

On Sun, Dec 10, 2023, 2:17 PM Agrarvolution @.***> wrote:

I will let you know, when I try to fix it. Current pace it, that I try to get that done over Christmas.

— Reply to this email directly, view it on GitHub https://github.com/Agrarvolution/com.agrarvolution.autotimecodecorrection/issues/1#issuecomment-1849104329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS3UABELT7PVCIYBWYPHA3TYIYYIFAVCNFSM6AAAAABANTYZ7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBZGEYDIMZSHE . You are receiving this because you authored the thread.Message ID: <Agrarvolution/com.agrarvolution. @.***>

[Agrarvolution]

I just updated the program. I was working on and off on it since Christmas. I waited pushing updates here until I was somewhat certain that it doesn't do anything destructive. Your issue might be solved now. The plugin now assumes the framerate of the csv file when the media file doesn't have it set in its metadata or you can now override the fps.

The repair stuff is moved to a separate panel. These might not work currently.