BDSup2Sub - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP)

[Peter_A]

Originally Posted by r0lZ

I have had the same problem with ++ and a specific BD (I don't remember which one). However, the Java version doesn't have that problem.

Also, note that the two versions have a CLI option to control the merging of the identical subtitles. It defines the maximum duration between two identical subtitles before they should be considered as two different subtitles. The option is -x <time_in_ms> or --merge-time <time_in_ms> and the default value is 200 ms for both versions. I don't know if that option is available in the GUI. And I don't know why that option doesn't work with BDSup2Sub++ and some specific subtitle streams.

Again, I suggest to keep the two versions of BDSup2Sbb and use the one that works best for each case.

(I have updated the list of bugs of the two versions here.)

Regarding "duplicate" subtitles, I found a different issue. On at least one title, there were consecutive subtitles, where the second began at the same timestamp as the first ended, but the captions were not the same (the first one was actually blank and very long in duration, so it probably shouldn't have been there in the first place, but it was, and the second one was a real caption). The Java-based BDSup2Sub merged them (dropped the second one and extended the time of the first, which was blank, to cover the time for both subtitles). So, the second subtitle (with a real caption) was lost completely. For the same title, BDSup2Sub++ maintained them both correctly. This may be a rare occurrence, but dropping a subtitle completely is much worse, in my opinion, than having duplicates, especially if the duplicates are there to begin with (i.e., not introduced by the program one is using).

[r0lZ]

Thanks for the interesting bug report. It is strange that both versions try to merge the two subtitles, as their content are obviously different. Can you confirm that their coordinates on screen are different too ? Also, have you tried to change the --merge-time (or -x) option ? Perhaps setting it to 0 is sufficient to solve the problem...

[Peter_A]

Originally Posted by r0lZ

Thanks for the interesting bug report. It is strange that both versions try to merge the two subtitles, as their content are obviously different. Can you confirm that their coordinates on screen are different too ? Also, have you tried to change the --merge-time (or -x) option ? Perhaps setting it to 0 is sufficient to solve the problem...

If you're replying to my post, both versions did not try to merge the two subtitles. Only the Java one did. C++ version worked fine. Coordinates are different. I have not tried anything via CLI; my use was via the GUI.

[CatBus]

I think I've found a bug in the Java version of BDSup2Sub (can't confirm C++). It looks like the colors of the subtitles get subtly changed when converting from BDN+XML to BD-SUP, in scenarios where I can't see a reason for this happening. You can magnify this by round-tripping the conversion multiple times.

Example: if the text in a BDN+XML subtitle is #E4E6E0, it gets converted to #E5E6E3 when you turn it into a BD-SUP. If you convert that BD-SUP back into BDN+XML, the color stays #E5E6E3. But then if you convert it back into a BD-SUP again, it then becomes #E5E5E5. Basically, every conversion from BDN+XML to BD-SUP slightly desaturates the colors.

I can't really tell where the conversion error is, but it may be in creating the image palette from the PNG files.

[CatBus]

I think the issue I described above is related to colorspace conversion (RGB->YCbCr), and it may well be that this is a normal amount of color shift due to lack of 100% color overlap between colorspaces. And the roundtrip magnification is why you should always try to reduce your colorspace conversions.

TL;DR: this may not be a bug at all, but just the normal weirdness that comes with colorspace conversion.