Calculating Conversion of SRT Time Code (AegiSub) into Conventional time code (Premiere)

[Mohaiemen]

I need to shift a set of time codes in an SRT file (using Aegisub Editor) to fix a mis-alignment within Premiere (Open Captions Subtitle file).

I can't do it in Premiere itself for the following reasons:
- Subtitle track was created using File>New>Captions>Open Captions and then placing that into a video track
- Now that all the subtitles have been manually placed, if I wanted to shift them, there's no way to grab all the subtitles and drag them forward
- A little bit of extra audio was inserted into beginning of film, but there's no way to drag/extend the subtitle track backward to fill in that gap (and even if I did, the actual time codes would not change to the right position)

In Premiere I can see that the first mis-aligned subitle needs to move to 00:01:13:09 (I will shift all subtitles at one go, but this first one is the marker). I export the Subtitle as an SRT (File>Export>Captions) and then move to AegiSub where I know there is option to shift a group of susbtitles and have time code change. When I open the file in AegiSub the time codes are in SRT format, which means that the errant subtitle is showing as 00:01:03.87. 

The .xx format showing at end of SRT time code isn't in the same format/mathematics as the :yy format showing at the end of the subtitle(.xx seems to go up to 99 while :yy goes up to :30), I don't have a way of doing the math for how much it should move. I looked online for calculators that do the conversion, but websites like this one robwomack.com/timecode-calculator/ give you only a total number of frames.

Maybe there is a simpler way to do this?

[Stan Jones · Accepted solution]

The most common srt ending is milliseconds, with the 3 digists at the end separated from the seconds by a comma. Aegisub appears to be displaying 100ths, which it exports in its .ass format. But when it exports as srt, it uses milliseconds. PR exports srt also with milliseconds.

Let's assume it is hundreds you need. Divide the PR frames (09) by the framerate (let's assume 29.97) and the result is .300. So in Aegisub, set it to 1:13.30.

I would consider just pulling the video into Aegisub and do the fix there.

Stan

[Mohaiemen]

Thanks Stan. Very helpful. I'm detailing the results here, in case it's helpful to other users.

My project was 24 FPS. I was trying to get from 00:01:03.87 to the equivalent of 00:01:13:09. That means adding 9 seconds and then a certain number of miliseconds (AegiSub shows only up to two digits by the way, even if it is mili), something along the range 1:09 - 0.87

So 100 * 9/24 = 37.5 (~38 ms) 
So 1.38 - 0.87 = 0.51

So total shift would be 00:00:09.51 in Aegisub.

I tried that and the resulting SRT was a fraction forward of the correct point (looks like 24% of a Premiere frame). Then I tried doing 00:00:09.50 (Aegisub didn't allow 3 decimal points) and that was a fraction behind the correct point. So looks like that fractional difference cannot be matched/resolved using Aegisub. I have attached a screenshot– bottom row is the correct subtitle position (but that version has a gap at beginning due to adding extra audio), middle row is with 0.51, top rop is with 0.50.



I followed Stan's advice and did the shifting in AegiSub (which is similar to Subtitle Editor) and after I changed the units to frames, was able to do a precise shift.

[Mohaiemen]

Found this excellent online time code calculator designed by Michael Cinquin.

It does two things very elegantly:
1) Calculates the exact time code difference between two time code points. In my original inquiry, I was asking about shifting individual blocks within an SRT after they have become mis-aligned, and since in such cases the misalignment is often backward or forward, this calculation gets you to how much you need to shift accurately (and quickly, I was doing the calculation manually, following Stan Jones helpful answer above).



2) Converts frames in the last position (00:00:00:00) to miliseconds. So in example above, the amount the subtitle needs to shift is 00:00:22:16, but if you are using something like AegiSub which requires giving the last position in miliseconds, look at the number inside bracket and the calculation is done for you– in this example 22:16 = 22.666 (or 22.67 rounded up).

There is an option to donate if you like his freeware, which I did. Well worth it. Everything else like this on the web seems to require laborious excel macros.

Just for perspective, this is my manual system for figuring out time code shifts before finding this calculator. The bad old days.

Manual system for calculating time code shifts...

[Stan Jones]

Thanks for sharing!