Apply offsets in a file distinct from the incorrect subtitle file
qgustavor opened this issue · comments
Example:
- 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 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 positionalalass 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 outputalass 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.