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.
Example:
correct_chapters.xmlfiles based on the offsets fromincorrect_subtitle.srttoreference_subtitle.ssaPossible 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_filein 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.