Timing a bit off in an imported .srt file

Report · Oct 09, 2022

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.

Report · Oct 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

Report · Oct 23, 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.

Report · Oct 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.

Report · Oct 24, 2022

I shouldn't make much of the roughly 40% error items and 60% correct items in my experiment. I got those figures purely by eyeballing the 1090 caption blocks. And even if I did an actual count of error items and correct items, there is surely inherent variance — statistical noise — in this or any such experiment. I've a hunch the "true" error rate (ie, in the universe of imported SRTs) would be 33%. I'll have to think about all that.

Report · Oct 24, 2022

Interesting! I won't be able to play with this until tonight.

What version of PR are you using?

> I exported an .srt from a video.

Exported from PR? Framerate of that sequence was what?

> I imported the exported .srt file.

Was anything changed in the sequence other than deleting the caption track? Same framerate, correct?

What import method did you use? (Into that sequence? Or from Media Browser?)

> 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.

The millisecond value in the exported srt is 966? Where do you see the 950?

Stan

Report · Oct 24, 2022

Answers to your questions:Premiere Pro v22.1.2 (build 1), running on Win10 Pro x64.

SRT file when imported is 30 fps. Video is 60 fps. (These values are seen in the Project panel.)
About "anything changed": I'll return to this below.
Importing: Sometimes I dragged an exported SRT onto the Project panel. This morning, I chose to use the "import file" button in the Text panel. Same results.
About 966 versus 950: Text block #4 in the exported SRT was xx:xx:xx,966. When I imported that SRT and then exported it to a new file, block #4 in the new file was xx:xx:xx,950.

Here's my latest and stripped-down scenario.

In a new project, drag an .mp4 file (I keep a copy on my desktop), which is 60 fps, to the Project panel. Copy the .mp4 file to the timeline panel.
On the Text panel, click on Create new caption track, taking any defaults.
Create a new caption text block, eg, 'This is a test' . In this scenario, the block's timings are 00:00:00:00/00:00:03:00.
In the timeline panel, with the 2 slider buttons maximally close, working with the Subtitle track, adjust the beginning of the text block so that it is 2 frames later (this procedure is a bit hard to describe, but it's obvious if one plays with the cursor on the subtitle track). Now, in the Text panel, the block's timings are 00:00:00:02/00:00:03:00. So far, so good.
Export the subtitle track to an SRT. The single entry in the SRT is '00:00:00,033 --> 00:00:03,000' .
Right-click on "Subtitle" in the subtitle track in the timeline panel, choose Delete Track.
In the Text panel, click on Import captions from file. Choose the SRT exported in step 5. The imported SRT shows 30 fps in the Project panel.
In the new subtitle track in the Text panel, the timing is 00:00:00:01/00:00:03:00.
Export the caption track from the Text panel. The timing in the newly exported SRT is '00:00:00,016 --> 00:00:03,000' .

In short, if a caption text block begins with xx:xx:xx:02, the process of exporting, deleting, re-importing produces a text block that is one frame earlier, ie, xx:xx:xx:01.

Finally, forget (for now at least) what I said about truncation during import. Something's happening with certain timings in import, but all I know is that when there's an error, the error takes the form of making a timing one frame earlier. It's not evident to me whether truncation can account for that.

Report · Oct 24, 2022

By the way, why have I been going through the madness of exporting/re-importing?

Answer: I have a captions file with almost 1100 text blocks (an opera libretto). PP is aggravatingly slow if I make changes in a block whilst the Text panel is open. It would be easier to export the captions subtrack, use an editor to change things in the exported SRT, and lastly re-import. But re-importing frequently messes up the timings.

Report · Oct 24, 2022

Unfortunately, I think you are on the right track. I'd love for the engineers to demonstrate otherwise. Your situation with 60fps is simpler to see, but what about drop frame, 29.97/59.94 etc.

Some process comments on your latest scenario:

4. ... adjust the beginning of the text block so that it is 2 frames later
Just hit the plus key until you are fully zoomed in, then use the right/left arrow to move one frame at a time. Then drag the caption to adjust. But you're doing the correct test.

6. ... Delete Track.
Just click on the caption track eyeball, and disable it. Right click and rename (e.g. "Original"). When you import the new one, you'll see exactly how they compare.

7. ... The imported SRT shows 30 fps in the Project panel.
The caption track is no longer a video item, and actually has no timecode. It always says 30fps and means nothing. No matter, it does not affect your test.

9. Export the caption track from the Text panel. The timing in the newly exported SRT ....
I understand, but I think working with these re-exported millisecond numbers is only confusing - your test shows the problem.

As you demonstrate, what PR is doing is converting frames to milliseconds by dropping any fraction. This amounts to rounding down. Whether this is the right method or not requires looking at how that method works in putting srts into programs. For example, Youtube cannot display in milliseconds, it displays based on video frame. So what frame does it use, and is the PR SRT correctly interpreted or not.

But the problem for PR (and you!) occurs when you bring this back into PR. PR converts the milliseconds to frames by again dropping the fractions. This compounds the error and results in PR assigning incorrect frames for the caption timecodes.

Some frames are always correct, namely those that result in milliseconds with no fractions - in 60fps this occurs with every third frame - 0,3,6,9,12 etc). All others are one frame short.

Original frame	Export millisecond with fraction	Export millisecond drop fraction	Import Frame
0	0	0	0
1	16.66667	16	0
2	33.33333	33	1
3	50	50	3
4	66.66667	66	3
5	83.33333	83	4
6	100	100	6
7	116.6667	116	6
8	133.3333	133	7
9	150	150	9

Stan

Report · Oct 25, 2022

I don't follow you when you say PR drops fractions "again."

But you have identified the key thing: Because PR in export is restricted to 3 digits, PR truncates a millisecond value by dropping any fractional part. The truncation is not hypothetical. One sees it in the experiment we've elaborated.

Thus, for example, frame 1 has an internal value 0.01666667 seconds (or whatever; let's talk as if PR keeps that degree of numerical precision, because the true internal precision doesn't matter as long as it is greater than 3 places after the decimal), and 0.01666667 seconds becomes externally 016 milliseconds. The 0.00066667 has been dropped to arrive at the external value.

In import, PR gets 016 and converts it to 0.01600000. PR multiplies 0.01600000 by 60 to arrive at a frame number and gets 0.96000000: That's frame 0, not the frame 1 before export.

Similar logic applies to every frame. Frames 0, 3, 6, ... have values that yield an exactly correct external value. Other frames are truncated at export, and when those frames values are imported, the associated frame numbers are 1 less than the numbers before export.

Report · Oct 25, 2022

I guess taking 0.96000000 to mean frame 0 is what you called the second truncation. As I said at an earlier point, I'd opt for rounding up in the range 0.500 through 0.999. But PR in effect truncates.