Timing problem when opening a srt file

[anne-o-pixel]

Hello When opening a srt using a recent aegisub on Linux, the time switch of some ms and so it begins one frame after it should start

Here content example of the srt file:

1
00:00:49,466 --> 00:00:54,429
hello, I'm a line that'll be bad timed

Here the result on older aegisub (good version)

[Script Info]
; Script generated by Aegisub
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:49.46,0:00:54.42,Default,,0,0,0,,hello, I'm a line that'll failed

and here with a recent one:

[Script Info]
; Script generated by Aegisub
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:49.47,0:00:54.43,Default,,0,0,0,,hello, I'm a line that'll failed

With some research, commit a2da1616c0dc5f7823d61ff9ec0e75095260cd6d on master branch is fine and commit bec44eaab82c1bb4c3c5d9cb06fbbf3934155711 on master branch change the time like the example above

[Myaamori]

Note that there's a merge commit between these two that merges in a bunch of commits from mainline Aegisub since after the meson branch was created. E.g. faad82e1ec96a861aea3cac9272f90bb8ac36430 seems to do something related to timestamps.

[FichteFoll]

I don't think it's possible to have a one-size-fits-all solution for this case, because ASS simply has less precision than SRT, meaning information will be lost regardless of what is done. Since a pure timestamp-based conversion cannot know whether there is a frame change on either side of the rounding area, it must choose one. The old behavior was apparently to always round down while the new is to round to the closest legal number (or up, though the commit Myaa references doesn't indicate that). Statistically, rounding to the closest will result in fewer frame boundary traversals since the overall time shift is smaller, so I think the current behavior is the proper way.

Now, if the conversion was a bit more sophisticated and could e.g. take timecodes into account, it could easily make a decision for which side to round towards depending on whether it will or will not cross a frame boundary, since it knows where they are. It could for example prompt for a timecodes or video (container) file when importing subtitle formats with higher precision than ASS.

That would still only work for videos up to 100fps, but there's absolutely nothing Aegisub could do about those.

[petzku]

It could for example prompt for a timecodes or video (container) file when importing subtitle formats with higher precision than ASS.

Prompting on load/parse of a SRT file seems like a reasonable way to handle this IMO. If it's unfeasible, another option would be to just use the currently-loaded video when opening a SRT file, and fall back to current behaviour if one doesn't exist.