bdsup2sub++ - convert and tweak bitmap subtitles.

[paradoxical]

Creating a new thread since I've taken over maintaining so that all the new versions can be tracked in the first post and not lost in the previous thread.

CLI syntax is:

BDSup2Sub++ 1.0.2 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-origin x Move captions from the original vertical position.
Supported values: up, down.
--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-verbose Switch off verbose console output mode.
--verbose Switch on verbose console output mode.
--log-to-stderr Switch to change progress output to standard error.

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 v1.0.2 (2013/17/4):

Windows Binary:
v1.0.2: here (https://www.dropbox.com/s/jiw6r9qphcugs1r/bdsup2sub%2B%2B1.0.2_Win32.7z).
git snapshot build: *to be added later*.

OS X 10.7+ binary:
v1.0.2: here (https://www.dropbox.com/s/f8p9fgsxv9p6hej/bdsup2sub%2B%2B1.0.2_OSX.zip).
git snapshot build: *to be added later*.

For Linux support:

Arch users can get bdsup2sub++ from AUR (https://aur.archlinux.org/packages.php?ID=60757&detail=1).

For any other distro, you'll have to ask for your repo maintainers for support. Currently, I don't have the time to maintain packages.

Github repository is here (https://github.com/amichaelt/BDSup2SubPlusPlus).

For all requests for bug fixes and enhancements made in this thread, it would also be helpful if you can also post them to the issue tracker (https://github.com/amichaelt/BDSup2SubPlusPlus/issues) as well.

When reporting a crash or a bug, please provide a sample file and steps that can consistently reproduce the issue.

[Kurtnoise]

Hi,

Thanks for your work...I really appreciate.

I'm wondering if is there a way to change colors from BD sup files using this tool ? My input are sup from BD and my target are also sup files dedicated to BD but most of the time resized...

If not possible yet, may I ask this as a feature request ? :cool:

[mini-moose]

great to see you are carrying dev paradoxical!

I'm really no expert, in fact I know abosoutely nada.
I tried a sup file I had the sassbot versions crash on. Yours doesn't and it converts it to 1280x720 a lot faster than the old java versions did, but something is odd.
The vobsubs created by java 400 is 6.2mb while with new ++, only 1mb. I can't really see a difference in the result but it still seems weird :) running them on cmd also seems odd:

java ends with:
Decoding frame 1268/1269 at offset 0x01db9cb5
WARNING: fade out detected -> patched palette
Decoding frame 1269/1269 at offset 0x01dc060a
WARNING: fade out detected -> patched palette
There were 1048 warnings

++ new ends with:
Decoding frame 71/223 at offset 00c5820d
WARNING: fade out detected -> patched palette
Decoding frame 72/223 at offset 00c9e945
WARNING: fade out detected -> patched palette
There were 144 warnings
There were 157 warnings

you can try the sup file:

http://www.mediafire.com/?4yvedoe2ddnv8ca

[Music Fan]

Current version is 1.0.1 (28/1/2013):

Windows Binary:
Download link: here (https://www.dropbox.com/s/6429efffiwxlj7u/bdsup2sub%2B%2B.7z)
I tried it with a sup extracted from a Blu-ray and it crashed.:o

[Kurtnoise]

I tried it with a sup extracted from a Blu-ray and it crashed.:o
you should upload your file somewhere...it might help to debug or fix the crash.

[paradoxical]

I tried a sup file I had the sassbot versions crash on. Yours doesn't and it converts it to 1280x720 a lot faster than the old java versions did, but something is odd.

Probably due to a couple of bugs I fixed. Also, I did pretty extensive memory and performance profiling and fixes. So performance has dramatically improved. There's one more memory leak I still need to fix though, which I'll get in 1.0.2.

you can try the sup file:

http://www.mediafire.com/?4yvedoe2ddnv8ca

Okay, I'll check to see what the difference might be. It shouldn't be that dramatically different.

I tried it with a sup extracted from a Blu-ray and it crashed.:o

Okay. Without the file I can't really do much.

I'm wondering if is there a way to change colors from BD sup files using this tool ? My input are sup from BD and my target are also sup files dedicated to BD but most of the time resized...

If not possible yet, may I ask this as a feature request ? :cool:

Yeah it doesn't do BD sup color editing currently. But it can go on the list. :)

Edited to add:

OS X binary is now up. I finally fixed all the issues with my statically linked Qt.

[mini-moose]

Probably due to a couple of bugs I fixed. Also, I did pretty extensive memory and performance profiling and fixes. So performance has dramatically improved. There's one more memory leak I still need to fix though, which I'll get in 1.0.2.


the processing time on standard sups is still a little slower than the java one. I ran the same sup with 720p resizing on both and timed it. about 5-6secs faster on the old java but I think that's still better than it was. 6 seconds are not gonna kill me :)
On this non-standard sup java takes around 3mins vs less than a minute on your latest version and as I said the end vobsub size is about 1/6.

Also from a non-expert view the cmd info seemed odd. java got to 1269/1269 and ++ 72/223. They might just use a different routine. Just pointing it out.
I'm sure you'll be able to tell more trying out the sup file provided.

thanks!

[paradoxical]

the processing time on standard sups is still a little slower than the java one. I ran the same sup with 720p resizing on both and timed it. about 5-6secs faster on the old java but I think that's still better than it was. 6 seconds are not gonna kill me :)
On this non-standard sup java takes around 3mins vs less than a minute on your latest version and as I said the end vobsub size is about 1/6.

Also from a non-expert view the cmd info seemed odd. java got to 1269/1269 and ++ 72/223. They might just use a different routine. Just pointing it out.
I'm sure you'll be able to tell more trying out the sup file provided.

thanks!

Yeah, there is definitely something amiss there.

Edit to add:

Checking the 1.0.0 version and it spews a ton of errors, too. So, I'll track it down here in a bit.

Edited to add again:

So more interestingly is that 4.0.1 Java version processes that sup with no "missing end time of frame" warnings. The 1.0.0 of ++ spews a bunch of those warnings which also matches what 5.1.1 Java does as well. 1.0.1 only has those warnings for far less frames. But the 1.0.0 and 5.1.1 still get the same timings as the 4.0.x Java versions, while 1.0.1 has something broken for sure. Interesting for sure.

[Music Fan]

Okay. Without the file I can't really do much.
Here it is ;
http://www37.zippyshare.com/v/43256615/file.html
This is actually an extract (a few minutes). SupRip does not have problem with it.

[paradoxical]

Here it is ;
http://www37.zippyshare.com/v/43256615/file.html
This is actually an extract (a few minutes). SupRip does not have problem with it.

So I loaded it with 1.0.1 and saved it out as every format with no crashes. Any other info you can provide? What exactly did you do to get it to crash?

[Music Fan]

I tested it again and actually it works with a shorter name in a root folder instead of a subfolder :) , the path was maybe too long. But it's not very long ; around 20 characters for the name of the sup and also 20 for the name of the folder (no subfolder), it looks like :
K:\folder containing HD sup subtitles\my cool sup blu-ray extract.sup
It works with ;
E:\my extract.sup
The crash happened just after loading the sup. Now I know that I have to use short paths but if you can allow longer names (and/or paths), it would be nice ;)

[paradoxical]

I tested it again and actually it works with a shorter name in a root folder instead of a subfolder :) , the path was maybe too long. But it's not very long ; around 20 characters for the name of the sup and also 20 for the name of the folder (no subfolder), it looks like :
K:\folder containing HD sup subtitles\my cool sup blu-ray extract.sup
It works with ;
E:\my extract.sup
The crash happened just after loading the sup. Now I know that I have to use short paths but if you can allow longer names (and/or paths), it would be nice ;)

I think that's a red herring. The path I loaded the subtitle file was way longer than 20 characters. The path was "C:\temp\BDSup2SubPlusPlus\bdsup2sub++-build-desktop-Qt_4_8_4__qt4_8_4__Debug\release\extract french (Blu-ray sup).sup"

[Music Fan]

Now it works with the long file name :) while I didn't change anything.:confused:

[paradoxical]

I don't know what to tell you. The application itself does allow or disallow the length of path and/or file names.

[paradoxical]

mini-moose I fixed your issue. 1.0.1 version has been refreshed with the fix. Windows binary link has been updated. OS X binary will have to wait about 5 hours until I get back to my Mac.

[mini-moose]

mini-moose I fixed your issue. 1.0.1 version has been refreshed with the fix.

thanks! I'm running it now. doing resize to 1280x720 with Mitchel.
It seems to be taking a very long time..I'm at 10mins now and it's only at 330/1269. Are you getting similar processing times?

[paradoxical]

It's not super fast, but I finished in about 2 mins. This was on my Quad core i7 Mini. I'll do some more performance analysis and see if there isn't any more low-hanging fruit especially with some of the more slow filters. Just as a benchmark, Bilinear was about 30 seconds.

Edit to add:

I did notice when profiling before that 720p was slower than going to either NTSC or PAL resolutions which seemed a bit weird so I'll see what I can find out with more profiling.

[paradoxical]

Just to add as well, the 5.1.1 Java version is also quite a bit slower doing the 720p with Mitchel too. Nearly 20-30% slower on the same system with a couple of test runs.

[mini-moose]

It's not super fast, but I finished in about 2 mins. This was on my Quad core i7 Mini.

hmm it just finished here. took 29mins and I'm not sure it reached the end (if cmd output is an indication) :
WARNING: fade out detected -> patched palette
Decoding frame 1145/1269 at offset 01ad769b
There were 144 warnings
There were 1048 warnings

my pc is a sandy bridge i7 so not a very slow one.

[paradoxical]

Yeah it didn't take anywhere near that long and that's with quite a few things running at the same time.

[mini-moose]

Yeah it didn't take anywhere near that long and that's with quite a few things running at the same time.

here are the switches I used:

--palette-mode keep --resolution 720 --fps-target keep --filter mitchell

[paradoxical]

So it seems I was subtracting time wrong using my clock so I did one more test run after warming up the JVM so it can hotspot things:

Java version 5.1.1: 4 minutes 55 seconds.
Current 1.0.1 build of ++: 4 minutes 35 seconds.

So it's about a 7-8% difference once I warmed up the JVM. And again, this is on a 2.3ghz quad core i7 Ivy Bridge. So, I don't know why you got nearly 29 minutes. That's pretty insane. Maybe the difference is running it via CLI. I did my runs via the GUI. I can test that.

[mini-moose]

I don't know why you got nearly 29 minutes. That's pretty insane. Maybe the difference is running it via CLI. I did my runs via the GUI. I can test that.

yes pretty insane indeed. and there's nothing else running that
takes any cpu cycles. I did try the gui too for a bit and it reached about 15% after 5 mins so pretty much on track to the same processing time.

[paradoxical]

Okay, so there is something weird going on on your end especially if you aren't running anything else. Just to give you an idea of my system at the moment, I'm playing CounterStrike: Global Offensive and running a Windows VM in Parallels that is doing some BD Reauthoring. So it's not a lightly tasked system while doing the tests.

Also, via CLI gave me a time about 5 seconds off from the GUI in the ++ version.

[Selur]

Thanks for the new binaries, btw. you might want to add a '(Mac OS X 10.7+)' or something to the mac to avoid confusion.

[mini-moose]

Okay, so there is something weird going on on your end especially if you aren't running anything else.


yes indeed weird. I just tried again. Same thing. Tried the java and it did it in like 2-3 mins..

also the gui shows a very erratic behaviour for me. It's not unique to the latest version - maybe the 3rd one described below is, others were happening before too. I usually don't use the gui.

upon launch, console window flashes for a sec but I think that was discussed before.

when I try to load a sup I get this several times:
http://i.imgur.com/y5jIYos.jpg

and when I try to save/export this pops up several times:
http://i.imgur.com/zNT4cmj.jpg

I have to close this window and try save again quite a few times till I manage to get it working.

[Music Fan]

Now it works with the long file name :) while I didn't change anything.:confused:
I had the same problem today with the same file : first it crashed, then I retried and it worked.:o

[paradoxical]

Thanks for the new binaries, btw. you might want to add a '(Mac OS X 10.7+)' or something to the mac to avoid confusion.

Done. Wish I could make it compile to 10.6 but the #ifdef effort would be enormous to allow that.

yes indeed weird. I just tried again. Same thing. Tried the java and it did it in like 2-3 mins..

I don't know what to tell you. I ran it a few times again this morning with less system load and both are in the 2-3 min ballpark with the Java still about 10% slower.

also the gui shows a very erratic behaviour for me. It's not unique to the latest version - maybe the 3rd one described below is, others were happening before too. I usually don't use the gui.

upon launch, console window flashes for a sec but I think that was discussed before.

when I try to load a sup I get this several times:
http://i.imgur.com/y5jIYos.jpg

and when I try to save/export this pops up several times:
http://i.imgur.com/zNT4cmj.jpg

I have to close this window and try save again quite a few times till I manage to get it working.

Can't say I've ever seen anything like either of those screenshots on any OS I've run it on. And yeah, the console issue is something that can't be fixed in the application. I release the console as fast as is possible. It's purely a Windows issue with respect to Qt. Neither OS X or any of the *nix systems do it. Again, the only way to fix this is either on Qt's end or to make separately-compiled applications. Neither are very likely.

I had the same problem today with the same file : first it crashed, then I retried and it worked.:o

I opened it 20 times in a row and none of the times it crashed. Comparable link paths as I said yesterday. As I said, the application does nothing but pass the file path on to the QFile constructor. Any path length issues would come down to OS limits and on Windows that is 260 characters IIRC.

[paradoxical]

So good news for you mini-moose. After more investigation, I've isolated the speed issue and it's a total facepalm moment on my part. That Windows binary was compiled with -O0, no optimization, and debug symbols and I forgot to revert these when I compiled it for posting. The binary has now been replaced with the proper release build. That was why you saw vastly different results than when I was testing on my Mac Mini. Now, it's still slower to output since neither the Java or ++ is not detecting the image area properly, it's saying the entire 1920x1080 area is the "image area" which is not right, which accounts for why it takes longer than other BDSups to convert and output that I've tested. That I will investigate and try to track down.

Edited to add:

mini-moose where did you get that file from?

[paradoxical]

So I have a fix that will find the image area in the case of a pathological subtitle file like you sent me mini-moose. To find the image area doesn't increase processing time much more than not doing it. The best you can do with subtitles such as that is to load it, resave it without scaling, then scale. Or just accept that the time it takes to do the bounds checking and scaling.

[mini-moose]

So good news for you mini-moose. After more investigation, I've isolated the speed issue and it's a total facepalm moment on my part. That Windows binary was compiled with -O0, no optimization, and debug symbols and I forgot to revert these when I compiled it for posting. The binary has now been replaced with the proper release build.

Edited to add:

mini-moose where did you get that file from?

ok I will reget it and test!
what file? the sup or the binary I used?

[paradoxical]

That "english.sup" file that you posted in the other thread. That thing is something pathological. Looks like it was output incorrectly. It's got no data for image offset, etc so both the ++ version and Java see each subtitle image as the full 1920x1080 frame. That's why processing it is sooo slow.

And actually my post right above you was incorrect. Finding the image area before scaling reduces the time to save to about 24.5 seconds rather than it taking a couple of minutes. If you wait a few mins I'll post a new test version for you with the fix for that case in it.

[mini-moose]

That "english.sup" file that you posted in the other thread. That thing is something pathological. Looks like it was output incorrectly. It's got no data for image offset, etc so both the ++ version and Java see each subtitle image as the full 1920x1080 frame. That's why processing it is sooo slow.

it's from some horror movie blu-ray. I find that those sort of odd sups are often found on horror movies (usually colored too, yellow in this case). If you load it on something like SupRip you will see the letters are very tiny. When converted to vobsubs they look the normal size.

Ran the sup again with the new version and it took around 4mins (resized to 1280x720 with Mitchel).

I'm quite relieved to see it wasn't my system to blame :p
thanks!

edit: tried the gui now too and at least on first try it didn't display the symptoms I described earlier.

[paradoxical]

It'll take you far less than that once I finish compiling a new version with a fix for it. Went from ~3 minutes to ~24 seconds. :p

[paradoxical]

Here (https://www.dropbox.com/s/t955gighbz5dc0f/bdsup2sub%2B%2B102a_win32.7z) is a test version with that fix. I checked some other BDSups to make sure nothing got regressed with the fix and I didn't see anything, but if you see that it broke anything please let me know. Won't compile another "official" version till I finish the other issues slated for 1.0.2 release on the issue tracker.

[mini-moose]

Here (https://www.dropbox.com/s/w0hghslkh98femz/bdsup2sub%2B%2B_win32_test.7z) is a test version with that fix.

nice one:) it took 22secs with resize to 720p and 12secs for 1080p (1080 is always faster).

one thing I want to ask - the last lines on cmd output is
Decoding frame 1145/1269 at offset 01ad769b
There were 144 warnings
There were 1048 warnings

As I said before I have 0 understanding but shouldn't it end with
1269/1269 ?

also a small request if possible. Can you tag the archive and binary with some sort of version number? It can get a little messy when there are several versions around.

[paradoxical]

nice one:) it took 22secs with resize to 720p and 12secs for 1080p (1080 is always faster).

one thing I want to ask - the last lines on cmd output is
Decoding frame 1145/1269 at offset 01ad769b
There were 144 warnings
There were 1048 warnings

As I said before I have 0 understanding but shouldn't it end with
1269/1269 ?

I'll look into it. There was an issue like that with the GUI's progress bar stalling then immediately finishing even the processing was fine that I fixed a while back.

also a small request if possible. Can you tag the archive and binary with some sort of version number? It can get a little messy when there are several versions around.

Yeah with 1.0.2 I'll put version in the archive name. The application itself always has the version number in the title.

[mini-moose]

Yeah with 1.0.2 I'll put version in the archive name. The application itself always has the version number in the title.

ok. I usually just rename them myself, cause if I have a few versions like in this case and I want to be able to compare their performance it's easier to have the exe tagged differently. This way I can have all of them running from the same location (since I use a .bat to call them).

another small note: the 101 fixed .sub is 6.2mb (like the java output) and the test version .sub is 4.4mb. Whether it means anything..I have no idea :)

[paradoxical]

It's due to the fix I made. The test version crops the bitmap to the image area like would happen with any other SUP instead of it being the full 1920x1080 frame.

[mini-moose]

It's due to the fix I made. The test version crops the bitmap to the image area like would happen with any other SUP instead of it being the full 1920x1080 frame.

ok cool, just pointing out differences in case they have some meaning. You will need feedback from the more advanced users regarding potential issues.

At the time it was discussed the ++ version will be able to eventually generate 3D subs too from 3D sourced sups. Is that something you're planning to look into ?

[paradoxical]

ok cool, just pointing out differences in case they have some meaning. You will need feedback from the more advanced users regarding potential issues.

It shouldn't have any effect on any other valid SUP files because it only checks for the specific case of the "imageobject" for the subpicture having a width and height of 1920x1080. Anything that does have that would be another pathological file.


At the time it was discussed the c++ version will be able to eventually generate 3D subs too from 3D sourced sups. Is that something you're planning to look into ?

Yeah. No guarantees on when, though. Trying to fix some of the remaining bugs that Sassbot didn't get to and crashes like this (https://github.com/mjuhasz/BDSup2Sub/issues/34) that effects both version before more enhancements. DVB Sub will probably come first as well since it's simpler to implement.

[paradoxical]

So as a little update, I've fixed BDSUP parsing code to finally handle subpictures with multiple image objects correctly which means that it no longer crashes in files such as this (https://github.com/mjuhasz/BDSup2Sub/issues/34). It is now hugely simplified and easier to follow. :)

[paradoxical]

BTW can anyone post any examples of BD SUPs that use multiple regions in a subpicture so I can use them to run through the code just to double check everything?

[mood]

So as a little update, I've fixed BDSUP parsing code to finally handle subpictures with multiple image objects correctly which means that it no longer crashes in files such as this (https://github.com/mjuhasz/BDSup2Sub/issues/34). It is now hugely simplified and easier to follow. :)

And the update version is 1.0.1 or 1.0.2a??

where i can download it?

[paradoxical]

You can't. It's code I haven't pushed out yet. Just letting people know that I've fixed that. I'll make a git test build with the changes in a day or so once I thoroughly test it.

[mood]

You can't. It's code I haven't pushed out yet. Just letting people know that I've fixed that. I'll make a git test build with the changes in a day or so once I thoroughly test it.

oki thanks.

[paradoxical]

Just as an additional heads up, until I post a build with the multiregion support I will be pushing lots of incremental changes to Git. If you are building from Git expect there to be breakages along the way until things stabilize again. While the parsing for SUP files works, decoding the separate regions and merging them into a single image is still wonky, proper BD SUP output maintaining the multiregions needs to be added. Also on the BDN+XML side, the input reading needs to be fixed so that any event with multiple graphics is supported correctly along with correctly outputting the multiple graphics when being generated from a BDSUP file with multiregion subpictures. All-in-all, it'll be big refactoring and change job so it might take most of the week to fix up, but in the end the tool will be much more useful in light of its current restrictions.

[Selur]

using 1.0.1 if I call 'bdsup2sub++.exe -h'
I just get a bunch of:
QTextStream: No device
outputs on the console and a Windows user just reported that bdsup2sub++.exe crashes when closed with:
APPCRASH
Anwendungsname: bdsup2sub++.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 51030a54
Fehlermodulname: nvinit.dll_unloaded
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 506b31f3
Ausnahmecode: c0000005
Ausnahmeoffset: 72dace39
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
not sure what's happening there, but it seems like there's a problem with some NVIDIA driver,... (can't reproduce his crash on my machine)
He's using Windows 7 64bit
primary graphic using Intel HD drivers v8.15.10.2827
secondary graphic: NVidia (GTX460) driver v306.97

[paradoxical]

Yeah, I don't get a crash but I see what the error is and I fixed it locally. It'll get rolled up into the 1.0.2 version.

[paradoxical]

You can also compile a fixed version of 1.0.1 using this (https://www.dropbox.com/s/7zog13e22o4dcwf/bdsup2sub%2B%2B1.0.1_cli_fix.patch) patch file. Just pull down the 1.0.1 tagged version. Otherwise, I'll post a 1.0.2 at the end of the week with the fix.