fix untimed last word fixes #779

[pxeemo]

I couldn’t find a case where lastWordSyncPoint is required, even after testing edge cases.
Please let me know if I’m missing something.

[nift4]

the idea was supporting completely empty words where timestamp is used to denote line end

like [00:11.22]<00:11.33>blah<00:11.44><00:11.55>

here end timestamp should be 00:11.55 and not 00:11.44

if you can add a quick unit test for this it would be great

[nift4]

Actually, there's already a unit test for what I was trying to do with that, but apparently there was no unit test for the inverse (what broke the benchmark lrc). Hmm.

[pxeemo]

I was thinking about the logic here.
Currently it calculates an average from the previous words and applies it based on the characters length, but shouldn't it just take the last word end time from the next line starting point?

[nift4]

I think I also had an TODO somewhere about this not making too much sense.

If next line start is bigger than last word's start time, then we can do that. It makes sense to me.

If next line start is however smaller then we have to keep estimating, as word cannot have negative duration.

[nift4]

but shouldn't it just take the last word end time from the next line starting point?

I tested it and it leads to bad results. Anyway, I'm fixing the bug this PR pointed out in a more complicated way, so I'm closing this. Thanks a lot for debugging this :)

[nift4]

Nevermind i tested wrong.. let me retry