Bug in VirtualDubMod?

Alxemi · 11th March 2003, 01:13

First my greatest THANKS to all vorbis/VDubMod/Xvid developers...
you´re doing a fantastic job!

I mux my OGMs with VirtualDubMod from the begining, and i play my last rips with bsplayer. In overlay mode1 i can see the OGM subtitles without the SUBTITDS filters installed (they give me a lot of problems..)
Using this method, bsplayer uses its own render engine to show the subs. It works fine, but the last character of each line is always missing...

I have always thought that it was a bsplayer problem, but then reading the Core Media Player changelog i read that:

[FIX] Fixed the bug where OGM embedded subtitles were cutted at the end (last char of each lines). From what I think, it was because VirtualDubMod does not insert the same characters control signifying the end of the line (10# instead of #10+#13) as the OggDS DSF muxer does. But that's also possible that the ISCR filter coming along with DirectX9 is the reason.

So i muxed with oggmux... and the last character appears! A VirtualDubMod bug? I don´t remeber this topic in the forum, so i post it.. maybe it helps.

Hey! It would be my first bug report!

I tested in w98 and XP with the same results

Greetings to all and excuse my english

Suiryc · 18th March 2003, 18:26

Hi

thanks for mentionning this problem.
It seems some subtitle engines eat the last char in this case.
VirtualDubMod currently (in the latest releases) write embedded subtitles using a (I believe) correct format which is "..." for single line and "...\r\n..." for multi-line subtitles.
SubtiDS write subtitles "...\r" and "...\r\n...\r" (which is, for me, not really 'natural'). However some subtitle engines (the one in the latest BSplayer you mention for example) eat the last char of the subtitle if the former format (and not the latter) is used :/

I corrected this in our CVS (i.e. we now use the same format as SubtiDS).

Thanks again.

11th March 2003, 01:13	#1 \| Link
Alxemi Happy XviD user Join Date: Aug 2002 Location: Madrid, Spain Posts: 183	Bug in VirtualDubMod? First my greatest THANKS to all vorbis/VDubMod/Xvid developers... you´re doing a fantastic job! I mux my OGMs with VirtualDubMod from the begining, and i play my last rips with bsplayer. In overlay mode1 i can see the OGM subtitles without the SUBTITDS filters installed (they give me a lot of problems..) Using this method, bsplayer uses its own render engine to show the subs. It works fine, but the last character of each line is always missing... I have always thought that it was a bsplayer problem, but then reading the Core Media Player changelog i read that: [FIX] Fixed the bug where OGM embedded subtitles were cutted at the end (last char of each lines). From what I think, it was because VirtualDubMod does not insert the same characters control signifying the end of the line (10# instead of #10+#13) as the OggDS DSF muxer does. But that's also possible that the ISCR filter coming along with DirectX9 is the reason. So i muxed with oggmux... and the last character appears! A VirtualDubMod bug? I don´t remeber this topic in the forum, so i post it.. maybe it helps. Hey! It would be my first bug report! I tested in w98 and XP with the same results Greetings to all and excuse my english __________________ Mira detras de ti... ¡Un mono con tres cabezas! (Guybrush Threepwod)

18th March 2003, 18:26	#2 \| Link
Suiryc Registered User Join Date: Oct 2001 Location: France Posts: 517	Hi thanks for mentionning this problem. It seems some subtitle engines eat the last char in this case. VirtualDubMod currently (in the latest releases) write embedded subtitles using a (I believe) correct format which is "..." for single line and "...\r\n..." for multi-line subtitles. SubtiDS write subtitles "...\r" and "...\r\n...\r" (which is, for me, not really 'natural'). However some subtitle engines (the one in the latest BSplayer you mention for example) eat the last char of the subtitle if the former format (and not the latter) is used :/ I corrected this in our CVS (i.e. we now use the same format as SubtiDS). Thanks again.