SSA subtitle plays in wrong order

[intheclouds]

I have multiple mkv files that have an SSA subtitles included. When the subtitle shows two lines, the first spoken sentence appears on the second line and the second spoken sentence appears on the first line (ie reversed), other than that - the timing is fine.

I have reset preferences and downgraded to 2.2.8, but neither has made any changes.

The following should read:

'Yet, here you are.
Makes me wonder why.'



Codec information:



OS: Windows 7

The following is from MKV > mkvtoolnix > extract track as mks > DRSRTv3 > open mks;

12
00:00:17,170 --> 00:00:21,070 SSA: Dialogue, Layer: 0, Style: Default, Name: , MarginL: 0, MarginR: 0, MarginV: 0, Effect:
- Yet, here you are.

13
00:00:17,170 --> 00:00:21,070 SSA: Dialogue, Layer: 0, Style: Default, Name: , MarginL: 0, MarginR: 0, MarginV: 0, Effect:
Makes me wonder why.

Unfortunately I've not had any luck getting hits on the forum or google and the wiki doesn't seem to help either.

Also, I can use VLSub to download srt subtitles, there play as expected although they are typically out of sync and I would rather not have to download a second subtitle when one is provided with the file.

Thanks,

[InTheWings]

With "normal" collision prevention, the subtitles will "stack up" one above the other - but they will always be positioned as close the vertical (bottom) margin as possible - filling in "gaps" in other subtitles if one large enough is available.

[Jean-Baptiste Kempf]

VLC is doing the right thing here.

[intheclouds]

Thanks both for your prompt responses.

So, the issue is with the subtitle? the fact that it was created with a collision?

The included subtitle seems to have a lot of collisions but are all dealt with the same way as described above - in reverse. Wouldn't we expect at least some of the collisions to appear in the correct order?

However, subtitles can be shifted vertically to prevent onscreen collisions. With "normal" collision prevention, the subtitles will "stack up" one above the other - but they will always be positioned as close the vertical (bottom) margin as possible - filling in "gaps" in other subtitles if one large enough is available. If the entry says "Reverse" then subtitles will be shifted upwards to make room for subsequent overlapping subtitles. This means the subtitles can nearly always be read top-down - but it also means that the first subtitle can appear half way up the screen before the subsequent overlapping subtitles appear. It can use a lot of screen area.

RE: the bold/underlined text above, can either the renderer (libass?) be defaulted or VLC configured to enable this and would it help?

What is the solution to this issue? Download/embed additional correctly formatted subtitles?

Thanks,

[InTheWings]

According to the code, we have no control over this: this is a single subpicture.
So that's libass rendering.

[DeusExMachina]

VLC is doing the right thing here.

No it's not.
There is no "right thing" in all contexts. When there is a time code collusion, the code is presented with a choice. The colliding items must stack, but there is nothing requiring one order or another. There are three options, stacking on the Y axis first on top, stacking on the Y axis last on top, and stacking on the Z axis. Again, there is no "right thing" to do, and clearly in this instance the "right thing" is wrong, as the collision should be ameliorated by stacking in the opposite order.