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

[SassBot]

Moderator Note: As paradoxical has assumed responsibility for continued development of this tool, the discussion is moved to:

http://forum.doom9.org/showthread.php?p=1613303

and this thread is closed. Thank you, SassBot, for your work and thank you, paradoxical, for your willingness to assume responsibility.

----- [resume original SassBot posting]

So as to separate from the other BDSup2Sub thread, I am creating a separate thread for my port BDSup2Sub++. For anyone who hasn't been following this is a port of the original BDSup2Sub to C++/Qt that I did in hopes of reviving what was a stagnating project. It has all the same functionality as the original version with some additional fixes and enhancements (such as proper support for importing SUB/IDX with multiple languages). If you have any issues or enhancement requests please post them in this thread or here (https://github.com/amichaelt/BDSup2SubPlusPlus/issues). The CLI syntax has been modified and is listed below.

Usage:

BDSup2Sub++ 1.0.0 0xdeadbeef, mjuhasz, Adam T.
Syntax:
bdsup2sub++ [options] -o outfile infile

Options:
-h, --help List options
--load-settings Set to load settings stored in INI file.
--resolution x Set resolution to 480, 576, 720 or 1080. Default: 576.
Supported values: keep, ntsc=480, pal=576, 1440x1080.
--fps-source x Synchronize source frame rate to <x>. Default: auto.
Supported values: 24p=23.976, 25p=25, 30p=29.967.
--fps-target x Convert the target frame rate to <x>. Default: keep.
Supported values: 24p=23.976, 25p=25, 30p=29.967.
--delay x Set delay in ms. Default: 0.0.
--filter x Set the filter to use for scaling. Default: bilinear.
Supported values: bilinear, triangle, bicubic, bell,
b-spline, hermite, lanczos3, mitchell.
--palette-mode x Palette mode: keep, create, dither. Default: create.
--minimum-time x Set the minimum display time in ms. Default: 500.
--merge-time x Set max time diff to merge subs in ms. Default: 200.
--move-in-ratio x Move captions from inside screen ratio <x>.
--move-out-ratio x Move captions from outside screen ratio <x>.
--move-y-offset x Set optional +/- offset to move captions by.
--move-x x Move captions horizontally from specified position.
Supported values: left, right, center, origin.
--move-x-offset x Set optional +/- offset to move captions by.
--crop-y x Crop the upper/lower n lines. Default: 0
--alpha-crop x Set the alpha cropping threshold. Default: 10
--scale-x x Scale captions horizontally by factor. Default 1.0.
--scale-y x Scale captions vertically by factor. Default 1.0.
--no-export-palette Do not export palette file.
--export-palette Export target palette in PGCEdit format.
--forced-only Export only forced subtitles.
--force-all x Set or clear the forced flag for all subpictures.
Supported values: set/clear.
--swap Swap Cr/Cb components.
--no-fix-invisible Do not fix zero alpha frame palette.
--fix-invisible Fix zero alpha frame palette.
--no-verbatim Switch off verbatim console output mode.
--verbatim Switch on verbatim console output mode.

Options only for SUB/IDX or SUP/IFO as target:
--alpha-thr x Set alpha threshold 0..255. Default 80.
--med-low-thr x Set luminance low/med threshold 0..255.
--med-hi-thr x Set luminance med/hi threshold 0..255.
--language x Set language to <n>. Default: de (Vobsub Only).
--palette-file x Load palette file <n>. Overrides default palette.

Output:
-o x, --output x Specify output file.

Wildcard support:
Use "*" for any character and "?" for one character in the source name
Use exactly one "*" in the target file name.
Example:
bdsup2sub++ --resolution 720 --fps-target 25p -o dvd_*.sub 'movie* 1?.sup'


Current version is 1.0.0 (17/7/2012):
Download link: here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100.7z).

Currently I only am providing Windows builds, but the source can be obtained here (https://github.com/amichaelt/BDSup2SubPlusPlus) if you want to build yourself. If anyone can provide OS X builds that would be great since I do not have access to a Mac, though you will need at least GCC 4.7.0 or some other compiler with support for all the C++11 features I use.

For Linux support, I am currently working to get this uploaded into Debian Testing. For Arch users, check this (https://aur.archlinux.org/packages.php?ID=60757&detail=1) out. I will also look into making packages for other distros as it is feasible due to the GCC version requirement.

[mood]

Thanks SassBot...

You have done a great job with this awesome tool.

[SassBot]

So I refreshed the 1.0.0 with a fix for what r0lz reported. Redownload if you have already have done so. The link is still the same as in the first post.

[r0lZ]

Happy to see the birth of v1.0! :-)

BTW, I've found another little bug. For whatever reason, I have now a BDSup2Sub++.ini file in my Windows\system32 directory. Perhaps when I did some CLI tests the CD was system32. Anyway, the default ini should always be saved in the installation dir (or in %appdata%).

[SassBot]

That's what happens. It's gets the directory of where the exe is running and saves it there.

I'm changing it so it uses %APPDATA% or on *nix platforms so that it saves to $HOME/.config. That'll be in the next version.

[mini-moose]

I think the download link is broken. It leads to 0 found on videohelp: "0 tool hits, Showing 0 to 0 tools"

[sl1pkn07]

https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100.7z

[SassBot]

I think the download link is broken. It leads to 0 found on videohelp: "0 tool hits, Showing 0 to 0 tools"

Yeah, link seems to be flaky. Sometimes works sometimes doesn't.

[mini-moose]

Supported values: 30p=29.967.

you mean 30p=29.970 (30000/1001) ?

Also, I think actual 24fps is missing (24.000 vs 23.976).

[SassBot]

you mean 30p=29.970 (30000/1001) ?

Yeah, just seems to be a typo carried over from the Java version. Thanks for spotting that.


Also, I think actual 24fps is missing (24.000 vs 23.976).

It's not missing. You just specify "24". 0xdeadbeef defined the '24p' as 24000/1001 and if you want 24.0 you just specify '24'. That's just from the code I absorbed. That list isn't meant to be the only values you can specify just a list of predefined shortcut values so you don't have to specify the rational values.

[mini-moose]

Thanks for spotting that.
It's not missing. You just specify "24".

great. yes, I looked at the gui and saw it has all the relevant fps choices. so the 24p/25p etc are just "shortcuts" to specifying the full number.

[mood]

Hi, SassBot...

I found a bug in version 1.0.0.

When I edit idx/sub created BDSup2Sub++ and use "Edit DVD Frame Palette" to set black background in one line...

In my TV not appears black background on line that I have set, but the problem with randomly background come back in many lines of subtitle.

Like this:
http://img99.imageshack.us/img99/9770/p1107121539.jpg


Here is the idx/sub with the problem:
http://www.mediafire.com/?91q982ruzbq2qze

The bug of randomly background in many lines back again. :(

Note: I use the same image, because the problem is the same

[SassBot]

Yeah, that's still on my list of things to nail down. I don't know why it came back. I'm busy with a few other projects at the moment, but I should begin new work by next week.

[qknet]

Dear SassBot,

I appreciate it when you decided to provide a non-java version.

I had my first try with the C++ version (the most up-to-date one), and it failed to load xml file (this one is handled perfectly by the java version). It says "First subpicture has timestamp of -00:00:15:857. Please specify proper delay value to correct this."

A part of the xml file is as follows:


<Description>
<Name Title="Subtitle" Content=""/>
<Language Code="vie"/>
<Format VideoFormat="1080p" FrameRate="23.976" DropFrame="false"/>
<Events LastEventOutTC="00:08:18:03" FirstEventInTC="00:00:31:20"
ContentInTC="00:00:00:00" ContentOutTC="00:08:18:12" NumberofEvents="49" Type="Graphic"/>
</Description>
<Events>
<Event Forced="False" InTC="00:00:31:20" OutTC="00:00:37:09">
<Graphic Width="1920" Height="1080" X="0" Y="0">00000764.png</Graphic>
</Event>
<Event Forced="False" InTC="00:02:56:07" OutTC="00:02:59:03">
<Graphic Width="1920" Height="1080" X="0" Y="0">00004232.png</Graphic>
</Event>
<Event Forced="False" InTC="00:03:41:19" OutTC="00:03:47:22">
<Graphic Width="1920" Height="1080" X="0" Y="0">00005324.png</Graphic>
</Event>
<Event Forced="False" InTC="00:03:56:13" OutTC="00:03:58:07">
<Graphic Width="1920" Height="1080" X="0" Y="0">00005678.png</Graphic>
</Event>
<Event Forced="False" InTC="00:04:02:13" OutTC="00:04:06:00">
<Graphic Width="1920" Height="1080" X="0" Y="0">00005822.png</Graphic>
</Event>

[SassBot]

Post the file and I'll look at it.

[qknet]

Post the file and I'll look at it.
Here you go. https://dl.dropbox.com/u/19135597/temp.rar

And, can you support idx/sub at 1080p?

[SassBot]

What do you mean? You can export Vobsub at 1080p. There is nothing additional to support.

[mini-moose]

the app crashes on a sup I tried to convert to vobsubs. It's a rather weird one. the old bdsup2sub handles it with tons of
fixing.

it can be found here:

http://www.mediafire.com/?zj86cr232ijlvfw

[SassBot]

Thanks. Will look into it. Been a bit busy with some other stuff (mostly getting distracted by watching Burn Notice and gaming) but I promise to start working on this again real soon. :) I have definitely not abandoned it.

[SassBot]

BTW qknet can you repost your file? The link isn't working.

[mini-moose]

The link isn't working.

hmm I just tried it and it's working fine but here's another anyway

http://www.sendspace.com/file/hszshq

[SassBot]

No, I was referring to qknet's dropbox link. I just get 404s from it.

[rakuen.now]

I just posted in the BDSup2Sub thread about how I fixed, at least on my system, the flashing bug for .sup(BD) output to tsMuxer when played back using XBMC. I don't know if anyone else is having this problem or is interested in fixing it. I looked up the code to the C++ version it looks very much the same as the Java version, so it should be afflicted the same way. Anyways, just a heads up in case anyone cares. If not, I'll go back under my rock...

[SassBot]

It's interesting to me. And, yeah, the code is pretty similar since it was a pretty straightforward port. I noticed you forked on github. If you send a pull request, I'll merge your fixes.

Right now, I'm doing some internal reorganization to cleanup some of the messiness of the port and restructuring things so that multithreading the writing out of files can be done (which at this point is basically impossible based on the current architecture carried over during the porting) so a new version will still be a bit off. I will get it out I promise. :) This cleanup will also allow me to write some unit tests to get decent code coverage to help squelch the regressions a bit due to the complexity of many areas of the code that cause weird cascading effects when you make what should be small changes.

[r0lZ]

I've noticed some bugs (or limitations) in BDSup2Sub++ 1.0.0.

In the "Move all captions" dialog, it is possible to move the captions horizontally from the original X position to the right (with a positive offset) or to the left (with a negative offset). That's fine. But the similar function to moye vertically from the original Y position works only with positive offsets. Therefore, it is not possible to move all captions up. Even positive offsets do not work well. Not sure why, but it's a pity. (I have not verified if it is possible to move the subtitles up with the command line.)

In the same window, it is possible to use the "crop bars" to restrict the move. If you use them, then apply the changes, you can see the subtitles at the correct position. But if you save the file and reload it, the subtitles are not where they should be. They are often under the crop bar (not visible any more). To permanently freeze the position of the subtitles, you must use "Reset crop offset" before saving. IMO, that's not very intuitive. Could you, at least, add a word of caution in the "Move all captions" dialog, or offer to reset the crop offset when saving?

Bug: In the window allowing you to move a single subtitle (available by clicking on the preview in the bottom right corner of the main window), the 4 buttons at the top (to save or cancel the edits and go to the previous or next subtitle) do not work.

[SassBot]

Hmm, weird. Okay, putting all those issues on the list of things to get fixed for 1.0.1. I know when I checked the move vertical that it supported positive and negative offsets but it's possible some other change to support other move options borked it since that code is a twisted mess. There's some behind the scenes math being done that can cause issues. As to the crop issue, you can just specify a 0 in the "crop offset Y" field to get the same effect as the "reset crop offset" menu option (unless I'm not fully understanding you) which I agree is a bit unintuitive. To the last issue, it seems that I just plain forgot to implement the functionality for the buttons. :o Don't know how I didn't spot that earlier.

Thanks again for the reports r0lz.

[r0lZ]

The crop bars are supposed to limit the vertical move in Y. For example, if I use a Move from original Y position with an intentionally big offset of 2000 and a crop value of 50, the subpics are moved to the bottom, but there will always be below them a margin of 50 pixels, due to the crop border. That works fine. If you type 0 to reset the crop border, the subpics will jump to the very bottom of the picture, and that's not what I want. So, I have to leave the crop border unchanged, and close the dialog. (Note that when the dialog is closed, the red lines are still visible, indicating that the crop border is "active".) So, now, it should be possible to save the subtitles, and they should stay where they are in the GUI, at 50 pixels of the bottom border. But that doesn't work. If you reload the subs, the crop border is gone, and the subpics are sticking to the bottom border. So, it seems that the crop border does not what it is supposed to do. However, I've found that if, after having closed the GUI window and before saving the file, I use the "Reset crop offset" menu, the subtitles are correctly saved at their visible position. IMO, that's counter-intuitive, as resetting the crop offset manually in the dialog (by entering 0) has the effect of disabling the crop border, but resetting it from the menu has exactly the opposite effect of "freezing" the subtitles. That may be the way it is programmed, but that's very strange and confusing.

Thanks for considering the two other issues.

[SassBot]

Does it do the same behavior in the original BDSup2Sub? That at least narrows it down to being a bug in the port.

[r0lZ]

Not sure. I'll verify...

[mbcd]

I have a short feature request:

I programmed my own "decoder" for PGS some times before, but had not enough time to do an "encoder" also ...

I need a function for "splitting" a PGS. That means:
I wanna do linked mkvs, so every mkv-part needs only a few subtitles.

My request is: Is it possible to implement a feature where you can specify a row of framenumbers as splitpoints, e.g. : 120, 15896, 24458, 225895, ...

Output gives you in this case 5 different pgs-files with subtitles that occour from frames:
0-120
121-15896
15897-24458
24459-225895
225896 - Subtitlefile-End

Every single pgs-File has to get a new calculated timecode that begins with "0", calculated from the offset where the split was to the first subtitleoccurance.

Mostly unused at this time, but I think that it will get more important in future with seamless branched titles.
Would be nice to get with cli too e.g.:
-split 120,15896,24458,225895 <- split the pgs but keeps original timecode
-split-resetTC 120,15896,24458,225895 <- split the pgs but resets original timecode at beginning of every file

[SassBot]

Okay. Add it to the github issues page (https://github.com/amichaelt/BDSup2SubPlusPlus/issues) and I'll look into it. :)

[mini-moose]

has dev stopped? or will resume when time allows it?

[hamedham]

thanks for this useful post
i searched for *.sub resizer in web but not any sites found
thank you "sassbot"

[jhon marvi]

BDSup2Sub is a tool I wrote initially to convert captions demuxed from a Blu-Ray transport stream (M2TS) into the DVD VobSub format (SUB/IDX) used by many DVD authoring tools - hence the name. Many more features were added over time as was support for other formats. So in the meantime the name seems a little inappropriate. In a nutshell, it's a subtitle conversion tool (for image based formats) with scaling capabilities and some other nice features.
:confused:

[TheShadowRunner]

Hi, I got 2 crashes with 2 SUP files (program crashes in ntdll.dll on XP SP3).
The SUPs can be found here (http://videoff7.free.fr/bdsup2sub_test.zip).
Hoping a fix is possible! Thank you.

[TheSkiller]

Hi guys,

I make my own DVD subtitles for my projects using Aegisub + avs2bdnxml + BDSup2Sub.

And so far I'm very pleased, the subtiles look very nice and this method enables me to take almost all the possibilities of ASS/Aegisub to DVD subtitles which is a HUGE relief. :)


Here's an example from the 16:9 subpic stream:
http://s3.imgimg.de/uploads/subpicexamplesmall77c05699png.png (http://s3.imgimg.de/uploads/subpicexample8f8cb7aepng.png)
(click for 720x574 full size)
I consider this almost perfect. Almost.
Something I have always wondered if it's possible to make it better is the outer edge of the outline, you know the transition between subpic and underlaying video (green here).

There tend to be those "rough" pixels, making the border a bit fuzzy. I noticed it seems to happen to the lowest part of any outline on a subpic mostly, in other words if there are two lines of text the upper one looks almost unaffected by it. Here's an illustration with 400% point-zoom:

http://s3.imgimg.de/uploads/subpicexampleproblem241f5a4dpng.png

I know the "Alpha Threshold" controls this border but it cannot fix it entirely, there are always some rough pixels somewhere, mostly at the bottom. And if I find a value which makes a single subpic look good, it makes others worse.
I mean it's not a huge deal but it keeps telling me my subpics aren't 100% perfect yet. :D :o
So, I keep scratching my head, either I'm doing something wrong or maybe it is some sort of bug in BDSup2Sub (happens with BDSup2Sub++, too, by the way)?
Would it be possible to add some mechanism that smooths the outline in terms of removing rough pixels?

If anyone feels like playing around, here's a ZIP containing the shown subtitle in XML + PNG format (output of avs2bdnxml).
http://www56.zippyshare.com/v/7044747/file.html (redundant, see edit)

The settings I used in BDSup2Sub:
Alpha Tresh: 20 | Med/Low Thresh: 96 | Hi/Med Tresh: 200
And important for my authoring, I use no cropping, by launching BDSup2Sub with /acrop:0

Output format is SUB/IDX.


Edit: Oh, well. I just found out the rough pixels at the bottom are caused by setting the Y font scaling in the ASS script to anything but 100%. So the problem was already in the PNG. At 100% it's gone, it's not a bug in BDSup2Sub. :o
But my question regarding a smoothing remains, as the alpha cropping in itself will still cause single rough pixels here and there which just look out of place.

Another Edit: I just realized such a smoothing algorithm to remove single stand-out pixels would be quite simple.
1) Check all the pixels of the final palletized subpic left to right individually and if the current pixel is [outline color] then check if the pixel left and right of it is [transparency color]. If both are, we have found such an unwanted pixel and can remove it by making it [transparency color].
2) Do the same in a vertical fashion, comparing the top and bottom pixel neighbours of all outline pixels.

[TheShadowRunner]

Since the main developer seems to have gone missing. I can look into it. What specifically were you doing to cause the crash? A step-by-step way to reproduce your crash would be great. :)Thanks for your reply, it's very simple:
I launch the program (with all default settings), and open one of the SUPs I linked. I then go to File > Save, chose "English" and it never reaches 100%, the program crashes halfway through. I think it just doesn't like something in those SUPs :/

[Selur]

anyone managed to compile BDSup2Sub++ on Linux?

[sl1pkn07]

https://aur.archlinux.org/packages/bd/bdsup2subplusplus-git/PKGBUILD
https://aur.archlinux.org/packages/bd/bdsup2subplusplus-git/bdsup2subplusplus-git.tar.gz

[Selur]

looked at the package but it only calls qmake and then make.
problem is if I run 'qmake bdsup2sub++.pro' and than 'make' on Lubuntu 64bit, I end up with a lot of complaints regarding ISO-C++ initialization.
Lubuntu 64bit uses gcc 4.6.3, which might be the cause of the problem,...
-> yup tried another VM with Kubuntu 64bit in it which uses gcc 4.7 and there it compiles.

[paradoxical]

Yeah, it uses C++11 features of GCC 4.7.x and higher. Clang 4.x would work too. I think the major issue is the non-static data member initialization. That's what bumps the requirements to 4.7.x.

[Selur]

I think the major issue is the non-static data member initialization.
yup. Thanks for the help.

[Music Fan]

Is this program able to convert DVB-SUB (sup extension) to sub/idx or other sup format (Blu-ray) ?
If not, could it be added ?
I know only one program able to make it, ProjectX, but it fails to do it correctly (colors and time-code problems).

[sneaker_ger]

Maybe:
Supported Formats

Blu-Ray SUP: Import (since 1.0) and Export (since 1.6)
Sony BDN XML: Import and Export (since 3.3.0)
HD-DVD SUP: Import (since 1.9)
VobSub (SUB/IDX): Import (since 3.5.0) and Export (since 1.0)
DVD-SUP (SUP/IFO): import and export (since 3.9.0)


I suggest you simply give it a try.

[TheShadowRunner]

paradoxical, any luck with these problematic SUP (http://videoff7.free.fr/bdsup2sub_test.zip)?
BDSup2Sub++ crashes during the convertion on my system :/

[paradoxical]

I've found where the issue is happening. It's a bit tricky figuring out why the problem is happening. I hadn't had a lot of time to debug it, but I'm working on it now.

[paradoxical]

Ok, I've located and solved the issue. Apparently there was a bug in doing a deep copy of an object that ended up having catastrophic effects down the line. Will post a fixed binary in just a few minutes after I email a patch to the original author.

[TheShadowRunner]

Wow this is awesome paradoxical, thank you VERY much for your time debugging this!

[Selur]

btw. while at it, it would be cool if the progress indication could be send to std::cerr instead of std::cout in command line mode. (std::cout get's delayed and this way monitoring the progress by watching the console output is a pain, since the progress only happens in large chunks,..)

[paradoxical]

Wow this is awesome paradoxical, thank you VERY much for your time debugging this!

Hehe, no prob. I was up for the challenge. :D The biggest challenge was adding enough log lines to isolate the issue. Once that was isolated it was easy to solve.

btw. while at it, it would be cool if the progress indication could be send to std::cerr instead of std::cout in command line mode. (std::cout get's delayed and this way monitoring the progress by watching the console output is a pain, since the progress only happens in large chunks,..)

Sure, it's a simple fix. I'll add that into the patch I make and will add that to the binary I make.