Wrong timecodes when exporting SRT files (+36 sec.)

[zecarpio]

Hello there,

Am I the only one struggling with exporting SRT files with the wrong timecodes since Premiere Pro 2022 was released?

For example, on my timeline (starts at 10:00:00:00) the first caption arrives at 10:00:02:05 and when exporting this as an SRT file, the first caption arrives at 10:00:38,210 (PrPro added +36 sec to the timecodes). When I'm exporting the captions as a text file (.txt) I can see the right timecode. So, what's going on with the SRT output?

Here's a screenshot of the exported files (.srt vs .txt):

My version of Premiere Pro:

2.2.0 (Build 128)

My computer:

MacBook Pro (Apple M1 Max)

Memory 64 GB

macOS Monterey

version 12.1

Thank you in advance.

Best

[Mike Dziennik]

Can't replicate on my end.

What frame rate are you using? What happens if you select everything and copy/paste into a new sequence? Do they export with the offset?

[zecarpio]

Hi Mike,

The project is at 23,976 fps. And yes, I've tried to copy and paste into a new sequence but the problem is still there when exporting the SRT files. Though, the TXT files always seem to respect the timecodes from the sequences.

Thanks for your reply,

Best.

[Mike Dziennik]

Were the captions transcribed or created manually?

Is there only 1 subtitle track? 

[zecarpio]

Hi Mike,

They were created manually (from a .txt file that I've received with subtitles and timecodes).

There's only 1 subtitle track.

Thanks

[Stan Jones]

A screenshot of the text panel, timeline, and program monitor might help.

How are you getting a .txt file into PR? When I tested this, it showed .txt as an allowed filetype, but would not actually allow importing it.

Stan

[zecarpio]

Hi Stan,

Here's a screenshot of the project:

I am not importing the .txt into PrPro. I received the captions as a Word document. I am putting these manually into the project with the Text panel (Captions > Create new caption track > Format: Subtitle).

Thanks.

[Stan Jones]

Thanks!

I still cannot see anything that would account for this oddity. And I don't recall anyone reporting such an offset. There have been reports of other timecode issues, but those looked like framerate (the offset changed over time, and was very small at the beginning). And why would the text export be correct? There would have to be some kind of logic applied in the srt generation that would change its timecodes.

Quickest fix if this is really is a consistent 36 second offset: use Subtitle Edit or similar to adjust.

Alternative: use a different method to create the subtitles. For example, even though it is not exactly the same, see this re using Word files:

https://community.adobe.com/t5/premiere-pro-discussions/how-to-import-caption-txt-file-in-premiere-p...

More testing: Create a simple sequence with just the main video. Create a few captions. Export.

Stan

[zecarpio]

Hi Stan,

Thank you very much.

Have a good one!

[zecarpio]

Hello there,

It's been awhile and after a couple of updated Premiere Pro versions, I still have the same bug. Every time I export an SRT file from my sequence there's a gap of +36 seconds in the timestams.

I've tried to import subtitles from an SRT file, create them myself and use the automatic transcription. No matter what, they still output with a wrong timecode.

Anyone else experiencing this?

Img. Left (Premiere Pro sequence). Right (exported SRT file)

[Stan Jones · Accepted solution]

Still very odd. I don't recall anyone else (still) reporting this particular issue.

I did not ask before (and it should not matter, but....), how do you get the 10 hour offset? Sequence -> Start time, or what?

Did you use the simple sequence test I described before? Have you tried this without the offset?

@Kartika Rawat @Trent Happel Any thoughts?

Stan

[zecarpio]

Hi Stan,

Yes, I go through Sequence -> Start Time -> 10:00:00:00.

I guess I'll have to try to leave the sequence start at 00:00:00:00 and make an output.

I'll do this test tomorrow and I'll let you know what's coming out of it.

Thank you again.

[zecarpio]

Hi Stan,

You've nailed it! I've create a new sequence (00:00:00:00) without changing manually the start timecode.

I've copied and pasted the content from my other sequence (10:00:00:00). The exported SRT file doesn't have the +36sec gap!

It'd be interesting trying to recreate this bug on your end to see if it's an isolated case or if other people may struggle with it in the future.

Thank you again.

All the best.

[Stan Jones]

Yes, I'll give it a test. Thanks for reporting back.

Stan

[anthonyv40623992]

I have this issue, too.  Yesterday Premiere generated the correct timecodes but today it is off by about :05.  Very frustrating.  Will try duplicating sequence & see if it gets resolved.

[anthonyv40623992]

I am experiencing it too, although my gap is around :04 seconds.  

Any solutions out there?  It is so strange when certain bugs only affect some users and not others.

[zecarpio]

Hi Anthony, Did you check if your timecode on the sequence starts at 00:00:00:00? That was my problem, all of my sequences used to start at 10 O'clock (10:00:00:00) but when I came back at 00:00:00:00 now the .srt exports are fine.

[Stan Jones]

@zecarpio,

lol. I'd feel worse that I never did the test we discussed 11/3/22, but then I see that we had an earlier lull from 2/16/22! I'll still give us high marks for persistence.

In any event, I tested in PR Beta 24.1.0.2 and have now confirmed your finding that setting a start time results in an SRT export that is offset later by some amount. In my case, I set a start time of 10 hours, and the offset is about 25 seconds in a test clip that is 3:45 in duration. The first caption shows a start time in PR of 10:00:01:06, and the SRT export shows it at 10:00:26,976.

I plan to file a bug report in the Beta bug forum.

Stan

[Stan Jones]

Bug report here:

https://community.adobe.com/t5/premiere-pro-beta-bugs/nonzero-sequence-start-time-offsets-srt-timeco...

Stan

[cyphen]

I can confirm this issue with Premiere Pro 2022 on my box.

I did some math and it's mutiplying the correct numbers by 1001/1000 based on absolute frame number. That number might look familiat to video engineers.

I don't know if this is related to a setting somewhere, or why some people would have the problem and some wouldn't...

This is also happening with 2023 on my system.

Mac Pro Tower

3.2 GHz 16-Core Intel Xeon W

AMD Radeon PRO W6800X Duo 32 GB

192 GB 2933 MHz DDR4

OSX ver 13.3.1 (a)