Skip to main content
J
JARedmondWA
Inspiring
October 9, 2022
Question

Timing a bit off in an imported .srt file

  • October 9, 2022
  • 1 reply
  • 2129 views

Apologies in advance if there's already an answer to my question (I did search).

 

If I import an .srt file into a video, often the precise time of a text block is off by a small amount. 

 

Let me make this concrete. I exported an .srt from a video. Then I deleted the captions track from the video and cleared the .srt frm the Project panel. Finally, I imported the exported .srt file. But ... very often the times of the imported .srt are off from what was true in the .srt file. For example, text block #4 of the import begins at 00:11:38,950, but in the .srt file, text block #4 begins at 00:11:38,966.

 

A small difference, but it happens often (maybe 33% of the time). It makes a mess when there's a burnt-in caption (German, in this case) and I wish my own caption (English) to appear at precisely the same moment as the burnt-in caption. If a caption in one language appears at a different moment from the corresponding caption in the other language, the experience when watching on a big TV is unsatisfactory.

 

The video (created by Premiere Pro) is an 3840x2160 .mp4 file. Codec is MP4/MOV H.264 4:2:0. Framerate is 60.00. Audio is 48000 Hz, compressed stereo, 32-bit floating point.

    1 reply

    Stan Jones
    Community Expert
    Stan JonesCommunity Expert
    Community Expert
    October 20, 2022

    Sorry you did not get a timely response on this. I did play with the milliseconds, but could not see any logic to the differences without more information. But since I couldn't see any logic, I didn't know what to ask! Other than version of PR, which probably doesn't matter as long as it is the new caption workflow.

     

    I think I got stuck with the exact 60 framerate not making sense of the 966 - 950 is 57 frames exactly. I would look at sequence settings, method of srt import.

     

    Stan

     

    J
    JARedmondWAAuthor
    Inspiring
    October 24, 2022

    I discovered something: It appears (in my single experiment) that PP takes a caption block's millisecond time (that is, xx:xx:xx,mmm), divides that value by 1000, multiplies the result by the framerate and rounds down. Always down.

     

    For example, in an SRT file that I've been using, the timing values of a certain caption block are '00:12:30,683 --> 00:12:41,900' . When PP imports the SRT, the first step is apparently to convert the 683 milliseconds to 0.683 and multiply that by my video's framerate, 60 fps, to yield 40.980. Then 40.980 is rounded down to 40.

     

    (The above value 40 means frame 40 if one counts starting from zero or frame 41 if one counts starting from one. PP counts starting from zero. Thus, 40 is xx:xx:xx:40 in the form PP employs to display timings in an imported captions file.)

     

    PP, in its apparent second step of importing, adds 00:00:00:40 to the first 3 pieces of the caption block's time, that is, 00:12:30:xx, yielding 00:12:30:40. Since PP apparently rounds down in step 1, the timings in an imported SRT will sometimes be 1 frame lower than they would be if PP used a more "fair" rounding. (In my experiment, "sometimes" is about 40% of the caption block timings.)

     

    A better technique, to my way of thinking, would be to use rounding where 0-0.499 is rounded down and 0.500-0.999 is rounded up. In the present case, with a framerate of 60 fps, the final result would be 00:12:30:41; that is, one frame later, which is precisely what PP showed for the original caption block before I exported the track.

     

    I have to make clear that I've gone through only a small portion of the timings of an imported SRT in my experiment, but every one fits the pattern I've described. Sometimes the "error" is for the beginning of a caption block, less often for the end, and less often still for both beginning and end. When there is no error (about 60% of the time), the putative rounding down resulted in a "correct" value.

    J
    JARedmondWAAuthor
    Inspiring
    October 24, 2022

    I did some more checking.

     

    Every caption block with a millisecond value of x16, x33, x66 or x83, where x = 0 through 9, was affected. There were no affected caption blocks not in that set.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices