VSFilter ASS {\clip(m... l...)} Problem, Textsub.vdf=Ok

[Liisachan]

Thank you for confirmation. I happened to notice it while using VSFilter. We should be able to use a subtitle that is on Frame 0 (the first frame), so Start Time must be inclusive. And if so, End Time must be exclusive, because if both were inclusive there would be a collision just because End Time = Next Start Time like this, which would be very confusing and not acceptable.
00:01.00,00:05.00 ... line 1
00:05.00,00:10.00 ... line 2

Originally Posted by jiifurusu

The problem is only really fixable by using true fractional framerates (nominator/denominator) and that could require some reworking of the software. I'm not sure if this is reasonably fixable...

True..... The similar problem may occur when you write 23.976, because (double) 23.976 is not equal to what is called 23.976.

I'm not a pro programmer but just a learner, so I can't give you any clear explanation, but experience shows: using (double) fps, or (double) ms_per_frame is not safe, and something like this is relatively safer and may be practical enough.
sub_start_frame = ceil( sub_start_time * dwRate / dwScale )

eqvinox: 1 ns is not really needed, but directx has 100ns resolution, so 100 ns might be a good idea so that you can always tell for sure which event is before and which is after.

[jiifurusu]

Now, this is indeed a rounding error, and it doesn't happen on frame 0. The problem is that due to the base 2 binary decimal representation of floating point numbers, 2400 / (24000 / 1001) is represented as something just smaller than 100.1, something alike to 100.09999999999999990 (not the correct number of decimals) so indeed that time can't be represented correctly. However VSFilter does use strict inclusive/exclusive for start/end times, it's only that on this time stamp (and some other border cases) the lack of precision results in wrong results.
It might be fixable in the Avisynth and VirtualDub interfaces to TextSub, but is inherently unfixable in DirectShow, since DirectShow doesn't work with framerates, but rather simply a timestamp per frame, similar to how eg. Matroska stores it.

The best workaround to the problem is simply to make sure subtitles that need to be frame timed are timed within a safe margin instead of exactly on the start display time for the frame, ie. time the subtitle to begin 0.01 second too early. (Aegisub does something to this effect.)

While there formally is a bug, I think it's a bad idea to fix it, since it will potentially break some things that might expect the technically incorrect behaviour.

[Liisachan]

Just reported this probable bug in Guliverkli2.
https://sourceforge.net/tracker2/?fu...50&atid=994494

I'll post it here too hoping someone who knows better will read this, considering the nature of the Guliverkli2 project, and with images so that what I'm saying will be clearer. Also, this problem is very basic, so I think anyone who softsubs wants to know this. Also I'll suggest a workaround which you can use now, with almost no bad side effects.

Maybe should I report this to Aegisub people? But this bug is in MPC too. Anyway:

If ASS is muxed into MKV (softsubbed) and played back by VSFilter/MPC, when 2 subs overlap timing-wise, the 2nd-coming sub ("Ich..." in the example below) gets the wrong shadow alpha (4a); the 4a suddenly returns to normal when the 1st-coming sub ("Los!") disappears. Both older VSFilter and the newest version are affected.

bug_sample.mkv 30KiB

Demo/Workaround/ASS files used 3 KiB

(An example explained)
Style: style1,Verdana,50,
&H00ffeeff,&Hffffffff,&H00000000,&H80000000,
-1,0,0,0,100,100,0,0.00,1,1.00,10.00,2,20,20,20,0
Style: style2,Verdana,24,
&H0080ffff,&Hffffffff,&H80000000,&Hcc000000,
-1,0,0,0,100,100,0,0.00,1,0.75,1.50,8,2,2,8,0

;; Non-Overlapping
Dialogue: 0,0:00:01.00,0:00:03.00,style1,,0000,0000,0000,,Ich will spielen!

;; Overlapping
Dialogue: 0,0:00:05.00,0:00:09.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:15.00,style1,,0000,0000,0000,,Ich will spielen!

The 1st "Ich...", not overlapped, shows how it should be:

When the 2nd "Ich..." appears:

When the "Los" ends, the 2nd "Ich..." suddenly returns to normal.


A quick-fix (workaround) is to divide the 1st-coming sub timing-wise:

Dialogue: 0,0:00:05.00,0:00:08.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:09.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:15.00,style1,,0000,0000,0000,,Ich will spielen!

Hardsub (TextSub) and an external ASS loaded to MPC, not muxed into MKV, don't have this problem.

[clsid]

I suggest you contact jiifurusu. He is the Aegisub developer that has worked on improving VSFilter. He also has write access to Guliverkli2 repository.

[Liisachan]

Is he the only person who is actually doing VSFilter now? I hope he's checking the guliverkli2 tracker as a VSFilter dev, but if needed, I'll PM or email or otherwise try to contact him then. I feel it a bit weird to report MPC/VSFilter's bug to Aegisub people, because it's not a problem of Aegisub. I always wonder who I should report a bug of VSFilter to, and after all, usually when I notice a small problem I'll just try to find a workaround without telling anyone. I feel, though, I must share info about big problems like this.

[clsid]

Aegisub used to maintain their own repository with a modded version of VSFilter. That has moved to Guliverkli2 some time ago.

There is not really anyone else that is working on VSFilter. The MPC-HC devs are too busy with other things. So jiifurusu is your best change of getting this bug fixed.

[Liisachan]

Thank you clsid. Their bug tracker seems to be down, and their forums are not accepting bug reports, so I posted a comment to their blog. I know it's not the best place to report a bug to, but he/she will read it eventually. Well if it's moved to Guliverkli2, my first post to sf. might have been already enough, now that I think about it...