Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Subtitles

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd July 2020, 13:06   #1481  |  Link
Peter_A
Registered User
 
Join Date: Feb 2014
Posts: 21
Quote:
Originally Posted by r0lZ View Post
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).
Peter_A is offline   Reply With Quote
Old 3rd July 2020, 11:40   #1482  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,392
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...
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 8th July 2020, 16:29   #1483  |  Link
Peter_A
Registered User
 
Join Date: Feb 2014
Posts: 21
Quote:
Originally Posted by r0lZ View Post
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.
Peter_A is offline   Reply With Quote
Old 20th February 2021, 18:32   #1484  |  Link
CatBus
Registered User
 
Join Date: Jan 2012
Posts: 8
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 is offline   Reply With Quote
Old 22nd February 2021, 18:45   #1485  |  Link
CatBus
Registered User
 
Join Date: Jan 2012
Posts: 8
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.
CatBus is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.