Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timing problem when opening a srt file #118

Open
anne-o-pixel opened this issue May 2, 2021 · 3 comments
Open

Timing problem when opening a srt file #118

anne-o-pixel opened this issue May 2, 2021 · 3 comments

Comments

@anne-o-pixel
Copy link
Contributor

anne-o-pixel commented May 2, 2021

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 a2da161 on master branch is fine
and commit bec44ea on master branch change the time like the example above

@Myaamori
Copy link
Contributor

Myaamori commented May 2, 2021

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. faad82e seems to do something related to timestamps.

@FichteFoll
Copy link
Contributor

FichteFoll commented May 3, 2021

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
Copy link
Contributor

petzku commented May 4, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants