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

[newnews]

Hello, I extracted the subtitle stream(BD PGS) from mkv file. Then I open the this .sup file with BDSup2Sub and save it to idx/sub. I can only see 20 lines. If I open this .sup file, I am able to see all 1300+ lines, but that software does not give option to save as idx/sub, so I still want to use BDSup2Sub. The error log while opening the sup file is:

Loading E:\Edge.of.Tomorrow\Edge.of.Tomorrow.2014.3D.BluRay.x264.DTS.track3_eng.sup
#> 1 (00:00:15.599)
#> 2 (00:00:37.621)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 2 (00:00:39.039)
#> 3 (00:00:40.791)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 3 (00:00:42.918)
#> 4 (00:00:45.003)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 4 (00:00:45.921)
#> 5 (00:00:48.006)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 5 (00:00:49.717)
WARNING: Invalid image size - ignored
WARNING: Missing PDS/ODS: last epoch is discarded
#> 5 (00:00:51.760)
#> 6 (00:00:53.053)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 6 (00:00:54.847)
WARNING: <unknown> 0x50 ofs:0x0006a035
ERROR: PG missing at index 0x0006e742


Detected 0 forced captions.
WARNING: missing end time of frame 6 -> fixed
Decoding frame 1/6 at offset 0x00000108

Please advice.

[igboo]

Is there a way to directly edit a blu-ray pgs stream? I specifically would like to be able to add subtitles to an existing .sup.

Cheers

[jpsdr]

You can't "Edit" in a text way a pgs stream, because it's made of pictures, it's not text dialog lines.

[DoctorM]

@igboo:

1) Okay, first create an SRT file with just the new subtitles you wish to add. Make sure the timing and everything are right.
2) Use a program like goSUP to turn your new SRT file into a BD SUP file. Try to match the colors, font and positions of your old subtitles because you can't change this later.
3) In BDSup2Sub load your old SUP file and then select output as XML/PNG to a folder. Call the output something like 'Original'.
4) In BDSup2Sub load your add-on SUP file and again output and save as XML/PNG. Save them to the same folder you put the output from step 3 in and name the files something like 'ADDON'.
5) Open the OLD and ADDON .XML files in Wordpad. Copy the relevant sections of code from your addon subs into the old subs and save it under a new name keeping an .XML extension.

The pieces you are copying in the .XML should be ONLY between EVENT tags. There will be one entry for each new line you are adding. (Similarly you can delete a line between these tags.)
Don't copy anything else. So a section should look like this:
<Event InTC="00:03:09:11" OutTC="00:03:11:06" Forced="False">
<Graphic Width="575" Height="130" X="673" Y="888">ADDON_0005.png</Graphic>
</Event>

It appears each line of <EVENT> needs to be in time code order, so make sure you copy them in that way to the XML file.

6) Load the new .XML in BDSup2Sub and save it as a BD SUP file. Done.

[igboo]

@igboo:

Done.

:thanks:

Thanks for the detailed method DoctorM. I've been looking for a way to do this for quite a while.

I'll give it a try when I get a chance over the next several nights.

Cheers

[an3k]

So I have this BD subtitle file taken directly from a Blu-ray I own. It's the german Avatar BD which contains all three editions (original cinema, extended cinema, collector's cut). https://www.dropbox.com/s/wjhkwtyzngjcjyy/00802.track_4612.sup?dl=0 This one is for the collector's cut.

When I open it with the Java version 5.1.2 it finds 1487 frames but many of them have errors like missing end time. Frame 710 has a 1920x1080 sized subpicture and its content is shown in the little preview windows in the bottom right corner (and also in both top and bottom preview windows but you have to scroll). Frame 712 also has a 1920x1080 sized subpicture but its content is NOT shown anywhere.
It is shown with these informations:screen size: 1920x1080 image size: 1920x1080 pos: (0,0) - (1920,1080) start: 01:10:01.130 end: 01:10:03.757 forced: yes

screen size: 1920x1080 image size: 1920x1080 pos: (0,0) - (1920,1080) start: 01:10:01.120 end: 01:10:03.760 forced: yes

Now I export to PNG/XML and I get 1.487 png files - one for each frame. The file for frame 710 is 1920x1080 and has actual text. The one for frame 712 is completely empty (size is the same as for frame 710 but no subtitle, just an empty picture).
If I open the XML in eg. Chrome or Notepad and jump to frame 710 I see <Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">original_0710.png</Graphic>
</Event>

Why is BDSup2Sub modifying the timings? Why differ the timings in BDSup2Sub so much from those in the XML file (which is created by BDSup2Sub)? Roughly 5 seconds! Why is the content of frame 710 shown a little bit awkward and the content of frame 712 not at all?


If I open the same file in the Qt version 1.0.2 it finds 1492 frames (because some frames are just split - frame XYZ with a duration of 1000 gets split into two frames with a duration of 500 each) but no errors at all. Frame 710 (now frame 711) is shown in the both top and bottom preview windows but not in the small in the bottom right corner. Same for Frame 712 (713).
When I export to PNG/XML I get 1.971 png files. Some frames have only one png file, some have two png files and some have 3 or more. Frame 710 (711) has two. One is 1920x1080 with the subtitle in the top left corner and one is 827x126 and contains the subtitle beautifully centered. Frame 712 (713) has also two png files in the same format and style as for 710 (711).


If I open the same file in Subtitle Edit it finds 1.487 frames, no errors at all but slightly different timings than in BDSup2Sub or the XML file. Frame 710 has 01:10:01,130 - 01:10:03,758 (duration 2,628).


If I finally open the XML file I created with BDSup2Sub Java in BDSup2Sub I again get different behavior and timings. Frame 710 is now correctly shown in all three preview windows with the following informations:screen size: 1920x1080 image size: 800x92 pos: (563,806) - (1363,898) start: 01:10:01.114 end: 01:10:03.742 forced: yes

screen size: 1920x1080 image size: 800x92 pos: (563,806) - (1363,898) start: 01:10:01.120 end: 01:10:03.760 forced: yesHowever, frame 712 cannot be shown at all.


Actually I need three tools to fix a "broken" BDsup. BDSup2Sub Java, BDSup2Sub Qt and Subtitle Edit. I use Java to create a valid XML and most png files. Qt to get the png files Java wasn't able to read/create correctly. Subtitle Edit to get the correct timings.

[r0lZ]

I can perhaps explain why you have timing differences. The first reason is that BDSup2Sub re-arranges the timings to be in sync with the frames of the video stream. For example, the end time in your first example (01:10:03.757) is probably not exactly the time code of a specific video frame at 23.976fps. Therefore, it rounds it to the nearest frame, and that gives 01:10:03.760.

The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). Note the terrible syntax: 24p doesn't mean 24fps, but 23.976! You have already the example of 2 bugs: the necessity to add the options to convert the frame rate to NOT convert it, and the discrepancy in the syntax of the frame rate. But if you use BDSup2Sub.jar from the CLI, it is possible to obtain correct results. (The rounding of the time codes will occur anyway, but it's not really a bug.) I suppose that you can play with the frame rate option in the first window of the GUI to obtain the same result, but I have never tried.

I don't know why subtitle #712 is not visible. Indeed, it's a big problem. I know that some BD subtitles have special effects like fades that can confuse BDSup2Sub, and it's probably why BDSup2Sub++ generates several images instead of only one. The Java version is supposed to drop the invisible images and retain only the "best" one. Maybe there is another bug here and it keeps the fully transparent image?

I don't use Subtitle Edit with BD3D2MK3D, simply because it cannot do what I need, and anyway, most conversions cannot be done from the CLI. But I like it when I need to convert manually a text based subtitle stream to BD SUP. As far as I know, it has no bugs.

I wonder if it is justified to accuse BDSup2Sub of all problems you have had. As explained above, the timing problem is certainly a bug, but it can be solved. However, the other problems (such as the invisible subtitle or the multiple PNGs produced by the ++ version) are probably due mainly to your stream. According to the numerous error messages, that stream is seriously damaged. And that reminds me something I have discovered when I have converted Avatar 3D for the first time. At that time, BD3D2AVS (as it was called then) was using eac3to to demux the 3D MPLS. That worked well for the video and audio streams, but in some cases, it was impossible to demux the subtitles correctly. It's because in some 3DBDs (notably Avatar), the same subtitles are present with the same stream ID in the M2TS of the AVC view and in the M2TS of the MVC view. Most of the times, the subtitles are present in the AVC M2TS only, but for a reason I have never understood, there are exceptions. Since eac3to tries to demux the SSIF file (containing the AVC and MVC M2TS files joined together), it finds two different streams with the same ID, and it tries to demux them as one single stream. Of course, that cause numerous conflicts. Luckily, tsMuxeR 3D has not the same problem, and it can demux the subtitle streams correctly even in that precise case. Therefore, I suspect that perhaps the demuxer you have used may be the culprit. Anyway, if you have used eac3to, try tsMuxeR. (This apply only to the 3DBDs, but perhaps there are other problems when demuxing the 2D BDs too.)

[an3k]

First of all thank you very much for feedback!I can perhaps explain why you have timing differences. The first reason is that BDSup2Sub re-arranges the timings to be in sync with the frames of the video stream. For example, the end time in your first example (01:10:03.757) is probably not exactly the time code of a specific video frame at 23.976fps. Therefore, it rounds it to the nearest frame, and that gives 01:10:03.760.Can this be turned off somehow?

The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). Note the terrible syntax: 24p doesn't mean 24fps, but 23.976! You have already the example of 2 bugs: the necessity to add the options to convert the frame rate to NOT convert it, and the discrepancy in the syntax of the frame rate. But if you use BDSup2Sub.jar from the CLI, it is possible to obtain correct results. (The rounding of the time codes will occur anyway, but it's not really a bug.) I suppose that you can play with the frame rate option in the first window of the GUI to obtain the same result, but I have never tried.I never used the CLI before but now I tried by following your advise. I ran C:\Program Files x86)\BDsup2sub>java -jar BDSup2Sub.jar --convert-fps 24p,24p --output C:\temp\temp.xml C:\00802.track_4612.sup and it created a new xml and plenty of png files. I compared the xml with the one I created with the GUI and the timings are exactly the same.
Whenever I used the GUI to load a BDsup I manually set "FPS Target" to 23.976 since it defaults to 25. BDSup2Sub.jar doesn't convert FPS when you export to BDsup but when exporting to eg. PNG/XML (I never tried the other formats) even when the "Change frame rate" checkbox is NOT checked.

I don't know why subtitle #712 is not visible. Indeed, it's a big problem. I know that some BD subtitles have special effects like fades that can confuse BDSup2Sub, and it's probably why BDSup2Sub++ generates several images instead of only one. The Java version is supposed to drop the invisible images and retain only the "best" one. Maybe there is another bug here and it keeps the fully transparent image?Even the Qt version is having problems with the BDsup and eg. frame 712. It says its position is something like -2235234,-3425634 and when I open the "Edit Frame" window a memory leak happens. It constantly uses 25% CPU and eats up RAM up to 2 GB before it finally gets closed by Windows because it doesn't "respond". However, exporting is working fine.

I don't use Subtitle Edit with BD3D2MK3D, simply because it cannot do what I need, and anyway, most conversions cannot be done from the CLI. But I like it when I need to convert manually a text based subtitle stream to BD SUP. As far as I know, it has no bugs.

I wonder if it is justified to accuse BDSup2Sub of all problems you have had. As explained above, the timing problem is certainly a bug, but it can be solved. However, the other problems (such as the invisible subtitle or the multiple PNGs produced by the ++ version) are probably due mainly to your stream. According to the numerous error messages, that stream is seriously damaged. And that reminds me something I have discovered when I have converted Avatar 3D for the first time.Well, neither BDSup2Sub++ nor Subtitle Edit is showing any errors. It's just the Java version. And I do not use the Avatar 3D, I use the 2D Blu-ray!
At that time, BD3D2AVS (as it was called then) was using eac3to to demux the 3D MPLS. That worked well for the video and audio streams, but in some cases, it was impossible to demux the subtitles correctly. It's because in some 3DBDs (notably Avatar), the same subtitles are present with the same stream ID in the M2TS of the AVC view and in the M2TS of the MVC view. Most of the times, the subtitles are present in the AVC M2TS only, but for a reason I have never understood, there are exceptions. Since eac3to tries to demux the SSIF file (containing the AVC and MVC M2TS files joined together), it finds two different streams with the same ID, and it tries to demux them as one single stream. Of course, that cause numerous conflicts. Luckily, tsMuxeR 3D has not the same problem, and it can demux the subtitle streams correctly even in that precise case. Therefore, I suspect that perhaps the demuxer you have used may be the culprit. Anyway, if you have used eac3to, try tsMuxeR. (This apply only to the 3DBDs, but perhaps there are other problems when demuxing the 2D BDs too.)I used the latest tsMuxer to extract the BDsup from the MPLS/M2TS.

I also experienced another bug. I open the original BDsup in the java version and export it as PNG/XML. The entry for the first frame is <Event InTC="00:00:39:18" OutTC="00:00:42:01" Forced="False">
<Graphic Width="1079" Height="62" X="416" Y="825">orig_0001.png</Graphic>
</Event>
Now I open that XML in BDSup2Sub.jar and export it as PNG/XML again. The entry for the first frame is now <Event InTC="00:00:39:18" OutTC="00:00:42:01" Forced="False">
<Graphic Width="1077" Height="60" X="417" Y="826">new_0001.png</Graphic>
</Event>
I also have to restart BDSup2Sub.jar (or "Close" the loaded BDsup) after exporting because otherwise it doesn't actually use the XML data but the BDsup data.

Is the Java or Qt version still maintained or if not is there any other tool which I can use to modify BDsup files?

[r0lZ]

As far as I know, the development of the two versions has stopped. However, the source files are available, and it should be possible to continue to develop at least one of them, if someone is interested. It's not my case, sorry.

Thanks anyway for your comments.

I don't think that it is possible to turn off the rounding of the time codes.

The fact that the command line with the --convert-fps option gives the same result than the GUI is strange. Honestly, I don't understand. Have you verified if the frame rate in the XML is correct?

The absurd X/Y positions you've seen in BDSup2Sub++ is also a known bug of that version. And I remember I have had many problems to capture the error messages of BDSup2Sub++ (when using the CLI). It uses a strange method that redirects the messages to a window. I have reported that problem to the author, but he has assured me that it's a QT "feature", and that there is no way to use the stderr stream "normally". Anyway, it's perhaps why you can't see the error messages in the GUI. And Subtitle Edit may be much more tolerant than BDSup2Sub. I don't know.

For the difference of 1 pixel of the width and height of the bitmaps, it's probably because the subtitles are not cropped exactly the same way with the two versions. Have you verified if the width and height of the XML corresponds to the real size of the PNG?

[an3k]

As far as I know, the development of the two versions has stopped. However, the source files are available, and it should be possible to continue to develop at least one of them, if someone is interested. It's not my case, sorry.Ok, maybe I'll take a look once I've finished my current project. Depends on how well the code is written. However, I'll only be able to develop the Java version since I have no clue how to do the Qt C++ stuff.

Thanks anyway for your comments.

I don't think that it is possible to turn off the rounding of the time codes.

The fact that the command line with the --convert-fps option gives the same result than the GUI is strange. Honestly, I don't understand. Have you verified if the frame rate in the XML is correct?Yes, framerate is correct in the XML. Maybe the XML/PNG specification doesn't support the time format used by BSsups (hh:mm:ss.sss) but only its own (hh:mm:ss.ss) so BDSup2Sub has to convert and thus round the times. BUT if you compare the timings of a BDsub and those of an previously extracted XML opened in another BDSup2Sub instace, the timings are identical. So either the XML spec doesn't support the more exact timings (down to 1 ms) and BDSup2Sub is aware of that and converts the timings accordingly when exporting to XML and as well when loading an XML OR this timings convertion is BDSup2Sub specific. The later would be really annoying.

The absurd X/Y positions you've seen in BDSup2Sub++ is also a known bug of that version. And I remember I have had many problems to capture the error messages of BDSup2Sub++ (when using the CLI). It uses a strange method that redirects the messages to a window. I have reported that problem to the author, but he has assured me that it's a QT "feature", and that there is no way to use the stderr stream "normally". Anyway, it's perhaps why you can't see the error messages in the GUI. And Subtitle Edit may be much more tolerant than BDSup2Sub. I don't know.[QUOTE]At least BDSup2Sub++ can export the pictures. With the help of both versions and Notepad I was able to fix my BDsup completely.

[QUOTE=r0lZ;1727459]For the difference of 1 pixel of the width and height of the bitmaps, it's probably because the subtitles are not cropped exactly the same way with the two versions. Have you verified if the width and height of the XML corresponds to the real size of the PNG?I didn't compared the two versions. I opened the BDsup in BDSup2Sub.jar and exported as XML/PNG. Then I closed the program, reopened it, loaded the previously extracted XML and exported it again. I compared these two XML versions both made by BDSup2Sub.jar. However I identified why there is a difference.
When opening a picture based subtitle file BDS2S.jar scans the pictures for non-alpha content and places that green border around it. Based on that the picture size is calculated. But BDS2S.jar leaves a 1 pixel space around the actual non-alpha content, identifying a picure as eg. 200x100. If you now export and open that exported version BDS2S.jar scans again but this time it doesn't (or maybe can't) leave a 1 pixel space around, thus identifying the same picture as 198x98. However, it correctly adjusts the position of the picture so a 200x100 picture located at 800x800 will result in a picture of 198x98 located at 801x801. The subtitle is actually at the same position.

How I repaired my broken BDsup file:

Opened the original BDsup in BDSup2Sub.jar GUI and made sure "FPS Target" is set to the correct FPS of the subtitle file.
Exported as XML/PNG to eg. C:\movie_orig\orig.xml
Opened the original BDsup in BDSup2Sub++ GUI and made sure "FPS Target" is set to the correct FPS of the subtitle file.
Exported as XML/PNG to eg. C:\movie_qt\qt.xml
Moved everything in C:\movie_qt\ into C:\movie_orig\
Opened C:\movie_orig\orig.xml in Notepad and C:\movie_qt\qt.xml in another Notepad instance.
In orig.xml I searched for each appearance of "1920" to find the malformed subtitle pictures and copied the correspoding line from qt.xml, overwriting the one in orig.xml
orig.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0165.png</Graphic>qt.xml
<Graphic Width="757" Height="125" X="587" Y="788">qt_0165_0.png</Graphic>
If qt.xml had more than one png file for a frame I had to manually check with Windows Explorer to find the correct png file.
However I also had these three entries
orig.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0710.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0712.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_1085.png</Graphic>
</Event>qt.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_0711_0.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_0713_0.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_1089_0.png</Graphic>
</Event>
so I had to fix these too but differently than before.
Opened orig_0710.png, orig_0712.png and orig_1085.png in a simple image viewer to see if these pictures contain actual non-alpha content (subtitle text) or are 100% empty. If a picture is empty I replaced just the filename in orig.xml with the one from qt.xml. In my case only orig_0712.png is empty, thus I replaced
orig.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0712.png</Graphic>withqt.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">qt_0713_1.png</Graphic>
I also checked qt_0713_0.png and qt_0713_1.png for its content. qt_0713_0.png is 567x102 but in the XML 1920x1080 is specified, thus I used qt_0713_1.png which is 1920x1080.
Saved the orig.xml and closed everything
Opened orig.xml with BDS2S.jar GUI
Checked for the three malformed frames 710, 712 and 1085 and all are correctly read by BDS2S.jar GUI but only frame 712 is not correctly placed (because neither BDS2S.jar nor BDS2S++ were able to a) write the correct position into the XML or b) write a 1920x1080 png file with the non-alpha content at its correct position).
Manually edited the frame 712 to match the position of frame 710.
Exported as XML/PNG to eg. C:\movie_final\final.xml
Opened C:\movie_final\final.xml in Notepad and checked the three malformed frames
final.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="800" Height="92" X="563" Y="806">final_0710.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="553" Height="69" X="686" Y="806">final_0712.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="561" Height="92" X="686" Y="806">final_1085.png</Graphic>
</Event>
Everything is fine now!

[r0lZ]

I see. Not easy to do that manually! Maybe if you have to do that several times, you should fix the source code instead. That will tale less time! ;-)
Seriously, if you decide to work on the source, please let me know. I know also a couple of bugs related to the palette generated for the VobSub format, and I have some suggestions.
Thanks in advance!

[cool_snoopy]

The revolution of a dvb ts is 1920x1080.
I rip sup and idx/sub from ts with projectx, but BDSup2Sub cannot load the sup file directly, the error message is "Offset xxxx out of bound..."
After I rename the corresponding IFO file as the sup file, BDSup2Sub can load the sup file with many warnings, and the revolution is 720x576.
How to load the ripped sup file with BDSup2Sub? Or How to rip sup from dvb ts at original revolution?
Thank you very much.

[Ghitulescu]

The IFO is not related to the HD subtitles if this is what you wanna know. The IFO is a convenience file put there to help the future processing of the SD (standard definition) subtitles, in particular the colours.

These being said I do not go into the nasty job of asking you if you know how to extract the HD subtitles with ProjectX. I assume you know it :)

[cool_snoopy]

The language of TS is Traditional Chinese
Sup is ripped by PorjectX
BDSup2Sub cannot load the sup file, the error message is "Offset xxxx out of bound..."
Not only BDSup2Sub, but also BDSubEdit and SupRip cannot load the sup file
I tried several TS files, only got the same errors

[Ghitulescu]

I then suggest you to learn first how to extract the subtitles with ProjectX. I did and still do this and there are no problems at all.

But this is off-topic.

[cool_snoopy]

Allow me to describe more clear.
The subtitle is shown in traditional Chinese. It's DVB subtitle, not DVB teletext

General
ID : 1 (0x1)
Complete name : H:\v\HDJ.Last.Paradise.S5.EP01.2011.HDTV.1080i.H.264.AC3.5.1.ts
Format : MPEG-TS
File size : 2.19 GiB
Duration : 24mn 42s
Overall bit rate mode : Variable
Overall bit rate : 12.7 Mbps

Video
ID : 851 (0x353)
Menu ID : 85 (0x55)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=12
Codec ID : 27
Duration : 24mn 42s
Bit rate : 11.5 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.221
Stream size : 1.98 GiB (90%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Limited

Audio #1
ID : 852 (0x354)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 24mn 42s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1s 128ms
Stream size : 33.9 MiB (2%)

Audio #2
ID : 853 (0x355)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 24mn 42s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1s 150ms
Stream size : 67.9 MiB (3%)

Text #1
ID : 855 (0x357)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : Chinese

Text #2
ID : 856 (0x358)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : English

Text #3
ID : 857 (0x359)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : chs


No matter which export format I select on Subtitle Setting tab, ProjectX only create sup file. If I check "additional export as VobSub", ProjectX will also create standard VobSub. I use BDSup2Sub to load the sub file, the shape looks much different with the subtitle shown during playing. I upsize it to 1280x720 and export, the exported sub is very ugly and unacceptable, this maybe because the shape looks different.
BDSup2Sub, BDSubEdit and SupRip cannot load the sup file ripped by ProjectX. SupViewer, Subtitle Edit and BDSup2Sub++ can load the entire sup file, SupRead can only load first frame, they all assume the revolution to be 720x576. Even though I check "enable HD subtitle", those softwares still assume the same revolution.
If I use BDSup2Sub to load the ripped sub, upsize it to 1280x720 and export it to sup, all the softwares above can load the entire exported sup, except SupViewer, it showes error message.

All I want to do are the following things
1. Rip sup from ts at original revolution and shape
2. Load the sup file with BDSup2Sub, downsize it to 1280x720 and export it to sub

So all I want to know is how to rip standart sup from ts at original revolution, that's why I post another thread first

[foxyshadis]

You already have the Sup files in original resolution, that's what it imports. BDSup2Sub converts Blu-ray subtitles to DVD subtitles, what other behavior would you expect? DVD SUB files are always DVD resolution. Only saving to Sony BDN XML will retain full resolution, after which you can batch process all the png files down to 1280x720 and convert them back to SUP.

Are you sure you wouldn't rather just convert them to text subtitles and forget the resolution problems?

[DoctorM]

I was taking a look at Avatar (the 2D Collector's Edition with the 3 versions).
I found that v5.1.2 shows blank frames with "WARNING: Problems during RLE decoding of picture OBJ at offset 0x003e1c0e" for anything in the Navi font.

v5.0 and ++1.0.2 work just fine. Something has definitely gone wrong with the newer versions of BDSup2Sub.
I know this has been discussed, but is anyone looking into it?

[an3k]

I was taking a look at Avatar (the 2D Collector's Edition with the 3 versions).
I found that v5.1.2 shows blank frames with "WARNING: Problems during RLE decoding of picture OBJ at offset 0x003e1c0e" for anything in the Navi font.

v5.0 and ++1.0.2 work just fine. Something has definitely gone wrong with the newer versions of BDSup2Sub.
I know this has been discussed, but is anyone looking into it?I hadn't the time yet, sorry. I'll post any news into this thread so you should subscribe to get an email ;)

[DoctorM]

I hadn't the time yet, sorry. I'll post any news into this thread so you should subscribe to get an email ;)

Already am. Thanks.

[Rudde]

Any way to get higher resolution timestamp on the xml output?

[ScottJ]

Any way to get higher resolution timestamp on the xml output?

It already includes the exact frame number (the last number in the timestamp). Can't get any higher resolution than that.

[r0lZ]

Yes, the timecodes in the XML are in the form HH:MM:SS:FF, where FF is a number of frames, not a fraction of a second. There is no way to be more precise than that.

However, the timecodes displayed in the GUI, are in the form HH:MM:SS.sss, where SS.sss is a floating point. And IMO it is extremely difficult to understand what BDSup2Sub does when it converts the input frame rate to the frame rate displayed in the GUI. Usually, they do not match at all. And it's not simply a precision problem. There is obviously a bug here, but increasing the precision will not fix it.

For example, if the XML timecode is 01:27:38:11 at 23.976fps, the frame number is 5258 seconds * (24/1.001) + 11 = 126077. Converted back to a timecode, still at 23.976fps, that gives 126077 / (24/1.001) = 5258.4617 seconds = approximately 01:27:38.462. But in the GUI, the time code displayed is 01:27:43.716 !!! It is obviously completely wrong ! It seems that BDSup2Sub does ALWAYS a framerate conversion, even when that option is not enabled.

Anyway, we have to live with that terrible bug, since BDSup2Sub is not developed any more.

[Rudde]

I didn't know the last FF was frame, and it seems to be difficult to convert to srt compatible format since it also does not extract fps correctly.

I did really try to parse the BDsup myself but I'm quite stuck on it because there is literally no complete documentation on it and it's so frustrating. I'm trying to make an online recourse for OCR and QA of BD (and hopefully DVD and HDDVD too some day) and make it crowdsourced.

Also; will FF = 01 be the first frame as the defined second?

[r0lZ]

No, I think that the first frame is 00. In other word, at 25 fps (PAL), FF is between 00 and 24.

Not sure what you mean with "it also does not extract fps correctly". IMO, the fps is correct in the XML. It's when it loads the XML that the frame rate is wrong. I think it assumes always 25 fps, instead of the fps in the header of the XML, although it displays correctly the source FPS in its first window. I suppose that this bug should be easy to fix. What you want to do is much more complicated.

Good luck anyway.

[Rudde]

So I ran 3 BD sups trough it now, one 24/1.001 fps, 24 and 25 fps and the xml reports the correct playback time played back at original framerate but it always report 25 fps i XML, that will be significantly off by last caption on 24/1.001 fps but yet insignificant if you only use the FF data as frame accurate.

[r0lZ]

Sorry, I don't understand. What do you mean with "but it always report 25 fps i XML" ?

[Rudde]

Sorry, I don't understand. What do you mean with "but it always report 25 fps i XML" ?

In the XML you have this line

<Format VideoFormat="1080p" FrameRate="25" DropFrame="False"/>

It will be FrameRate="25" regardless of the actual frame rate.

[r0lZ]

Ah, OK. I didn't know that. In BD3D2MK3D, when an XML is created from a SUP at 23.976 fps, the real output frame rate is specified in the command line, and it is correctly written in the XML. But it seems that BDSup2Sub considers it still as 25 fps.

Anyway, your finding confirms that there is a very big bug here. Not sure if the same bug exists with other formats (BD SUP or DVD VobSub).

[Kez]

<snip>The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). <snip>

I can confirm the bug also exists in the GUI where you have to set the target frame rate to avoid a conversion to 25fps which it defaults to on every start up. The input frame rate seems ok though and always matches source in my experience. YMMV

As for a command line option to work around the bug, you are better off using --fps-target keep on either the CLI or on the shortcut icon command line. This ensures that the target frame rate matches the source, just in case you load a non 23.976 fps sup...

-kez

[r0lZ]

Welcome to the Doom9 forums, Kez.
Thanks for the confirmation ant the --fps-target keep hint.

[Kez]

Thanks for the welcome r0lZ.

One question:
Does anyone know if BDSUP2SUB and the ++ version are in sync in terms of bugfixes and features?
Obviously I'd like to use whichever one is more up-to-date in that regard, but it wasn't exactly clear to me from the info on GitHub.

Thanks!

[r0lZ]

Some bugs are present in both versions (the frame rate of the XML/PNG and the badly built palette when converting to DVD SUB for example). But IMO, the java version is better. The ++ version has at least one additional bug. When a BD SUP is converted to XML/PNG, some subtitles are converted as several pictures instead of only one, and some of them are totally black. The converted XML stream cannot be reloaded in BDSup2Sub++ itself ! Also, the development of the ++ version has been very rapid and promising, but has stopped abruptly after only a few months. Therefore, it has not been tested as extensively as the java version. However, when the ++ version works fine, I prefer it. It is much more rapid, and it doesn't require the overhead of java. But personally, I use almost always the java version, for security purpose.

Note also that the syntax of the command line is somewhat different for the two versions.

[LigH]

Documentation
The complete documentation is available from the help menu inside the application. You can also read it online (http://bdsup2sub.javaforge.com/help.htm).

Unfortunately, this link is forwarded to https://codebeamer.com/cb/wiki/938267help.htm now, and anonymous reading is not allowed here, you need to create an account before even reading.

Is this tool able to batch-edit palette entries of subtitles in a Blu-ray SUP stream (e.g. set the opacity of the background of all subtitles in this stream to 0) and save the result in the same format?

[r0lZ]

I don't think so. Personally, for this kind of job, I convert the SUP to XML/PNG with BDSup2Sub (java version), then I batch-edit the PNG files with Image Magick or a good image editor (with batch support of course), and finally I recreate a new SUP from the edited XML/PNG, again with BDSup2Sub.

Take care! BDSup2Sub assumes ALWAYS 25 fps by default when it reads a XML/PNG stream, so be sure to specify that you want to convert the FPS from 23.976 to 23.976 fps in the little window that appears when you load the XML. That seems stupid, but it's the only workaround for that nasty frame rate bug.

[Ghitulescu]

The question above was intended on my behalf, as not receiving any answer here for a long time, I also asked it in the German forum. Apparently proper handling of subtitles never was a hot issue here.

This is actually what I did, demuxing into elementary bitmaps, editing them, then recomposing them back. The author suggested to go by DVD subs, where such editing tools exist, then converting them back to BD subs.

But thanks for the tip concerning BDSupToSub and 25fps, I never noticed it, maybe because I muxed directly the XML+PNG in tsmuxer.

[r0lZ]

Yes, editing the colors or transparency of DVD subs is easy, but it is a pity to have to reduce the colors to 4 and the transparency to 16 levels and lose the quality of the original BD SUP just to edit it!

For the frame rate bug, afaik it happens only when BDSup2Sub (java or ++) loads the XML/PNG stream, regardless of the frame rate included in the XML file. But I use the FPS conversion trick anyway, even when I load another format, just to be sure. With that trick, I have never experienced any sync problem.

[Bandits]

Yes, the timecodes in the XML are in the form HH:MM:SS:FF, where FF is a number of frames, not a fraction of a second. There is no way to be more precise than that.

However, the timecodes displayed in the GUI, are in the form HH:MM:SS.sss, where SS.sss is a floating point. And IMO it is extremely difficult to understand what BDSup2Sub does when it converts the input frame rate to the frame rate displayed in the GUI. Usually, they do not match at all. And it's not simply a precision problem. There is obviously a bug here, but increasing the precision will not fix it.

For example, if the XML timecode is 01:27:38:11 at 23.976fps, the frame number is 5258 seconds * (24/1001) + 11 = 126077. Converted back to a timecode, still at 23.976fps, that gives 126077 / (24/1001) = 5258.4617 seconds = approximately 01:27:38.462. But in the GUI, the time code displayed is 01:27:43.716 !!! It is obviously completely wrong ! It seems that BDSup2Sub does ALWAYS a framerate conversion, even when that option is not enabled.

Anyway, we have to live with that terrible bug, since BDSup2Sub is not developed any more.

I thought the time codes were:

FF - milliseconds
0 - 000
1 - 040
2 - 080
3 - 120
4 - 160
5 - 200
6 - 240
7 - 280
8 - 320
9 - 360
10 - 400
11 - 440
12 - 480
13 - 520
14 - 560
15 - 600
16 - 640
17 - 680
18 - 720
19 - 760
20 - 800
21 - 840
22 - 880
23 - 920
24 - 960

I could be wrong but its always worked for me. I seem to remember testing by exporting and importing using the above conversion and the times remained correct.

Edited typo on numbering.

I always use --fps-target keep and the above numbers work for all FPS.

[r0lZ]

@Bandits: There is a bug in your list of time codes. Frame 15 is missing, For 25fps, if the first frame is frame 0, frame 24 is the last frame in the same second, not frame 25.

And anyway, your timings are correct only for PAL at 25fps. BDSup2Sub is always correct when it deals only with streams at 25fps, since it's the frame rate that it assumes (wrongly) always. The bug happens only when it loads streams at other frame rates (film at 24fps, NTSC at 23.976 or 29.97fps or other exotic frame rates), if you don't specify explicitly to convert the frame rate to itself.

[DMD]

Good morning
I ask if you can include the subtitle management 4K resolutions.

Thank you

[hubblec4]

When I use the cli (BDSup2Sub 5.1.2) to convert a DVD-sup to IDX/Sub and I use the "--language de" switch or any other language code, always "English en" is set in the idx for the language.
Is this a known bug?

[r0lZ]

It works fine for me, and I use the same version.

My command is:

java -Xmx256m -jar D:\work\BD3D2MK3D\toolset\BDSup2Sub.jar test.sup -o test\test.xml --language de


There are some bugs in BDSup2Sub, especially with the XML+PNG format. For example, the frame rate is systematically 25 fps when converting from XML+PNG to another format (with the CLI or the GUI), unless you specify explicitly another frame rate. But as far as I know, the language code is correctly handled.

Note also that BDSup2Sub supports only the ISO 639-1 codes (2 lower case letters). It doesn't support more recent ISO codes (with 3 or 4 letters). But since you have used "de", that should work. Are you sure that the --language argument is after the input and output file names?

[hubblec4]

My command is:

java -Xmx256m -jar D:\work\BD3D2MK3D\toolset\BDSup2Sub.jar test.sup -o test\test.xml --language de

Are you sure that the --language argument is after the input and output file names?

In the usage-description there are "options" before the in-out files.
I try it with --language at last position and it does not work.
With the Windows version it works but not with the java-version.

"C:\java.exe" -jar "D:\BDSup2Sub.jar" "F:\Subpictures_23.ifo" -o "F:\Sub Pic23.sub" --language aa


here a sample (http://forum.gleitz.info/attachment.php?attachmentid=99341&d=1493129925)

[r0lZ]

Oh, yes, with your sample, I can reproduce the bug. The difference is that in my previous tests, I've used a BD SUP file. You convert a DVD SUP file (+IFO).

I did not know that problem, but anyway, we have to live with it. Luckily, if you convert to XML+PNG, it is easy to edit the XML file to change the language code. I don't think there is another solution.

And take care with BDSup2Sub++.exe. It has a lot of bugs, even if it doesn't have this one! And it is abandoned too.

[hubblec4]

Oh, yes, with your sample, I can reproduce the bug. The difference is that in my previous tests, I've used a BD SUP file. You convert a DVD SUP file (+IFO). Yes DVD-sup!


I did not know that problem, but anyway, we have to live with it. Luckily, if you convert to XML+PNG, it is easy to edit the XML file to change the language code. I don't think there is another solution.
In my old DVD2mkv-editor I have created a workaround for this bug, but for german langauge only. Now I see every language fails and I will extend my work-around. It is a very simple procedure which change the "id: entry"(and "alt: entry") in the idx-file.

I hope this is enough to solve this issue.



And take care with BDSup2Sub++.exe. It has a lot of bugs, even if it doesn't have this one! And it is abandoned too.

Is there a list of this known bugs?
Like in your PGC2mkv-plugin I would have the choice between this two versions.

[r0lZ]

I don't think there is a complete list, but I know that in many cases, when it converts a BD SUP to XML+PNG, it creates several images for the same subtitle, and some are totally black. It cannot reload the XML it has produced itself! (I think that that bug occurs when there are fades in the subtitle stream. Something very rare, if not impossible, for the DVD SUP, so don't worry too much.)

It has also the bugs of the java version, including the problem of the wrong time codes when it loads an XML/PNG stream. It forces 25 fps anyway.

[hubblec4]

Why convert you to XML/PNG? This step I have never used.

I have no problems with converting dircet to idx/sub.

[r0lZ]

For most users, the main advantage of XML/PNG is that it is easy to edit, for example to darken too bright subtitles. Personally, I need that format for BD3D2MK3D, to convert the subtitles to 3D (SBS or T&B). It's also a format needed to import the subtitles in some authoring programs.

[Bandits]

Is there a list of this known bugs?

I know I have had issues with 5.1.2 with detecting all subtitle events (Avatar). I have reverted back to 4.0.0 and it seems to be the best for my needs.

If I could understand the subtitle events a little better inside the extracted stream I would write my own editor. I tried to follow the information in this thread and SUPread but it seems to be incomplete. I can get the event information but extracting the png does not make sense to me.

[Scorpius666]

Thanks to this wonderful thread I have found that versions of BDSup2Sup higher than 5.0.0 will lose 15% of the subtitles (totally unusable), but versions 5.0.0 and lower will only lose 1% if any.

Since it still loses a couple of subtitles, I have decided to implement one of the two things missing in BDSub2Sup that makes it lose subtitles.

Basically BDSup2Sub didn't implement two things:

Complex compositions. This is when two or more subtitles are shown at the same time. A warning is shown that multiple ODS are defined and only one subtitle will be recognized.
Cropping. BluRay subtitles support showing a piece of the image each time, so a line like "Ok! Let's do it" can be shown like "Ok!" first and then "Ok! Let's do it".


The second item is not that terrible. You will only lose the "animation" of the subtitle being shown few words at a time.

But the first item is a big problem. This usually happens when a subtitle is being shown and then another one has to appear, for example a foreign sign have appeared in the screen and the person hasn't finished talking. Since compositions are very common they must be implemented.

So that's what I did here: https://github.com/naikel/BDSup2Sub/tree/enhanced

Also I tried to give a better explanation how PGS works here: http://blog.thescorpius.com/index.php/2017/07/15/presentation-graphic-stream-sup-files-bluray-subtitle-format/