Doom9's Forum - View Single Post - BDSup2Sub - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP)

r0lZ · 29th December 2017, 14:49

OK, I did some tests with various versions of BDSup2Sub. I have tested BDSup2Sub v4.0.0 (as far as I know, it's the latest version written by 0xDEADBEEF, still available in the files.zip here), v5.1.2 (the current "official" version), BDSup2SubEnhanced v0.0.9 (originally based on v5.0.0) and BDSup2Sub++ v1.0.2 (the only version that doesn't require Java). Unfortunately, none is bug free.

Here is the detail of the tests I did.

Let's begin with the little bugs or discrepancies, not really harmful if you know what you are doing.

1. The irritating problem of the frame rate assumed wrongly is present in all Java versions, but the ++ version doesn't have that problem. Note that it's not really a bug, only a discrepancy. When you load a stream, the program detects correctly the source frame rate, but it sets 25 fps as the default output frame rate, for totally obscure reasons. That means that the time codes are rounded with the wrong output frame rate, and they are therefore not strictly identical than in the input stream, even if the user doesn't explicitly require a conversion. Furthermore, the wrong frame rate is written in the XML file if you convert to XML/PNG, and that can lead to completely wrong time codes and grave sync problems. Luckily, it is easy to avoid that bug simply by specifying that you WANT a conversion, and specifying the output frame rate equal to the input frame rate. It's a pity, but if you know that you have to do it, the workaround is easy. (That works with the GUI and the command line.)

2. Related to point 1 is the bug that prevents the user to store a different output frame rate by default. The output frame rate is always 25 fps in all Java versions, regardless of what you have used the last time and/or the usage of the "Store" button. That means that even if you use only, say, BD sources at 23.976, you have to pay attention to the output frame rate each time you load a stream. Pity, but again, it's an annoyance and not really a bug. Again, the ++ version does a better job. It doesn't store the output frame rate, but it uses by default the same frame rate than the input. Perfect.

3. Related to point 2 is the way the program store its settings. All versions store them in .ini files, but v4.0.0 and the Enhanced versions store them in the folder containing the executable. It's against the Microsoft rules, but you may accept that little problem. V5.1.2 and ++ store their ini respectively in the user's home and in APPDATA\Roaming, as they should.

Now, the real bugs.

4. When a subtitle is included in a larger bitmap (therefore with more or less large transparent borders around them), all Java versions have problems with the colours or the transparency values of the different parts of the subtitles. For example, the background can be opaque instead of fully transparent, or the outline can be missing. This is the case of v4.0.0 and Enhanced. V5.1.2 outputs completely transparent frames ! Only the ++ version does the job perfectly. I guess that bug is caused by the method used to discover the colours and transparency levels of the different parts of the pictures. They check probably only some pixels near the border of the subtitle, and fail when there is no subtitle at that place. It's a very important bug, that occurs relatively frequently (especially with Asian BDs). It explains why some peoples have reported that some subtitles are missing when using a recent version. v4.0.0 and Enhanced give totally wrong results, but at least, they are visible.

5. The Enhanced version has been written to fix the bug of missing subtitles when several subtitles are displayed AT THE SAME TIME (technically: Multiple ODS). It's often the case with Japanimation (mangas) but that can happen with other movies as well, although it's relatively rare. Indeed, v4.0.0 and v5.1.2 have that problem, as well as the entire "official" branch of BDSup2Sub. And of course, the Enhanced version does it well. Strangely, the ++ version works also perfectly well ! It's an important bug, but unless you are a fan of mangas, you may not have noticed it.

6. When an XML/PNG stream is loaded in any version of BDSup2Sub, the fully transparent borders are cropped so that the picture occupies the smaller possible areas. (Of course, nothing changes when the subtitle touches the 4 borders.) Since the border is removed, the X, Y, width and height coordinates of the bitmap must be adjusted. All Java versions do that job correctly. The ++ version has its first bug here. The X coordinate is always wrong after a crop. For example, the subtitle is not centered on screen any more, and may appear slightly to the left, or completely near the left border of the video frame. Of course, it's a big bug, that happens only when loading XML/PNG streams containing subtitles in large canvas. It's a pity, as otherwise AFAIK ++ is the only bug free version. Unfortunately, the development of the ++ version has stopped, so the crop bug will probably remain for a long time.

7. The ++ version tries to detect when several subtitles are displayed at the same time in a BD SUP stream (Multiple ODS), just like the Enhanced Java version, and usually it does it well. When it converts the SUP stream to XML/PNG, it creates several PNG images for the same subtitle (instead of a single image combining all subtitles together). It is not clear if doing so is legal, but it is able to load the XML/PNG and convert it back to another format without problem. However, it has a big bug occurring only with some specific SUP streams (like the subtitles of Avatar 3D). It detects wrongly some additional subtitles that are in fact not present. When it encounters such false positives, it creates bizarre empty PNG images, and it references them in the XML badly. The result is that the XML/PNG stream cannot be reloaded in any version of BDSup2Sub. See this post for more info.

8. It's probably not a bug, but I notice that there are many warning messages displayed by all java versions, like for example:
WARNING: multiple PDS/ODS definitions: result may be erratic
WARNING: end time of frame 39 < start time -> fixed
WARNING: fade out detected -> patched palette
Strangely, the ++ version does NOT display these warnings. Is it because it deals with the potential problems correctly ? It's certainly the case of the multiple PDS/ODS definitions, but for the other warnings, I don't know.

9. With some BDs, it appears that BDSup2Sub++ is unable to merge the identical subtitles together. So, in that BDs, a single subtitle can be repeated several times, with no gap (or only a few ms) between the time codes. The resulting subtitle stream is therefore larger than the original one. The java version doesn't have that bug. Both versions have the CLI option -x <time> or --merge-time <time> to "Set maximum time difference for merging subtitles in ms", with the default value of 200 ms, but it seems that that option doesn't work well with ++ and some subtitle streams.

10. When BDSup2Sub++ loads and re-saves (without modification) a BD SUP file, it creates a new file larger than the original file. The overhead is usually around 10%. Even the new version, re-saved again, has again a small size increase. The origin of the problem is not known, but it seems that the stream is still correct and compatible with the decoders. The Java version doesn't have that problem.

There might of course be other bugs that I'm not aware of, or very small bugs that are not really important like the little GUI bugs of v4.0.0. Note also that the ++ version doesn't have exactly the same command line parameters than the Java versions. And, about the command line, the 3 Java versions may require to launch Java with the obscure -Xmx256m command line parameter, as otherwise it may crash when processing a big subtitle file due to lack of memory.

Anyway, with the 4 "problematic" streams I've tested so far, there is no version that works constantly as expected. I suggest therefore to use the ++ version if you don't need to convert from or to XML/PNG, and the Enhanced version otherwise. Anyway, don't forget to pay attention to the output frame rate (bug 1) with all Java versions.

P.S. The bugs 4 and 6 can be reproduced with this sample. Bug 7 is clearly demonstrated with the subtitles of the Avatar 3DBD (not sure for the 2D version). If someone wants to check a specific stream or bug, send me a PM and I'll give you the demo stream.

29th December 2017, 14:49	#1378 \| Link
r0lZ PgcEdit daemon Join Date: Jul 2003 Posts: 7,469	OK, I did some tests with various versions of BDSup2Sub. I have tested BDSup2Sub v4.0.0 (as far as I know, it's the latest version written by 0xDEADBEEF, still available in the files.zip here), v5.1.2 (the current "official" version), BDSup2SubEnhanced v0.0.9 (originally based on v5.0.0) and BDSup2Sub++ v1.0.2 (the only version that doesn't require Java). Unfortunately, none is bug free. Here is the detail of the tests I did. Let's begin with the little bugs or discrepancies, not really harmful if you know what you are doing. 1. The irritating problem of the frame rate assumed wrongly is present in all Java versions, but the ++ version doesn't have that problem. Note that it's not really a bug, only a discrepancy. When you load a stream, the program detects correctly the source frame rate, but it sets 25 fps as the default output frame rate, for totally obscure reasons. That means that the time codes are rounded with the wrong output frame rate, and they are therefore not strictly identical than in the input stream, even if the user doesn't explicitly require a conversion. Furthermore, the wrong frame rate is written in the XML file if you convert to XML/PNG, and that can lead to completely wrong time codes and grave sync problems. Luckily, it is easy to avoid that bug simply by specifying that you WANT a conversion, and specifying the output frame rate equal to the input frame rate. It's a pity, but if you know that you have to do it, the workaround is easy. (That works with the GUI and the command line.) 2. Related to point 1 is the bug that prevents the user to store a different output frame rate by default. The output frame rate is always 25 fps in all Java versions, regardless of what you have used the last time and/or the usage of the "Store" button. That means that even if you use only, say, BD sources at 23.976, you have to pay attention to the output frame rate each time you load a stream. Pity, but again, it's an annoyance and not really a bug. Again, the ++ version does a better job. It doesn't store the output frame rate, but it uses by default the same frame rate than the input. Perfect. 3. Related to point 2 is the way the program store its settings. All versions store them in .ini files, but v4.0.0 and the Enhanced versions store them in the folder containing the executable. It's against the Microsoft rules, but you may accept that little problem. V5.1.2 and ++ store their ini respectively in the user's home and in APPDATA\Roaming, as they should. Now, the real bugs. 4. When a subtitle is included in a larger bitmap (therefore with more or less large transparent borders around them), all Java versions have problems with the colours or the transparency values of the different parts of the subtitles. For example, the background can be opaque instead of fully transparent, or the outline can be missing. This is the case of v4.0.0 and Enhanced. V5.1.2 outputs completely transparent frames ! Only the ++ version does the job perfectly. I guess that bug is caused by the method used to discover the colours and transparency levels of the different parts of the pictures. They check probably only some pixels near the border of the subtitle, and fail when there is no subtitle at that place. It's a very important bug, that occurs relatively frequently (especially with Asian BDs). It explains why some peoples have reported that some subtitles are missing when using a recent version. v4.0.0 and Enhanced give totally wrong results, but at least, they are visible. 5. The Enhanced version has been written to fix the bug of missing subtitles when several subtitles are displayed AT THE SAME TIME (technically: Multiple ODS). It's often the case with Japanimation (mangas) but that can happen with other movies as well, although it's relatively rare. Indeed, v4.0.0 and v5.1.2 have that problem, as well as the entire "official" branch of BDSup2Sub. And of course, the Enhanced version does it well. Strangely, the ++ version works also perfectly well ! It's an important bug, but unless you are a fan of mangas, you may not have noticed it. 6. When an XML/PNG stream is loaded in any version of BDSup2Sub, the fully transparent borders are cropped so that the picture occupies the smaller possible areas. (Of course, nothing changes when the subtitle touches the 4 borders.) Since the border is removed, the X, Y, width and height coordinates of the bitmap must be adjusted. All Java versions do that job correctly. The ++ version has its first bug here. The X coordinate is always wrong after a crop. For example, the subtitle is not centered on screen any more, and may appear slightly to the left, or completely near the left border of the video frame. Of course, it's a big bug, that happens only when loading XML/PNG streams containing subtitles in large canvas. It's a pity, as otherwise AFAIK ++ is the only bug free version. Unfortunately, the development of the ++ version has stopped, so the crop bug will probably remain for a long time. 7. The ++ version tries to detect when several subtitles are displayed at the same time in a BD SUP stream (Multiple ODS), just like the Enhanced Java version, and usually it does it well. When it converts the SUP stream to XML/PNG, it creates several PNG images for the same subtitle (instead of a single image combining all subtitles together). It is not clear if doing so is legal, but it is able to load the XML/PNG and convert it back to another format without problem. However, it has a big bug occurring only with some specific SUP streams (like the subtitles of Avatar 3D). It detects wrongly some additional subtitles that are in fact not present. When it encounters such false positives, it creates bizarre empty PNG images, and it references them in the XML badly. The result is that the XML/PNG stream cannot be reloaded in any version of BDSup2Sub. See this post for more info. 8. It's probably not a bug, but I notice that there are many warning messages displayed by all java versions, like for example: WARNING: multiple PDS/ODS definitions: result may be erratic WARNING: end time of frame 39 < start time -> fixed WARNING: fade out detected -> patched palette Strangely, the ++ version does NOT display these warnings. Is it because it deals with the potential problems correctly ? It's certainly the case of the multiple PDS/ODS definitions, but for the other warnings, I don't know. 9. With some BDs, it appears that BDSup2Sub++ is unable to merge the identical subtitles together. So, in that BDs, a single subtitle can be repeated several times, with no gap (or only a few ms) between the time codes. The resulting subtitle stream is therefore larger than the original one. The java version doesn't have that bug. Both versions have the CLI option -x <time> or --merge-time <time> to "Set maximum time difference for merging subtitles in ms", with the default value of 200 ms, but it seems that that option doesn't work well with ++ and some subtitle streams. 10. When BDSup2Sub++ loads and re-saves (without modification) a BD SUP file, it creates a new file larger than the original file. The overhead is usually around 10%. Even the new version, re-saved again, has again a small size increase. The origin of the problem is not known, but it seems that the stream is still correct and compatible with the decoders. The Java version doesn't have that problem. There might of course be other bugs that I'm not aware of, or very small bugs that are not really important like the little GUI bugs of v4.0.0. Note also that the ++ version doesn't have exactly the same command line parameters than the Java versions. And, about the command line, the 3 Java versions may require to launch Java with the obscure -Xmx256m command line parameter, as otherwise it may crash when processing a big subtitle file due to lack of memory. Anyway, with the 4 "problematic" streams I've tested so far, there is no version that works constantly as expected. I suggest therefore to use the ++ version if you don't need to convert from or to XML/PNG, and the Enhanced version otherwise. Anyway, don't forget to pay attention to the output frame rate (bug 1) with all Java versions. P.S. The bugs 4 and 6 can be reproduced with this sample. Bug 7 is clearly demonstrated with the subtitles of the Avatar 3DBD (not sure for the 2D version). If someone wants to check a specific stream or bug, send me a PM and I'll give you the demo stream. __________________ r0lZ PgcEdit homepage (hosted by VideoHelp) BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV Last edited by r0lZ; 20th March 2019 at 15:27. Reason: Added ++ bug #10.