Skip to main content
This topic has been closed for replies.
Correct answer Анастасия27146278egmh

It doesn't work anyway. The frame rate is the same everywhere. SRT to XML converting solved the problem. Thank you for your comment

2 replies

Stan Jones
Community Expert
Community Expert
November 15, 2022

That is odd.

 

The ending timecode of caption 318 and the beginning timecode of 319 are the same. The is the way PR exports timecodes that are right next to each other, and is read correctly by Youtube, for example. Other systems (Subtitle Edit, for example) flags this as an overlapping timecode. Since PR is combining these two captions, but with a bunch of space in between, I wonder if it is not reading this as invalid and ignoring the in between timecodes.

 

I can't get this to happen when I test a couple of different similar scenarios.

 

I'll suggest some tests.

 

Copy and edit the srt you are using so that the two timecodes 318/319 are not the same. Does that make a difference?

 

All milliseconds are not valid. For example, if you create srt using a frame rate of 29.97 drop frame and then put in a 24 fps sequence, some of the frames might be wrong. What was the frame used in aegisub? What is the framerate of the sequence in PR?

 

If you can't get this sorted, the workaround would be to split the combined captions. The timecodes look very close otherwise, so that might work?

 

Stan

 

Анастасия27146278egmhAuthorCorrect answer
Participant
November 17, 2022

It doesn't work anyway. The frame rate is the same everywhere. SRT to XML converting solved the problem. Thank you for your comment

Kevin-Monahan
Community Manager
Community Manager
November 17, 2022

Thanks so much for giving your solution to the problem, Анастасия. Have a great day today! 

 

Kevin

Kevin Monahan - Sr. Community and Engagement Strategist – Adobe Pro Video and Audio
Kevin-Monahan
Community Manager
Community Manager
November 15, 2022
Kevin Monahan - Sr. Community and Engagement Strategist – Adobe Pro Video and Audio