You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You got reference_subtitle.ssa incorrect_subtitle.srt and incorrect_chapters.xml,
Run alass on those three files and get a correct_chapters.xml files based on the offsets from incorrect_subtitle.srt to reference_subtitle.ssa
Possible command syntax:
alass reference_subtitle.ssa incorrect_subtitle.srt correct_chapters.xml --content-source=incorrect_chapters.xml:
a flag, quite simple but a bit weird because all other arguments are positional
alass reference_subtitle.ssa incorrect_subtitle.srt incorrect_chapters.xml correct_chapters.xml:
4 positional arguments means that the output argument is now the source which the offsets will be applied and the fourth argument is now the output
alass reference_subtitle.ssa incorrect_subtitle.srt correct_chapters.xml incorrect_chapters.xml:
4 positional arguments means that the last argument is now the source which the offsets will be applied
Possible issues and solutions:
Adding the Matroska .xml chapter format might be hard or introduce too much complexity. In that case I think that's fine just adding this option and only allowing it to be used on the already accepted formats. Handling chapters would be still possible if I write a .xml to .ass to .xml converter (I think I can write one and publish in CodePen without any problem using ass-parser and DOMParserEdit:here it is).
Maintainers might not have time for that. In that case I will try to implement it myself and submit a pull request. I never worked with Rust before, but I think implementing it would require - from what I read in the code - just replacing inc_file in some parts of the code with a reference to the file to be used as input when the extra argument with the override source is inputted.
Edit: I tried implementing it myself and here are the changes I made. I tested this code and it worked, in the other hand the synchronized chapters were offset from the correct timings by up to 30 seconds, so I don't know if I messed up the implementation or if the reference file I used when testing was not ideal.
Edit: I didn't implemented timestamp format conversion in the xml to ass converter and - for some reason - passing a .ass file to alass with a lot of leading zeros - which is what the xml stores - made it return completely wrong timings. I probably need to fix my converter to use the expected timestamp format in ass, but that was weird. I assumed the timestamp parsing just assumed a colon delimited list of integers followed by a float value, thus the leading zeroes would not cause any issue.
The text was updated successfully, but these errors were encountered:
Example:
correct_chapters.xml
files based on the offsets fromincorrect_subtitle.srt
toreference_subtitle.ssa
Possible command syntax:
alass reference_subtitle.ssa incorrect_subtitle.srt correct_chapters.xml --content-source=incorrect_chapters.xml
:a flag, quite simple but a bit weird because all other arguments are positional
alass reference_subtitle.ssa incorrect_subtitle.srt incorrect_chapters.xml correct_chapters.xml
:4 positional arguments means that the output argument is now the source which the offsets will be applied and the fourth argument is now the output
alass reference_subtitle.ssa incorrect_subtitle.srt correct_chapters.xml incorrect_chapters.xml
:4 positional arguments means that the last argument is now the source which the offsets will be applied
Possible issues and solutions:
I think I can write one and publish in CodePen without any problem using ass-parser and DOMParserEdit: here it is).inc_file
in some parts of the code with a reference to the file to be used as input when the extra argument with the override source is inputted.Edit: I tried implementing it myself and here are the changes I made. I tested this code and it worked, in the other hand the synchronized chapters were offset from the correct timings by up to 30 seconds, so I don't know if I messed up the implementation or if the reference file I used when testing was not ideal.
Edit: I didn't implemented timestamp format conversion in the xml to ass converter and - for some reason - passing a .ass file to alass with a lot of leading zeros - which is what the xml stores - made it return completely wrong timings. I probably need to fix my converter to use the expected timestamp format in ass, but that was weird. I assumed the timestamp parsing just assumed a colon delimited list of integers followed by a float value, thus the leading zeroes would not cause any issue.
The text was updated successfully, but these errors were encountered: