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.

[Selur]

Thanks! On the road atm. and no compiling enviroment at hand, so he will have to wait till the end of the week. :)

[paradoxical]

Unless something goes awry I should have it by Friday at the latest. I'm making good progress on multi-region stuff. Got SUP parsing, decoding and output down. Now just need to fix BDN+XML import and export.

[Selur]

"I should have it by Friday at the latest" ... :D

[Music Fan]

He didn't say which friday:p

[paradoxical]

As I said, "Unless something goes awry". :p A few things popped up that diverted my time from being able to finish things up when I wanted. Next week it should be finished.

[Selur]

I know, just wanted to check. Thanks for the info. :)

[nautilus7]

Hi, bdsup2sub is having dificulties dealing with this subtitle file: http://www.sendspace.com/file/igjzoy

It's from the star wars bluray which is using seamless branching. This sup file comes from a very short m2ts file (2min opening crawl) and contains no actual subtitles inside, which I guess is the cause of the problem.

[paradoxical]

Yeah, it is simply telling you that there are no subtitles. The only real issue is just making the error message more user friendly. There's not really much else can be done.

[nautilus7]

Yes, but i want to convert it to bdn xml and i can't.

You'll ask why i would like to do that? Because i want to re-author the bluray and it must contain these empty subs, because as i mention before it is seamless, so this part's subs are empty, but others aren't.

[paradoxical]

Then just create an empty BDN+XML with avs2bdnxml.

[nautilus7]

ok, i will.

[nautilus7]

Well, i tried, but it doesn't let you create en empty xml. It detects that no png's are rendered and it doesn't output an xml.

[paradoxical]

Then create an ASS script with a single event that has no text. You'll get a single rendered PNG and it won't actually show anything. It'll work just the same as if it was truly empty.

[nautilus7]

This is exactly what i did.

avs2bdnxml -o output.xml c:\encoding\subtitles.avs
CPU: Using SSE2 optimized functions.
avis [info]: 1920x1080 @ 23.98 fps (100 frames)
Progress: 100/100 - Lines: 0 - Done
No events detected. Refusing to write XML file.

[Script Info]
; Script generated by Aegisub 3.0.2
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 1
ScaledBorderAndShadow: yes
Collisions: Normal
Last Style Storage: Default
PlayResX: 1920
PlayResY: 1080
Scroll Position: 0
Active Line: 1
Video Zoom Percent: 1
YCbCr Matrix: None

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,

[paradoxical]

Download: this (https://www.dropbox.com/s/e6kgkdfhbpfz9bn/dummy%20PES%20sub.7z).

[nautilus7]

Thanks.

[paradoxical]

Yes, I have gotten behind on getting the next version out mostly because the amount of changes have been quite extensive to support multi-region subs. It will come soon.

Also to mood: I've eked out another 20-30% on processing that badly made subtitle file you posted using Mitchell filtering downsizing to 720p. For most of the resize filters that calculate the same values over and over again I was able to replace those parts with compile-time constant expressions that have lead to most of the filtering speed up. They still aren't as fast as they could be, but this is simply just trying to optimize without dropping to assembly or intrinsics at this point.

[paradoxical]

New snapshot build for Windows can be grabbed *link updated below* (I've also updated the link in the first post). OS X build will come later tonight.

This has the CLI fix for Selur in it and the support for reading and decoding multi-region BDSUP and multi-graphic BDN+XML. Right now, with the multi-region SUP and the multi-graphic BDN+XML both regions/graphics are merged into one when output. This will be fixed in the next build so that BDSUPs will be output with two windows and the BDN+XML can be output with 2 graphics. Trying to support that was taking a lot of changes all over the place and was causing the delays so I backed out those changes to make this build. Please test to make sure there hasn't been any regressions or something indirectly broken by the changes done.

This is still marked as 1.0.2 alpha as I do want to get the output fixed for BDSUP and BDN+XML as mentioned above for the 1.0.2 release. Also I want to fix the issue r0lz reported a while back for the move from original y position not working properly.

[Selur]

OS X build will come later tonight.
Nice!

[paradoxical]

Ok, I did find a tiny regression. Updated the link to fixed version in first post. Also, new link is *link removed for now* as well.

[mini-moose]

just tried the latest version. I used the same cmd I always do and there's a lot of those coming up (haven's seen those before):

QString::arg: Argument missing: , windows 0 dim: 0*1920, 1080

It might have to do with this?:

QxtCommandOptions: option "verbatim" not found
QxtCommandOptions: option "no-verbatim" not found

is that a switch that needs to be added now?

The results seem fine and subs are created fast, just not sure what the above are..

Also as I mentioned before at the end of the process there last line always seems to be a few lines short:

Decoding frame 1246/1271 at offset 01d29be6
Conversion of 1 file(s) finished

again, not something that seems to be causing issues but it seems a bit weird.

[paradoxical]

No, it's unrelated. Though the build as posted should have had the fix to that. The second issue is due to a change that I didn't mean to be in that build. I changed the switch to "verbose" and "no-verbose" but apparently didn't update the help text since I hadn't meant for it to go out yet.

Since I'm in the middle of other changes, I'll just pull that build for now. Right now I'm finishing up some stuff related to the multi-region/multi-graphic output working correctly. I have it working fine if you don't do any scaling/moving but otherwise it screws up the image windows if you do.

[mini-moose]

No, it's unrelated. Though the build as posted should have had the fix to that.

thanks.

Another thing I was wondering about. Sometimes SDH sups have this black background when I preview them in the sw and in the created vobsubs. I'm not sure if it's supposed to be this way or not.

[paradoxical]

Yeah, I saw that on the issue tracker. Can you repost the files? The mediafire links are dead.

[mini-moose]

Yeah, I saw that on the issue tracker. Can you repost the files? The mediafire links are dead.

don't think I posted such files (just that weird horror one). I can check and see if I have any if needed.

[paradoxical]

Okay, well someone posted links to files reporting that issue. Either way, the links that are here (https://github.com/amichaelt/BDSup2SubPlusPlus/issues/6) are dead. So the original file and the bdsup2sub++ output would be helpful. :)

[mini-moose]

Okay, well someone posted links to files reporting that issue.

found one for you to try:

http://www.mediafire.com/download.php?cx8cgl8uvhgxha1

[paradoxical]

Okay that doesn't seem to be what I was thinking of and is unrelated to that issue I linked. The issue I was thinking was that someone was seeing bdsup2sub and ++ adding some black outline to certain subtitles that other programs didn't when converting.

As to your file: Everything I can open it in shows the same black borders. Even PGStoBDN when you have it output it as PNGs has the same black borders. It looks like that's just the way the subs were made.

[mini-moose]

Okay that doesn't seem to be what I was thinking of and is unrelated to that issue I linked. The issue I was thinking was that someone was seeing bdsup2sub and ++ adding some black outline to certain subtitles that other programs didn't when converting.


ok, I thought that was what others were talking about. Guess I was wrong.

[paradoxical]

So after a long and tedious effort, I now have multi-region BD Sup/multi-graphic BDN+XML import/export working in all the test files I've tried. Scaling and moving had to also be changed all over the place to accommodate this, but these work as well in my tests. Last two things to do before releasing 1.0.2 is to look into the bug related in the "move from original y position" option and then just run it a few times through some performance/memory usage tests to make sure nothing has regressed in that manner.

If anyone wants to play around with another pre-release build here (https://www.dropbox.com/s/0m766wejvdi5n1g/bdsup2sub%2B%2B102b_20131303_Win32.7z) is an executable for Windows. I've done a lot of testing and see no issues, but if someone can break anything or spot a regression I'm not finding please let me know. :) You will now be able to use this to shift timings, move, scale etc. without worrying about it destroying your multi-region/epoch sup files as it would previously.

Oh and for anyone using this via cli the "verbatim" and "no-verbatim" options have been changed to "verbose" and "no-verbose". I've updated the first post to reflect this as well.

[r0lZ]

Nice work. Thanks!

[mini-moose]

So after a long and tedious effort, I now have multi-region BD Sup/multi-graphic BDN+XML import/export working in all the test files I've tried.

what is multi-region BD sup?

[paradoxical]

It's a SUP file that contains subpicture(s) that are composed of two separate pictures. The original bdsup2sub was written to only assume every subpicture had 1 composition object and window. This means it would mess up those SUP files that utilized multiple composition objects for certain subpictures. BDN XML+PNG can also have events that are made up of two graphics as well. This was also not handled correctly due to the same assumption as for BD SUP.

[mini-moose]

It's a SUP file that contains subpicture(s) that are composed of two separate pictures. The original bdsup2sub was written to only assume every subpicture had 1 composition object and window. This means it would mess up those SUP files that utilized multiple composition objects for certain subpictures. BDN XML+PNG can also have events that are made up of two graphics as well. This was also not handled correctly due to the same assumption as for BD SUP.

thanks for explaining!

[Tappen]

I found a problem when loading the file below into 102b_20131303_Win32. Whenever I go to the multi-region subs it throws an exception.

http://www.sendspace.com/file/5cunw7

[r0lZ]

Another problem, reported by SpaceNerd here (http://forum.doom9.org/showthread.php?p=1609874): It seems that the b-spline resize filter doesn't work. I haven't verified that myself. Can you have a look, and fix the bug or remove the b-spline filter from the list of available filters? Thanks!

[paradoxical]

Yeah, looking into those now. Thanks for the reports. Especially on multi-region subs. My selection of samples was quite limited.

Edit to add: I'm actually surprised no one has reported that issue before, r0lz. I assume it was being called through the CLI, right?

Edit to add again: So the issue was that the code was doing basically a poor search of the filter specified via the CLI in a list it had. I'm surprised you didn't have other issues besides specifying b-spline since the detection code should have been broken for any filter explicitly set. I guess them saying that "bilinear" works is that you didn't specify a filter since that is the default.

[r0lZ]

Yes, I wrote a GUI to convert 3D BDs to MKV, and it uses BDSup2Sub++ to convert the subtitles. It calls it via CLI, of course.

BTW, there is another thing that I find terribly irritating. Each time BDSup2Sub is run, it creates a new INI file, in the current directory. IMO, that's not a good behaviour. Sometimes, the INI file is created in System32 (or in its VirtualStore equivalent). As a consequence, it is impossible to know for sure if it reloads the settings from an INI, and which one. IMO, the INI should be always saved and loaded in the same place. It should be either in %AppData% or in the application's folder (if the current user has write permission to that folder). Can you also verify that problem? Thanks!

[paradoxical]

Yes, I wrote a GUI to convert 3D BDs to MKV, and it uses BDSup2Sub++ to convert the subtitles. It calls it via CLI, of course.

Then it's weird it wasn't failing for other filters besides b-spline was specified.

BTW, there is another thing that I find terribly irritating. Each time BDSup2Sub is run, it creates a new INI file, in the current directory. IMO, that's not a good behaviour. Sometimes, the INI file is created in System32 (or in its VirtualStore equivalent). As a consequence, it is impossible to know for sure if it reloads the settings from an INI, and which one. IMO, the INI should be always saved and loaded in the same place. It should be either in %AppData% or in the application's folder (if the current user has write permission to that folder). Can you also verify that problem? Thanks!

Yeah, saving it to the proper OS settings directory is something that Sassbot had already had opened an issue for. I had added to the list of fixes for 1.0.2 then removed it for a later release, but I'll add it back. It's a simple change.

[paradoxical]

I found a problem when loading the file below into 102b_20131303_Win32. Whenever I go to the multi-region subs it throws an exception.

http://www.sendspace.com/file/5cunw7

That's a weird file. So the code crashes trying to decode the subpicture but the palette wasn't set since it didn't encounter a PDS. Easy enough fix, though. It also exposes a few decoding errors in the code as well. If you find anymore files that crash or have other issues like that one, please post them!

[r0lZ]

Then it's weird it wasn't failing for other filters besides b-spline was specified.Is it supposed to crash with all filters, when it is launched from CLI? It seems to work fine.

Thanks for considering fixing the path for the INI file!

[paradoxical]

Is it supposed to crash with all filters, when it is launched from CLI? It seems to work fine.

Yes, it should have since the code checking whether the specified filter existed in the list of filters was broken. Bilinear would have only worked because it doesn't need to be explicitly set.

Thanks for considering fixing the path for the INI file!

Yeah, it's a one-liner fix.

[r0lZ]

Yes, it should have since the code checking whether the specified filter existed in the list of filters was broken. Bilinear would have only worked because it doesn't need to be explicitly set.
Maybe it's why I haven't noticed the problem myself. I use bilinear, and it's also the default in my GUI. But selecting other filters do not crash the program. IIRC, I did some tests. Not sure why b-spline crashes. Anyway, I'll test that with the fixed version...

[paradoxical]

Maybe it's why I haven't noticed the problem myself. I use bilinear, and it's also the default in my GUI. But selecting other filters do not crash the program. IIRC, I did some tests. Not sure why b-spline crashes. Anyway, I'll test that with the fixed version...

Ok, I committed the fix a bit ago. Once I fix the issue reported by Tappen I'll post a new beta test version.

[paradoxical]

Okay, so I've fixed the CLI bug and the issue Tappen reported with the Ouran SUP. Please bang on this to see if you find any other issues. The last two things to do are the settings change and the move from original y position issue for 1.0.2 final if nothing else comes up.

New Windows binary here (https://www.dropbox.com/s/wjj5htnwz26tciu/bdsup2sub%2B%2B102b_20131803_Win32.7z).

[r0lZ]

I have asked previously (http://forum.doom9.org/showthread.php?p=1581216&highlight=depth#post1581216) to SassBot if it is possible to add a feature to convert the subtitles (usually in SUP format) to 3D half side-by-side or top/bottom (SUB/IDX). There is a real need for this, as currently, I know only 2 programs that can convert from SRT to 3D SUB (SubtitleEdit (http://www.nikse.dk/subtitleedit) and the discontinued 3DSubtitler), and none to convert directly from SUP to 3D SUB. In fact, Suppe3D (http://forum.doom9.org/showthread.php?p=1594978&highlight=Suppe3d#post1594978) has been developed by Neisklar to do just that, but it requires converting to PNG/XML (with BDSup2Sub++) and it is slow. IIRC, Suppe3D has no progress indicator when converting from PNG/XML to IDX/SUB, because BDSup2Sub++ doesn't output progress numbers to stdout during that conversion.

I would greatly appreciate the 3D conversion integrated in BDSup2Sub++, or at least a fix for the missing progress numbers. Of course, fixing the bugs in the current version is more important, and I propose to add 3D support in a forthcoming version. That should not be very difficult. It is only necessary to divide the width or height of the subpic bitmap by two (that's already possible) and to duplicate that resized bitmap and stack the 2 copies horizontally or vertically (depending of the side-by-side or top/bottom mode), with a configurable x offset (the 3D "depth" of the subtitle). BDSup2Sub++ can already do everything, except the final composition of the 2 bitmaps. Let me know if you need additional information...

[paradoxical]

It's on the list of issues for a later version. Also, bdsup2sub++ logs output to stdout by default when used via CLI. If they are not getting the progress indication either the version used had something broken for logging or their code is not reading stdout correctly.

[r0lZ]

Well, Suppe3D reads progress from CLI when it does the first pass (conversion from SUP to PNG), but it cannot do it when converting from PNG to SUB. I haven't found the post where Neisklar explains that it's because BDSup2sub doesn't output the progress numbers, but I remember it. Not sure he has used the last stable version, but I suppose so.
Anyway, that's not important if the 3D conversion is integrated in BDSup2Sub++. Nobody will use Suppe3D any more! ;-)

[paradoxical]

Well, Suppe3D reads progress from CLI when it does the first pass (conversion from SUP to PNG), but it cannot do it when converting from PNG to SUB. I haven't found the post where Neisklar explains that it's because BDSup2sub doesn't output the progress numbers, but I remember it. Not sure he has used the last stable version, but I suppose so.

Then there is something wrong with their code. It logs to stdout for everything. I've just re-tested it with multiple things and redirected stdout and it worked. If you can find the post that would help isolate what their issue could have been.


Anyway, that's not important if the 3D conversion is integrated in BDSup2Sub++. Nobody will use Suppe3D any more! ;-)

It'll definitely be worked on. Other things need to be finished first, though.

[paradoxical]

1.0.2b build for OS X has been added to the first post. It is also here (https://www.dropbox.com/s/h4fnzua4yexk8uu/bdsup2sub%2B%2B102b_20131803_OSX.zip)

[Selur]

Thanks! :D

[paradoxical]

You're welcome. :) Should be rounding the corner to finishing up all issues slated for 1.0.2. Please bang on it hard.

[djmasturbeat]

thanks
been meaning to check out the ++ versions (more, actually I had the previous "a" build, but only used it minimally, and not with ScnBD at all but for other things).
will test with ScnBD when I get a chance, and test out split epochs/dual windows/overlapping and time conflicting subs.

[paradoxical]

Yeah, the more testing it gets the better. Please bang away on it and let me know of any more limitations/errors one can find as I've only had a limited amount of samples to test with.

Edit to add: I think fades will still be an issue right now. Does anyone have any example SUPs that actually have fade effects, palette animations, etc.? I opened an issue to implement support for this in a later version.

[djmasturbeat]

i can demux sups from some of my own stuff (subtitles created with avs2bdnxml latest build) which uses fades, some done as inline effects hacked into the xml file before importing to scnbd, some fades left in the .ass

however ~ is this information intact in the sup if I demux with tsmuxergui, anyone know?

i will start with my Gundam Wing Endless Waltz, and send you a sup, send the PES+MUI, plus my .ass files and xml+png from avs2bdnxml
NB: the xml still has in a bug which happened for me on my first few projects, in the xml file from avs2bdnxml... no one else can reproduce it, so it seems to be heisenbug (bug based on heisenberg principle) as it was called in that thread, but I haven't had time to play much with a diff/alt build of his software yet. anyhow the bug is basically the first line appears twice consecutively with a ms or 2 delay between instances, and this creates a flicker, o/c. I fix it in ScnBD by removing the second instance and extending time of first one, in PES editor.
you can use the.ass to locate the fade effects that remain in the script. I don't think I did any inline effect fades (you can ctrl-f "fad" on the .xml just to be sure), I just shortened the fades that gave me underflows and removed other sub fx.
I will send you these in a pm and try to get some more stuff to look at later.

[paradoxical]

Cool, I appreciate it. Anyone also know of any retail discs that have subtitles that use such effects? Especially if they use one of the other authoring programs besides Scenarist just to see if the resulting SUP might look any different.

[djmasturbeat]

retail.... I will have to think on that.
Perhaps, but it seems like fan discs, as usual, are more of a labor of love than assembly-line mindset.

I will try to get you more of my own personal stuff and include all the files (.ass, avs+png, pes+mui, sup) to help better link what equates to what amongst these things.


I can get you stuff from another authoring tool just for general observation.
I will try to remember to send the Kiki's Delivery Service retail (dub)subs in sup and pes+muiwith my rendered fansubs and scripts, but I don't know that they have any fades or palette animations, nor any kind of inline subtitle effects. The only reason I would add them is they were made with Panasonic Authoring (PACR), which is a vastly different system from ScnBD, though if they are w/o inline effects, I have little idea what use they will be, if any for comparison.

Again, i don't know of any retails offhand with fades, but I will think on it.

[paradoxical]

Well, it was more for the curiosity than anything. And, yeah, the more stuff you can send me the better. Again, thanks a ton!

[paradoxical]

Hmm, so according to this (http://forum.doom9.org/showthread.php?t=156420) post the Lord of the Rings Fellowship of the Rings uses fade effects. Haven't watched mine yet so this would be a great time to crack open the discs and examine the subs. :) Should be at least a good starting point to how retail discs do fade effects.

So as I said, if anyone knows of any other retail BDs that use fades, palette animations, etc. let me know. I'll try to fix all the shortcomings inherited from the original program as best as I can relating to this.

[djmasturbeat]

which LotR, the TC, or the even-more-overly-long ones?
sorry, loved the books but found the movies a snooze, and hated the color/hue palette change thing they did on the BDs (was it only the extended they did that to?)

[paradoxical]

I have both actually.

So in testing, fades might not actually be an issue at least on the import side. For subtitles that I tried that the original BDSup2Sub says "WARNING: Palette animation: result may be erratic" and then basically does no fading. bdsup2sub++ on the other hand does the fade as you would expect. Though I expect that the way the subpictures are written back out will need to be optimized so that image objects aren't duplicated when the only difference is in the palette id. I'll need to test export but from reading the code it doesn't look like the palette update flag and the palette id ever get updated in the headers being written out so that will need to be changed. But it's an encouraging sign nonetheless.

[Chetwood]

The subs are only animated for the director's comment in which the name of the person currently speaking fades in/out. Another thing: would it make sense to save back to PGS when resizing 1080p subs to 720? After all, PGS allows for more colors than VobSub and might result in more readable subs.

[paradoxical]

The subs are only animated for the director's comment in which the name of the person currently speaking fades in/out.

Well for the theatrical cut there are a couple of forced subs that do fading, too. The point really was just to see if the code would handle fades at all which it did. I just need to fix export so that the fades aren't destroyed when writing the sup back out.

Another thing: would it make sense to save back to PGS when resizing 1080p subs to 720? After all, PGS allows for more colors than VobSub and might result in more readable subs.

Yes, it'd make more sense to do PGS since that would be guaranteed to be supported. 720p VobSub is sort of non-standard and you never know how it will be handled by various players and/or subtitle filters.

[paradoxical]

Spotted a crash in picture decoding for BD SUPs due to some parsing logic errors. I didn't spot it before since it didn't crash the release build only on debug. This has been fixed. If you were using the previous beta and want the newest binary it can be downloaded here (https://www.dropbox.com/s/vyo4j2x9v7mt827/bdsup2sub%2B%2B102b_20132003_Win32.7z). First post has been updated as well.

[djmasturbeat]

looks like the dropbox link is dead for the update

[paradoxical]

Yeah, I'll fix the link shortly. After fixing the previous issue an export bug cropped up. Arggh.

[paradoxical]

As an update I know what the issue is and I have a fix for it. I have to go to the dentist now so once I get back I'll commit the fix, test it and post a new build.

[r0lZ]

I have a palette problem that drives me crazy. I don't think it's a BDSup2Sub++ bug, as the java version and the VsFilter/VobSub plugin for Avisynth give the same result.

The original stream is in SRT format, and has been converted to SUB/IDX (and also, for testing to PNG/XML) with 3DSubtitler.
I have uploaded a (very) small sample here (http://download.videohelp.com/r0lZ/tmp/test_subs.7z) in PNG/XML format.

The first subtitle is correct. Its colour is white, with a black outline.
The second subtitle looks correct in the upper part of the BDSup2Sub++ GUI (source), but the font colour is blue in the lower part. I don't understand why. It should be white too, and if I open the PNG in an image editor, the colours are correct.

I have tried many things to fix that palette problem, including converting the PNG images to TIF and then back to PNG, but w/o success.

Finally, I've discovered that saving the XML/PNG as BD SUP with BDSup2Sub++ seems to work. When I reload the SUP, it has the correct colours. But as soon as I change the output format back to IDX/SUB, the second subtitle turns blue again!

Trying to save as IFO/SUB with a new palette doesn't work either. When I try to edit the palette, the colour of the subtitle changes, but the program selects automatically another colour. Finally, BDSub2Sup++ has crashed.

What am I doing wrong? How can it be that some images are correctly shown, and other ones, saved with the same program, are wrong? Is it a way to fix that problem?

[paradoxical]

Ok, I'll look at it.

[r0lZ]

Thanks. BTW, I have finally found a way to convert the stream with correct colours. I have edited all colours of the palette in the BdSup2Sub++ GUI, leaving just one black, one grey and all other colours white, then I've saved the palette. Then, I've loaded the PNG/XML subs, and re-loaded the palette. It seems that that has forced BDSup2Sub++ to select the "best colour" from the palette to replace the blue, and luckily it picked white. The saved IDX/SUB seems correct. That works, but obviously, there is something strange, as it should not be necessary to use that bizarre trick.

[paradoxical]

Yeah, I've noticed the problem too. I'm guessing something weird is going on when mapping to the reduced palette. Maybe in the quantization phase. I'm still working out all the kinks for import/export of BD SUPs but I look at it after that. I'm busy this weekend so I won't be able to finish to BD SUP stuff up until early next week.

[r0lZ]

Strangely, the avisynth VsFilter has exactly the same problem, with the same subtitles, also shown in blue. So, I guess something is strange in some PNGs. But that should not prevent BDS2S to convert them correctly. Goof luck, and have a nice weekend.

[paradoxical]

Well I've noticed it also for BD SUP to Vobsub that colors get screwed up, too.

[r0lZ]

Yes. BTW, I did some tests with v1.0.0 too, without success for the colour problem, but I've discovered that the subtitle start and end times were screwed up when converting from PNG/XML (to any format, I think). I didn't know that bug and I've verified with v1.0.1. Obviously, it has been fixed. Good job! :-)

[paradoxical]

So there was a big delay in getting this out, but a new beta version is here (https://www.dropbox.com/s/wpoxlgkgxo0yewr/bdsup2sub%2B%2B102b_20132803_Win32.7z). This should put to rest all the issues with import/export issues with multi-region SUPs. There is still a few optimizations that can be done be for subtitles that share a composition object when output back out as BD SUP but those will have to arrive for 1.0.3. The lack of that doesn't seem to harm anything, but it would make the SUP files smaller and match closer to what is output by professional authoring tools. This now just leaves the move issue and the change to fix where settings file is saved which I will work on now. Please report if you do see any issues though.

[r0lZ]

Thanks. BTW, I've also noticed a small typo. The name of the config file is bdsup2sup++.ini instead of bdsup2sub++.ini. Not a big deal, but that's easy to fix. :-)

[paradoxical]

Yeah, that's pretty weird. Will fix that. Apparently it's been that way for a while.

[paradoxical]

Refreshed the file to fix that and another fix. So I'd recommend regrabbing if you already got it.

[r0lZ]

It seems that the palette is still wrong when saving to SUB/IDX or SUB/IFO. But this time, the color of all original subtitles (in PNG or SUP format) is wrong too, regardless of the output format. With v1.0.1, I have been able to convert with the good colors by forcing a palette with only black, gray and white colors, and the antialiasing worked well. Now, the antialiasing (present in the original SUP file) is lost too. When the palette is forced, it picks black for the outline, and the gray for the text and the antialiasing, with some white pixels at random places. Really strange.

[r0lZ]

I've noticed an interesting thing. As you know, I have generated the original PNG/XML files with 3D-Subtitler (http://www.softpedia.com/get/Multimedia/Video/Other-VIDEO-Tools/3D-Subtitler.shtml). It has an option to change the contrast (in fact, it's more the brightness) of the generated subtitles. Its default value is 100, but iirc I've lowered it a bit, because the movie is very dark, and I don't want too bright subtitles. With that dark subtitles, BDSup2Sup (++ and java) fail when picking the colors of most subtitles. But if I set the "contrast" slider to its maximum (value 250), then the colors of the converted SUB/IDS are picked correctly, and the generated IDX/SUB is correct. (I have edited the palette in the IDX file to change the colors after the conversion, and that works well.) So, it seems that BDSup2Sub picks the wrong colours only when the original colours are not close enough to the existing palette.

Also, I have noticed another small bug. When I've tried to convert the dark subtitles, I have saved and loaded several palettes (in .INI format). I have loaded the BDSup2Sub++.ini file instead of the palette.ini by accident, and BDSup2Sub++ has changed all colors to black. Not a big problem, but if it's easy, it should check for the right file format before changing the palette.

[paradoxical]

It seems that the palette is still wrong when saving to SUB/IDX or SUB/IFO.

It's because no change was made for that yet.

Also, I have noticed another small bug. When I've tried to convert the dark subtitles, I have saved and loaded several palettes (in .INI format). I have loaded the BDSup2Sub++.ini file instead of the palette.ini by accident, and BDSup2Sub++ has changed all colors to black. Not a big problem, but if it's easy, it should check for the right file format before changing the palette.

Ok I'll look into it.

[paradoxical]

New git build here: here (https://www.dropbox.com/s/82dr1cq9hk2v535/bdsup2sub%2B%2B102b_20130404_Win32.7z). Has a fix where some flags were not properly set when using the CLI which caused the output to differ from conversion in the GUI. Also has a few improvements for exporting just forced subtitles.

[paradoxical]

All outstanding issues I wanted to get fixed for 1.0.2 are down. Please test with this build (https://www.dropbox.com/s/pwdm81ebgm47y2m/bdsup2sub%2B%2B102RC_20131204_Win32.7z) to see if you spot any issues. If not, I'll tag 1.0.2 and start work on other things on the list.

Just a word of warning that until I do some additional optimizations to the BD SUP output, if you convert a SUP file that has lots of fades or when composition objects are referenced across multiple epochs to another SUP file you will notice the resulting output will be larger (sometimes many times larger if there are lots of fades for example). This is because of limitations of the code as it is right now and that it duplicates those composition objects rather than just keeping a reference to them and using different composition states as you would see in proper output. It doesn't harm anything as the subtitles will still display correctly, it just means the file size will be bloated.

This will be an issue I will fix, but it required a bigger change to the output code than I currently wanted to do. This will be the first thing I do fix for the next version, though.

[paradoxical]

Oh and to add for you r0lz, I've added specific commandline switch for the move Y from origin. It requires you to specify up and down because for some reason the library I use for parsing commandline options would interpret giving an option a negative integer value as an option itself and thus would fail out because it was unrecognized. So you have to do "move-y-origin up" or "move-y-origin down". It's a little awkward but should work for now. I'll see if I can workaround the issue otherwise in the meantime. Also, the same option when used in the GUI also works properly now.

[r0lZ]

Thanks! I'll test the new version soon. :)

[Selur]

@paradoxical: I got two users who get crashes of bdsup2sub++ if they use a newer NVIDIA drivers than 296.10, using 296.10 everything is fine.
Are you using any OpenGL code that might be in conflict with newer NVIDIA drivers on some cards?

[paradoxical]

Nope. Also, the Qt I compile to link in is even specifically compiled without OpenGL or ANGLE.

[paradoxical]

Also my dev box is running 314.07 and I see no issues with it.

[Selur]

I'm running with the latest NVIDIA driver and have no problem either, but some older cards seems to have trouble with it.

[paradoxical]

I don't know. Maybe it's a Qt bug. I don't use anything OpenGL/DirectX directly.

[Selur]

What Qt version do you use to compile delaycut?

[paradoxical]

The version for the latest bdsup2sub++ builds is 5.0.2. You can always check that by going to About > About Qt.

[paradoxical]

Just as a thought, did you happen to get the information about what kind of CPU they had? The only other change with that build is that I compiled both the Qt libs and the application with MinGW-builds x32-4.8.0-release-win32-sjlj-rev1

[Selur]

No, but I will ask them and report back.

[paradoxical]

Hear anything? Having perused a thread it seems this happens with other apps as well according to that link to rename the DLLs. It's weird though as it seems to be almost random according to the posts about it. Just to test it doesn't have any crashes on the other main Windows machine I use to develop on which has a Quadro 2000 currently running 311.06.

[Selur]

Sadly no update from the users that reported the problem till now,...

[paradoxical]

Sadly no update from the users that reported the problem till now,...

Well, since it seems others have seen this issue with other apps, it's probably unlikely to be some sort of CPU incompatibility issue. So were they having issues with builds prior to the latest as well? If so, it means at least that it isn't a 5.x specific issue. Seems maybe Qt has some sort of bug or the NVIDIA drivers are just doing something stupid by loading DLLs that aren't needed. In either case, I'm not really sure that I can do anything especially since it's almost a random issue and one that only seems to affect a small amount of people.

[Selur]

will ask the users to try older Versions and report when I get feedback

[sl1pkn07]

is possible add "none" option to image filter?

[paradoxical]

Images only get filtered if you specify a different target resolution than the source resolution via CLI or choose "convert resolution" in the GUI. So there's no real point.

[paradoxical]

Anyone noticed any showstopping bugs that would prevent me from tagging 1.0.2 and releasing it?

Also, is there anyone interested in 64-bit Windows builds? I've only not done so just because I was too lazy to compile another set of Qt libs.

[sl1pkn07]

http://wstaw.org/m/2013/04/16/plasma-desktopEv4322.png

edit: stop build: http://sl1pkn07.no-ip.com/paste/view/cc2615c1

[paradoxical]

What am I supposed to be seeing?

As I told you before, the code does not apply filtering unless you have specified a different target resolution than the source resolution.


// export 4 color palette
if (width == trgWidth && height == trgHeight)
{
// don't scale at all
if ((inMode == InputMode::VOBSUB || inMode == InputMode::SUPIFO) && paletteMode == PaletteMode::KEEP_EXISTING)
{
targetBitmap = substream->bitmap(); // no conversion
}
else
{
targetBitmap = substream->bitmap().convertLm(substream->palette(), alphaThreshold, luminanceThreshold); // reduce palette
}
}



if (width == trgWidth && height == trgHeight)
{
targetBitmap = substream->bitmap(); // no scaling, no conversion
}

[sl1pkn07]

no apply bilinear filter by default?

[paradoxical]

Did you read my previous post? I even posted the exact code where it checks to see if any scaling is done. I can keep repeating myself if you want.

[sl1pkn07]

no, no need (i'm not coder, only know bash, but bad). but then is possible in the GUI set "none" instead bicubic (first option)? (like http://wstaw.org/m/2013/04/16/choped.png) or describe method to back to unfiltered if select one of filters (without close and reopen sub)

greetings

[paradoxical]

There is no point of a "none" option. Filtering only gets applied if you select to convert resolution of the subtitles. What you're asking for would only complicate the GUI with a bunch of added logic in order to add an option that will do nothing.

[paradoxical]

To put this another way. Adding the "none" option means, that when you do select "convert resolution" the GUI has to either:

1) Choose a filter option automatically

or

2) Has to check on export that you have selected a filter.

If you then uncheck the "convert resolution" option it then has to then know to clear your filter selection. Which means that if you then choose "convert resolution" again if option 1) had been chosen as the previous behavior the GUI then has to remember what your old selection was in order to restore it.

Now that doesn't seem like a lot, but why add any of that extra logic when the current code does not apply the scaling filter unless the "convert resolution" option is checked and you picked a target resolution different from the source resolution?

Is adding this option going to actual fix some longstanding, unresolved issue? If so, please enlighten me because I don't see it.

Also, you seem to be confused by what happens when you change that option based on what you said here:

or describe method to back to unfiltered if select one of filters (without close and reopen sub)

You don't need to close and reopen the subtitle file. To get back to "unfiltered" only requires you to go to the conversion options and uncheck "convert resolution". Assuming you had also chosen a target resolution different than the source resolution. Because even if that option is checked but you hadn't changed the resolution it isn't scaling anyway as that would be pointless.

Also, every time you change between the different options it always scales from the source image. It does not then apply the same scaling filter to the previously scaled image if that's what you were thinking it does.

[paradoxical]

On another note, having compiled a test 64-bit version of the binary it has uncovered a bug in the palette logic for BD SUP files. Apparently the code that controls updating the palette was reading the wrong object for a boolean value for if the palette had been updated. It just so happens that when it that code path was reached the value from the constructed object just happened to be a value (the debugger showed that it was "40" which made no sense for a C++ boolean value as it should have read "true" or "false") that caused it to go through the path successfully. When compiled with the 64-bit version of MinGW this value was set to the correct default value of "false" and as such the palette did not get updated when it should have which caused issues with subtitles that had fades. Apparently this code path was only working through luck. Guess it was worth making a test 64-bit build after all.

If no one tells me they've seen any showstopping issues by tomorrow morning, I'll just tag 1.0.2 and add new builds for OS X and Windows that also incorporate the fix for that.

[r0lZ]

I haven't much time to test it right now, but I have roughly tested the move Y options (from CLI and GUI), and they seems to work well.

Just a cosmetic thing: when moving all subs of a file with many subtitles with the GUI, a little windows appears during the operation, but nothing is visible in that window. I presume that it's a progress window, or perhaps it should show the subtitle number that is currently processed. Not a big deal. IMO, you can release v1.0.2.

If you can get the x64 version working, I agree that it could be useful, although imo it is not really necessary.

[paradoxical]

Hmm, the move dialog issue seems to only appear in the latest builds using Qt 5, but I'm not sure why it only happens for that one progress dialog and not the others. That may be a reason to just stick with Qt 4.8.4 for a while still. And yeah, the x64 version really isn't necessary because the RAM usage is so low. Also, I benchmarked between it and the 32-bit version and it was really no faster.

[r0lZ]

The blank dialog is not really an issue. It's just a cosmetic glitch. Anyway, do what you think is the best.
There is no real need for the x64 version. Thanks for having tried.

[paradoxical]

Ok new builds. The Windows build going back to Qt 4.8.4 which doesn't have that weird progress dialog issue when moving.

Windows (https://www.dropbox.com/s/jiw6r9qphcugs1r/bdsup2sub%2B%2B1.0.2_Win32.7z) and OS X (https://www.dropbox.com/s/f8p9fgsxv9p6hej/bdsup2sub%2B%2B1.0.2_OSX.zip). First post has also been updated.

The blank dialog is not really an issue. It's just a cosmetic glitch. Anyway, do what you think is the best.
There is no real need for the x64 version. Thanks for having tried.

True, but I wasn't really seeing anything dramatically better going to Qt 5 anyway either speed or otherwise so I'll just stick with what doesn't cause random glitches. I will probably post a Windows x64 version later once I make sure there are no more subtle bugs hiding around that it might expose.

[Selur]

btw. some infos from one of the problem users:
301.42-desktop-win7-winvista-64bit-international-whql.exe -->OK

306.23-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash
306.97-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash
310.70-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash
310.90-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash
314.07-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash
314.22-desktop-win8-win7-winvista-64bit-international-whql.exe -->crash

he's using an Intel Core i7-2600K CPU

[paradoxical]

There's nothing I can do. I don't control what NVIDIA's drivers do. They are the culprits here. I wish there was a better answer. I simply compile Qt as is and link it in.

Also, as I said before I run 314.07 on one of my dev systems and it runs the binary with no crashes.

[Selur]

Just, thought I post the info so it doesn't get lost :)

[paradoxical]

Just, thought I post the info so it doesn't get lost :)

I definitely appreciate it as I wasn't trying to be dismissive of your post. I just wish I had a better answer. :(

[paradoxical]

Seems even an ImgBurn user (http://forum.imgburn.com/index.php?showtopic=20585) has been hit by this issue before as well.

[AGKnotUser]

Just tried 1.0.2 with Avatar exporting only forced subtitles. All subtitles appear in the extreme upper left corner of the screen. Tried with MPC-HC and XMBC. What other information do you need?

[paradoxical]

Give me your input file and the output so I can check them. Also, outline any settings you set, etc. when processing.

[AGKnotUser]

Give me your input file and the output so I can check them. Also, outline any settings you set, etc. when processing.

They are way over the upload limit, even zipped or rared. The only settings I used was to use SUP(BD) Output Format And Export only forced. How can I give you a sample?

[AGKnotUser]

I am able to give you a sample of the exported file. Just for information I tried the old BDSup2Sub.jar version 5.0.0. It was the last version to work with this Blu-ray. 5.1.1 and 5.2 Snapshot didn't work either. Unfortunatedly i don't have 1.0.1 anymore to test with.

[paradoxical]

Upload the files to something like sendspace. Just giving me the output file doesn't really help. I need to debug what happens when it processes the source.

[AGKnotUser]

Upload the files to something like sendspace. Just giving me the output file doesn't really help. I need to debug what happens when it processes the source.

OK, Here is the URL for Avatar Subtitles.zip both input and output files: http://www.sendspace.com/file/rt6ke7

[paradoxical]

Thanks.

[rack04]

I have a subtitle file from Silver Linings Playbook Blu-ray that I'm having some issues with. BDSup2Sub v4.0.0 reports 2079 captions and BDSup2Sub++ v1.0.2 reports 2080 captions and I don't know which one is right. Below is a download link for the subtitle that I extracted using eac3to.

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

[paradoxical]

Thanks for the file, checking it now.

[paradoxical]

So I see what is going on. Apparently BDSup2Sub is combining 2 PCS together starting from subtitle 1568 because the composition number didn't change, whereas bdsup2sub++ is keeping each PCS separate. That's the cause of the 1 subpicture discrepancy. It's a harmless difference.

[AGKnotUser]

OK, Here is the URL for Avatar Subtitles.zip both input and output files: http://www.sendspace.com/file/rt6ke7

Just wondering if you found the files to be helpful.

[paradoxical]

Just wondering if you found the files to be helpful.

Yes, they are. I've looked at them a bit but haven't had enough free time lately to dig too deep. Have another project I'm trying to finish up. Will do so soon, though, I promise. :)

[AGKnotUser]

Yes, they are. I've looked at them a bit but haven't had enough free time lately to dig too deep. Have another project I'm trying to finish up. Will do so soon, though, I promise. :)

No problem, thanks for all your efforts.

[Selur]

btw. anyone compiling BDSup2Sub++ (ideally static) for Ubuntu? (Qt4.8 is needed for qtxcore and gcc 4.7+ is needed for BDSup2Sub++ itself)

[sl1pkn07]

need libqxt (I ignore the name of this library in ubuntu)

[Selur]

libqxt -> "sudo apt-get install libqxt-dev", sadly not available for Ubuntu 10.04 (probably since 10.04 uses Qt4.6), but on 12.04 (which uses 4.8) :D
»-std=c++11« requires gcc 4.7+, iirc Ubuntu 13.04 is the first Ubuntu version using gcc 4.7+, sadly it also uses Qt5 as default which breaks some of my projects due to some bugs that might get fixed by 5.0.3.

[sl1pkn07]

for expample in archlinux is possible use 3 versions of Qt: Qt3, Qt4 and Qt5. the version of Qt to use is selected by the app qtchooser (from Qt project). the version of gcc is 4.8, but can install other version through AUR (user repository, no binary, need build)

https://launchpad.net/ubuntu/+source/libqxt

update your ubuntu or change distro XD

[paradoxical]

Selur, here (https://launchpad.net/~george-edison55/+archive/gcc4.7-precise) is a ppa for GCC 4.7 on Ubuntu 12.04. It gives you a starting point at least. Also, I have a Kubuntu 12.10 in a VM that I use to compile and test the program. There isn't a need for 13.04 to compile this.

[Selur]

thanks :)

[paradoxical]

thanks :)

You're welcome. Like I said, though, 12.10 has everything you need. You get GCC 4.7.2 and you can grab the Qt and libqxt from the repos. No need to compile anything but the program itself.

[eTiMaGo]

Heya,

I posted an issue on the github page but maybe someone has an answer here... I'm trying to process multi-language idx/subs into xml/png using the CLI, but it outputs only the first language. So, is there a command to either output ALL language streams to different individual outputs, or to select a different language ID from the source file?

[paradoxical]

There is no support for outputting all languages at once. It also doesn't look like the CLI supports choosing which language to export even though the GUI does which is easy to rectify.

[eTiMaGo]

OK cool, then I'll use individual idx/subs for now.

[Music Fan]

Hi paradoxical,
are you still working on DVB-SUB support ?

[r0lZ]

I've tried to convert this SUP file (http://download.videohelp.com/r0lZ/tmp/7%20Subtitle%20%28PGS%29%2C%20French.7z) to XML/PNG from the command line, and I've discovered several bugs.

First bug:
Many subtitles are made of 2 PNG images. The first one is the correct subtitle, converted to PNG without problem, but the second image is totally black (without transparency). I wonder from where they are coming from. (I'm not sure it's really a bug, but it's strange, and it's the first time I see that black pictures.)

Second bug:
Many subtitles are made of 2 exactly identical PNG images, apparently correctly converted. IMO, when the images are identical, they should not be saved twice. But that's not the problem. In the XML file, the same subtitle is supposed to use more than 2 PNG images (usually 5). But only 2 images exist in the directory, and therefore the XML file references non-existing PNG images. Of course, that causes many problems.

Third bug:
Since I have discovered that the bugs 1 and 2 do not happen if I convert all subtitles to IDX/SUB and then the IDX/SUB to XML/PNG, I have converted successfully the subtitles that way. But the original subtitle stream has 3 forced captions, so I have decided to convert them also, with the same method. The first conversion (from SUP to IDX/SUB) works fine, and I have the 3 forced captions in the SUB file. But when I try to convert that SUB file to XML/PNG, BDSup2Sub++ crashes immediately. The crash happens ONLY when using the command line. The same conversion works fine from the GUI.

Note that the subtitle stream comes from the Ice Age 3 3D BD given when you buy a Panasonic TV. That BD is well known to have some bugs in the MVC video stream, and maybe it has also somewhat bad subtitle streams. Anyway, these 3 bugs are strange, and I suppose you will be interested in examining the SUP file.

BTW, any chance to have the option to convert the SUP to 3D SUB soon? Currently, due to the 3 bugs above, I can't convert them reliably. Thanks in advance.

[paradoxical]

OK cool, then I'll use individual idx/subs for now.

Yeah, it will be fixed in the next version.

Hi paradoxical,
are you still working on DVB-SUB support ?

Yeah, it's still something that will be added.

I've tried to convert this SUP file (http://download.videohelp.com/r0lZ/tmp/7%20Subtitle%20%28PGS%29%2C%20French.7z) to XML/PNG from the command line, and I've discovered several bugs.

First bug:
Many subtitles are made of 2 PNG images. The first one is the correct subtitle, converted to PNG without problem, but the second image is totally black (without transparency). I wonder from where they are coming from. (I'm not sure it's really a bug, but it's strange, and it's the first time I see that black pictures.)

Second bug:
Many subtitles are made of 2 exactly identical PNG images, apparently correctly converted. IMO, when the images are identical, they should not be saved twice. But that's not the problem. In the XML file, the same subtitle is supposed to use more than 2 PNG images (usually 5). But only 2 images exist in the directory, and therefore the XML file references non-existing PNG images. Of course, that causes many problems.

Third bug:
Since I have discovered that the bugs 1 and 2 do not happen if I convert all subtitles to IDX/SUB and then the IDX/SUB to XML/PNG, I have converted successfully the subtitles that way. But the original subtitle stream has 3 forced captions, so I have decided to convert them also, with the same method. The first conversion (from SUP to IDX/SUB) works fine, and I have the 3 forced captions in the SUB file. But when I try to convert that SUB file to XML/PNG, BDSup2Sub++ crashes immediately. The crash happens ONLY when using the command line. The same conversion works fine from the GUI.

Note that the subtitle stream comes from the Ice Age 3 3D BD given when you buy a Panasonic TV. That BD is well known to have some bugs in the MVC video stream, and maybe it has also somewhat bad subtitle streams. Anyway, these 3 bugs are strange, and I suppose you will be interested in examining the SUP file.

That's very weird with the blank PNG. I've downloaded the file and will look into it.

BTW, any chance to have the option to convert the SUP to 3D SUB soon? Currently, due to the 3 bugs above, I can't convert them reliably. Thanks in advance.

It will probably come in the version after next. When that will be I can't say. I'm still busy working on a side project I committed to for another person that is taking longer than expected and haven't had tons of time to start work on the next version yet. I'm definitely working on things, it's just coming along slow. Hopefully by mid June I can get back into committing more time to working on it.

[Music Fan]

Yeah, it's still something that will be added.
Great ;)

[mini-moose]

got a small sup file of only 5 lines. bdsup2sub++1.0.2_Win32.exe creates a vobsub file with those split into 48 lines, most with a 0,171 duration. It's the same 5 lines but they repeat themselves several times.

Warning for every line:

WARNING: duration of frame 1 is shorter than 520ms

tried also with java versions (older and newer) and they seem to keep them at 5 lines.

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

[paradoxical]

Ok, looking into it.

[Chetwood]

This sub (http://www.sendspace.com/file/57x0b1) (password is your nick) is ripped straight from DVD with VSrip and locks up BDSUP2SUB++ (and even BDSUP2SUB 5.11) when switching to the second language and browsing items. Can you take a look? Thx.

[mini-moose]

"ERROR: Palette ID out of bounds."

Sup here:

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

only creates .sub file, works fine with java versions

[Music Fan]

I see that paradoxical is not member of this forum anymore, so I guess this project has been stopped.
Does anybody know a tool able to convert DVB-SUB to sup ?

[Selur]

there hasn't been an update for 7 month, see: https://github.com/amichaelt/BDSup2SubPlusPlus .
So yes, at least for the moment the project seems to have stopped. (latest version is still a lot newer than BDSup2Sub)
Sorry, never tried DVB-Sub subtitle which BDSub2Sup++.

[Music Fan]

Ok, so I guess he still hadn't added DVB-Sub support because he hadn't last time he answered me (on previous page).

[Selur]

yup, his replay was from may and since the last update was from "Apr 17, 2013" (see: https://github.com/amichaelt/BDSup2SubPlusPlus/commits/master) I think you are right. :)

[Music Fan]

Actually ProjectX can demux DVB subtitles ;
http://www.iphonelife.com/blog/87/how-you-can-convert-your-dvb-recordings-subtitles-idevice-friendly-mp4-subtitles

http://www.videohelp.com/tools/ProjectX

It seems to work but I get very special colors when I open the sup in SubtitleCreator, I still have to understand how to correct these subtitles.
ProjectX creates sup, sub, idx, ifo and txt.
SubtitleCreator can open sup, sub, idx and ifo, I don't know what is better.
And it seems to be converted in 720.576 while my TS is in 1920.1080.:confused:

[Selur]

ffmpeg might also able to extract them. I thought the main goal was to convert them,...

[Music Fan]

Yes, I wanna convert them to make an AVCHD with multiAVCHD (so actually not really an AVCHD but a bastard format between AVCHD and Blu-ray), and I need a sup file compatible with multiAVCHD (blu-ray type sup). I'd like also to change colors and position and I believe it can be done without OCR.
How does it work with ffmpeg ?

I'm talking about bit-map subtitles, not teletext sub.
I believe it's the norm ETSI EN 300 743.

[Selur]

probably something like: ffmpeg -i 00038.m2ts -c:s copy "track_05 - Subtitles.sub" could be used, never really played with DVB subtitles, so can't say for sure. :)

[Music Fan]

I tried but it didn't work, I got several error messages and a 0 KB file was created.
I also tried sup extension instead of sub, no file was created.

[Selur]

-> google a bit and maybe you can find a solution :)

[Music Fan]

I found several topics about DVB-sub muxing and de-muxing with ffmpeg but no one is clear, I still didn't find any command I could use.:o
I don't know ffmpeg, it doesn't look easy to use.

[Selur]

then you are lost -> best ask inside another thread and may be someone with ffmpeg and dvb-sub experience can help you further :D good luck!

[Music Fan]

Ok, I created a topic in the subtitle part of the forum ;
http://forum.doom9.org/showthread.php?t=169795

[Sparktank]

Ok, looking into it.

Anyone know what happened to paradoxical?

Looking at his GitHub profile, I can see a couple new forks he created but very little contribution for this year.

[Chetwood]

I'd also like to know that. I was wondering if he could shed some light on how to identify forced subs on BDs (http://forum.doom9.org/showthread.php?p=1659305#post1659305).

[stax76]

Does anybody know how to contact the author? I have a sample clip where sup to sub conversion fails.

[cdlvcdlv]

Does anyone how to compile the source code in Windows?
I have tried with qt-opensource-windows-x86-mingw492-5.5.0.exe (958 MB) and qt-opensource-windows-x86-mingw482-4.8.6-1.exe (328 MB) + i686-4.8.2-release-posix-dwarf-rt_v3-rev3.7z (44 MB) but I get the same error. (I would prefer not to download/install such huge compiler.)

> qmake "bdsup2sub++.pro"


This creates Makefile and another files. No errors.

> mingw32-make
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -fexceptions -mthre
ads -Wall -Wextra -DUNICODE -DQT_DLL -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQ
T_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I"
f:\Subtitulos\Qt\4.8.6\include\QtCore" -I"f:\Subtitulos\Qt\4.8.6\include\QtGui"
-I"f:\Subtitulos\Qt\4.8.6\include\QtXml" -I"f:\Subtitulos\Qt\4.8.6\include" -I"f
:\Subtitulos\Qt\4.8.6\include\ActiveQt" -I"debug" -I"." -I"f:\Subtitulos\Qt\4.8.
6\mkspecs\win32-g++-4.6" -o debug\bdsup2sub.o bdsup2sub.cpp
bdsup2sub.cpp:52:37: fatal error: QxtCore/QxtCommandOptions: No such file or dir
ectory
#include <QxtCore/QxtCommandOptions>
^
compilation terminated.


If this is not the place to ask this question, maybe someone might tell me where it would be.

[sl1pkn07]

is a Qt4 program. make sure you use qmake from qt4 instead of qt5

[cdlvcdlv]

make sure you use qmake from qt4 instead of qt5
If I understand the version numbers then the first attempt was doomed to failure. But maybe I had a chance in second one.
I have tried with qt-opensource-windows-x86-mingw492-5.5.0.exe (958 MB) and qt-opensource-windows-x86-mingw482-4.8.6-1.exe (328 MB) + i686-4.8.2-release-posix-dwarf-rt_v3-rev3.7z (44 MB) but I get the same error.The numbers in bold are the relevant ones, aren't they? Strangely enough, the two attempts stopped with the same error message:

#include <QxtCore/QxtCommandOptions>
^
compilation terminated.So I think there is something more I'm missing.

By the way. What would be the minimal environment needed to compile bdsup2sub++? This is around half a GiB to generate a 4 MB exe... And even so without success.

Is relevant the compiler? In qt4, three choices exist. Namely - qt-opensource-windows-x86-mingw482-4.8.6-1.exe, qt-opensource-windows-x86-vs2008-4.8.6.exe and qt-opensource-windows-x86-vs2010-4.8.6.exe.

Saludos, compañero espanishtaní. ;)

[sl1pkn07]

yes, Qt4 is a 4.8.X series, Qt5 is a 5.x.x series

ok, i see, you need install qxt https://bitbucket.org/libqxt/libqxt/wiki/Home

[cdlvcdlv]

Dl and installed libqxt-0.6.2.zip from the link you posted, unzipped, run configure.bat, make and make install. Lots of warnings about vars declared but not used, but it generated the files and copied them to their folders.

Then go to bdsup2sub++ source folder, run qmake && make... lots of warnings again and in the end...
windres -i bdsup2sub.rc -o debug\bdsup2sub_res.o --include-dir=. -DUNICODE -DQXT
_CORE_LIB -DQT_DLL -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HA
VE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT
g++ -Wl,-subsystem,console -mthreads -o debug\bdsup2sub++.exe object_script.bdsu
p2sub++.Debug -L"f:\Subtitulos\Qt\4.8.6\lib" debug\bdsup2sub_res.o -LC:/Qxt/lib
-lQxtCored -lQtXmld4 -lQtGuid4 -lQtCored4
F:/Subtitulos/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64
-mingw32/bin/ld.exe: cannot find -lQxtCored
collect2.exe: error: ld returned 1 exit status
Makefile.Debug:197: recipe for target 'debug\bdsup2sub++.exe' failed
mingw32-make[1]: *** [debug\bdsup2sub++.exe] Error 1
mingw32-make[1]: Leaving directory 'D:/Datos/Subtitulos/Programas/BDSUP2SUB/BDSu
p2SubPlusPlus-master/src'
Makefile:34: recipe for target 'debug' failed
mingw32-make: *** [debug] Error 2After some searching, I found out that I should have configured libqxt with -debug (configure -debug), what I did. Then, the "qmake && make" runs OK. It's a 14 MB debug exe, with dynamic linking, so it needs 231 additional MB to run (libgcc_s_dw2-1.dll, libstdc++-6.dll, libwinpthread-1.dll, QtCored4.dll, QtGuid4.dll, QtXmld4.dll, QxtCored.dll). But placing the dlls in the .exe folder it works. If I manage to do something useful, I would find out how to make static linking to create the neat 4 MB of the usual bdsup2sub++ releases. It would be useful to know what compiler was used (mingw, VS2008 or VS2010). There may be differences regarding to final size and performance.

The code is well-structured, but not much documented about how the conversions are done so that you can understand clearly why it does what it does.

@Chetwood: Some warnings in the code are related to forced subtitles. I hope they shed some light on the question.In file included from Subtitles\suphd.cpp:20:0:
Subtitles\suphd.h:55:10: warning: unused parameter 'index' [-Wunused-parameter]
bool isForced(int index) { return false; }
In file included from Subtitles\supbd.cpp:25:0:
Subtitles\subpicturebd.h:171:10: warning: unused parameter 'isForced' [-Wunused-
parameter]
void setForced(bool isForced)
In file included from Subtitles\subpicturebd.cpp:20:0:
Subtitles\subpicturebd.h:171:10: warning: unused parameter 'isForced' [-Wunused-
parameter]
void setForced(bool isForced)
In file included from debug\moc_suphd.cpp:9:0:
debug\../Subtitles/suphd.h:55:10: warning: unused parameter 'index' [-Wunused-pa
rameter]
bool isForced(int index) { return false; }

[asarian]

I simply got my Windows binary of BDSub2Sup++ from a STAXrip distro. No need to make life harder than it already is. :)

[outgoing]

New version released 1.0.3

https://github.com/amichaeltm/BDSup2SubPlusPlus/releases

[jpsdr]

Euh... New version ???
released this on 10 May 2018

[outgoing]

Euh... New version ???

yup but here the last version published was the previous one.

[jpsdr]

Ah... Yes, indeed.

[captainayy]

So I'm a long-time user of this software and recently decided to try to fix some of the bugs that I've run into while using the software over the years since the development seems to have otherwise stalled out.

I've made a forked branch here (https://github.com/captainayy/BDSup2SubPlusPlus) where I've been doing most of my work. I was also able to contact the original author and they gave me commit access to their branch as well.

So over the last couple of weeks I've been working on knocking out a number of bugs and I thought I'd make a test build for people to try. That can be grabbed here (https://github.com/captainayy/BDSup2SubPlusPlus/releases/tag/1.0.4). There's only a 64-bit build at the moment as I don't have a 32-bit build chain set up, but I will try to get a 32-bit build out in the next few days. Since this is using Qt 5.15.2 it should work on Windows 7, but as I only have a Windows 10 box I cannot confirm this. Please let me know if you have any issues running it on that version.

This build includes fixes for a number of issues that I've come across including:

1) This issue (https://github.com/amichaeltm/BDSup2SubPlusPlus/issues/22) where the output resolution of an IDX/SUB would get messed up like the following shot:

https://user-images.githubusercontent.com/56635/110207057-9e7ff900-7e81-11eb-95a2-291141295d34.png

2) There was an infinite loop when checking a forced picture flag when loading a BD SUP file.

3) Fixed an issue that happened when I loaded an IDX/SUB file and then set a number of subtitles to be forced then saving to BDSUP.

4) Fixed an issue where in certain BD SUPs that not all the subtitles that should have been merged together were being merged (in particular there was a SUP file from Avatar I used in testing this fix). This also had the side effect of, at least in my tests, fixing an issue reported in this post (https://forum.doom9.org/showpost.php?p=1630830&postcount=193) where if you output as XML/PNG you could get a black second image for some subtitle events.

5) If you would load a subtitle and resave it, the size of the output subtitle would increase upon each saving. This was due to a bug where the output image size and position were not staying the same as the input due to not clamping the width/height and x/y offsets. Those values are now being rounded down so that they will match the original size if the resolution and position are not otherwise changed. This now means that the files do not bloat each time you resave it with no edits.

I can also see there are a number of other outstanding issues on both the original repo and on that second forked repo that I've been given access to, but a lot of the files linked there are no longer accessible. So for anyone else who is still using this tool and would like to re-test with any files they've previously had issues with hopefully you can repost those files and open an issue on my issue tracker here:

https://github.com/captainayy/BDSup2SubPlusPlus/issues

I can't guarantee that I can implement all the requested extra features for the program (though I can certainly try) but I would at least like to get the current code to be a bit more stable and bug-free. I only have a few hours a week to work on this so development might be a bit slow but I will try to do my best. :)

[von Suppé]

So I'm a long-time user of this software and recently decided to try to fix some of the bugs that I've run into while using the software over the years since the development seems to have otherwise stalled out.
Nice to see someone taking this up. I'll test your fork later.

One of the issues that pops to mind is, BDSup2SUb would always recode images. When the images themselves need no editing (no scaling), it'd be nice if BDSup2Sub would leave them untouched. With "Output Format" set same as source (or, for instance BD SUP <--> XML/PNG) and "Palette" as "keep existing", think of only changing offsets and/or timing alterations.
Did you address this?

[Bandits]

So I'm a long-time user of this software and recently decided to try to fix some of the bugs that I've run into while using the software over the years since the development seems to have otherwise stalled out.

I've made a forked branch here (https://github.com/captainayy/BDSup2SubPlusPlus) where I've been doing most of my work. I was also able to contact the original author and they gave me commit access to their branch as well.

So over the last couple of weeks I've been working on knocking out a number of bugs and I thought I'd make a test build for people to try. That can be grabbed here (https://github.com/captainayy/BDSup2SubPlusPlus/releases/tag/1.0.4). There's only a 64-bit build at the moment as I don't have a 32-bit build chain set up, but I will try to get a 32-bit build out in the next few days. Since this is using Qt 5.15.2 it should work on Windows 7, but as I only have a Windows 10 box I cannot confirm this. Please let me know if you have any issues running it on that version.

This build includes fixes for a number of issues that I've come across including:

1) This issue (https://github.com/amichaeltm/BDSup2SubPlusPlus/issues/22) where the output resolution of an IDX/SUB would get messed up like the following shot:

2) There was an infinite loop when checking a forced picture flag when loading a BD SUP file.

3) Fixed an issue that happened when I loaded an IDX/SUB file and then set a number of subtitles to be forced then saving to BDSUP.

4) Fixed an issue where in certain BD SUPs that not all the subtitles that should have been merged together were being merged (in particular there was a SUP file from Avatar I used in testing this fix). This also had the side effect of, at least in my tests, fixing an issue reported in this post (https://forum.doom9.org/showpost.php?p=1630830&postcount=193) where if you output as XML/PNG you could get a black second image for some subtitle events.

5) If you would load a subtitle and resave it, the size of the output subtitle would increase upon each saving. This was due to a bug where the output image size and position were not staying the same as the input due to not clamping the width/height and x/y offsets. Those values are now being rounded down so that they will match the original size if the resolution and position are not otherwise changed. This now means that the files do not bloat each time you resave it with no edits.

I can also see there are a number of other outstanding issues on both the original repo and on that second forked repo that I've been given access to, but a lot of the files linked there are no longer accessible. So for anyone else who is still using this tool and would like to re-test with any files they've previously had issues with hopefully you can repost those files and open an issue on my issue tracker here:

https://github.com/captainayy/BDSup2SubPlusPlus/issues

I can't guarantee that I can implement all the requested extra features for the program (though I can certainly try) but I would at least like to get the current code to be a bit more stable and bug-free. I only have a few hours a week to work on this so development might be a bit slow but I will try to do my best. :)

Have you looked at this post?

https://forum.doom9.org/showthread.php?p=1828627#post1828627

[von Suppé]

Have you looked at this post?

https://forum.doom9.org/showthread.php?p=1828627#post1828627
Good link indeed, I know I've read it some time. r0lZ is very aware of the several bugs in various versions, as his BD3D2MK3D tool also uses BDSup2Sub.
As for point 6 in that post, I do have a comment/request.

Cropping the transparent rectangular around the text can cause a nasty effect. As for vertical positioning, when authoring image based subtitles, one has to take into account that the type of characters will determine the height of the image. Images of lines with "low" characters like "a c e r m n" will come out lower than those with characters like "A C E g y r ç". Properly authored SUBs and SUPs have a deliberately added transparent background in such a way, that it seems all lines were "written on the same line".
So, editing the transparent surrounds can have a "bobbing" effect on subtitles that are quickly consecutive. If possible, I'd like to see at least the possibility to leave the transparent borders untouched.

[captainayy]

Have you looked at this post?

https://forum.doom9.org/showthread.php?p=1828627#post1828627

Yes. If you read the list of items I fixed you should note that 6, 7, 9 and 10 should all be fixed in this test build. At least as far as I can tell with the files I could trigger the issues with. :)

But, I still need people to also test and verify if those things are completely fixed for the subtitle files that they have that trigger them as I only have so many examples to test with. Also, the file sample linked in that post is no longer accessible so hence the request that anyone file an issue and repost their files with issues if they can still reproduce them.

[captainayy]

One of the issues that pops to mind is, BDSup2SUb would always recode images. When the images themselves need no editing (no scaling), it'd be nice if BDSup2Sub would leave them untouched. With "Output Format" set same as source (or, for instance BD SUP <--> XML/PNG) and "Palette" as "keep existing", think of only changing offsets and/or timing alterations.
Did you address this?
No, but I did have the similar idea in mind allowing for a setting that prevents it from trying to optimize the images and leaves them untouched when saving. I'll add it to my TODO list. :goodpost:

I'm thinking that I'd probably leave the default behavior as is unless you specify either through a UI setting or a new CLI switch to not optimize the images.

[hubblec4]

thanks captainayy for your work on this project.
When I have time I will help to test some fixes.
I had also posted some issues to the old repo from amichaeltm. Should I renew this issues in your repo?

[captainayy]

thanks captainayy for your work on this project.
When I have time I will help to test some fixes.
I had also posted some issues to the old repo from amichaeltm. Should I renew this issues in your repo?

Yeah feel free. Also having any additional samples to test against for regressions, etc. would be great if anyone can provide them. :)

[r0lZ]

So I'm a long-time user of this software and recently decided to try to fix some of the bugs
Great news ! Thanks a lot.

You already know the posts where I tried to describe the bugs I discovered. I hope I can be helpful by giving some examples of problematic subtitle streams. I'm not sure I have the time and inclination to test myself if the bugs are really fixed, but I'll try to help as much as I can.

Avatar.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Avatar.sup)

full-width subtitles.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/full-width%20subtitles.sup)

Bad Palette Sample.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Bad%20Palette%20Sample.sup)

Multiple_ODS_sample.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Multiple_ODS_sample.sup)

[captainayy]

Great news ! Thanks a lot.

You already know the posts where I tried to describe the bugs I discovered. I hope I can be helpful by giving some examples of problematic subtitle streams. I'm not sure I have the time and inclination to test myself if the bugs are really fixed, but I'll try to help as much as I can.

Avatar.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Avatar.sup)

full-width subtitles.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/full-width%20subtitles.sup)

Bad Palette Sample.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Bad%20Palette%20Sample.sup)

Multiple_ODS_sample.sup (https://download.videohelp.com/r0lZ/ProblematicSubs/Multiple_ODS_sample.sup)

I will take a look at those samples. Thank you!

Edit:

I've only had a chance so far to open up the full-width subtitles.sup one but that one has an interesting thing where it looks like the x1 position value is overflowing a 32-bit signed integer value:

https://i.ibb.co/dg37KM9/image.png

As you can see in the next index the position values are correct again:

https://i.ibb.co/yFGJ06S/image.png

Interesting stuff...

[captainayy]

Well I was at least so far able to solve the issue with the full-width subtitles.sup file. It may be a few days before I can double check the others. The other benefit to the fix is that this can now extract one additional subpicture that SubtitleEdit cannot. Subtitle #30 gets mangled like this:

https://i.ibb.co/N6D2c8w/image.png

where as bdsup2sub++ can extract two subtitles. Though the first one obviously is a bit off because off what looks like missing data in the SUP file.

https://i.ibb.co/m5HtPtp/image.png

https://i.ibb.co/60kLW2z/image.png

I guess I should ask, how was this file made? There's a huge amount of data that is just zeros in the file. For that subtitle 30, there's a segment size defined for the ODS data that ends up pointing into the middle of that zero'd out data. This trips up the original BDSup2Sub and this version as well. So I had to add some code that basically searches the rest of the SUP file to try to find the next PGS segment or it hits the end of the file. That helped it find that subtitle #31 and allowed it to continue parsing the rest of the PGS blocks in the file.

[r0lZ]

I guess I should ask, how was this file made?
Honestly, I don't remember. I just kept it with the other "problematic subtitles" just to have them at my disposal for further analysis. I remember only that it was extracted from an oriental movie. AFAIK, all BDs with such full-width subtitles are coming from China, Hong Kong, Korea, India etc... Those BD are usually badly authored, especially the 3D-BD, where the subtitles are almost always flat, and often containing errors. Also, many times, but not always, they contain a fully invisible subtitle starting at 0:00:00, for an unknown reason.

IIRC, I have extracted the subtitle stream with TsMuxeR, but I don't think it is the culprit.

[captainayy]

Honestly, I don't remember. I just kept it with the other "problematic subtitles" just to have them at my disposal for further analysis. I remember only that it was extracted from an oriental movie. AFAIK, all BDs with such full-width subtitles are coming from China, Hong Kong, Korea, India etc... Those BD are usually badly authored, especially the 3D-BD, where the subtitles are almost always flat, and often containing errors. Also, many times, but not always, they contain a fully invisible subtitle starting at 0:00:00, for an unknown reason.

IIRC, I have extracted the subtitle stream with TsMuxeR, but I don't think it is the culprit.

Cool. Yeah I definitely appreciate the extra problematic samples to test against. It was just really weird seeing a whole section of the file that what was MBs and MBs of just zeros so was just curious if that was done intentionally to create a broken file or if someone actually really did author such a broken subtitle stream (yikes.... :scared:). :thanks:

I'll try to look at the other samples here this weekend, but I think I have something close enough to a fix at least for that sample. Just need to test that the fix doesn't cause issues for anything else that previously works.

[mood]

it's possible not open cmd line window on startup?

Save the language option "remember last language saved" so you don't have to change language every time you save a subtitle?

thanks ;)

[captainayy]

it's possible not open cmd line window on startup?

Unless something has changed this is a limitation of Qt applications on Windows that support running both via GUI and commandline. The issue only manifests on Windows and Linux or macOS has no such issue. If you can point me to a solution that would allow both console support and GUI support to continue working on Windows without also affecting console output and redirection when run via CLI, then I would happily merge it in.

Though I'm a few years behind on doing Qt application development so if there's a way to solve the issue I'm all ears.

[von Suppé]

I'm thinking that I'd probably leave the default behavior as is unless you specify either through a UI setting or a new CLI switch to not optimize the images.
As for GUI, it would be nice if that option would be present in the "Conversion Settings" window and its setting would be remembered.

[hubblec4]

Yes this seems to be a behaviour on Window. On Linux I have also no console at startup.
One solution I have found was to start such a program in minimized state and bring it to normal state.

[von Suppé]

The time-editor in the "Edit Frame" window behaves weird when trying to apply small increases or decreases for the "Start Time" and "End Time" values. The edited timecode jumps back to it's native value when saving changes, or Start and End Time end up showing same value.
I also wonder why the Duration value shows two decimals, where the unit is already milliseconds (ms).

[captainayy]

As for GUI, it would be nice if that option would be present in the "Conversion Settings" window and its setting would be remembered.

Yeah, that's what I was thinking as well. I'll make it unchecked by default to not break existing behavior, but will make it a setting in the INI that would be restored if you check it.

The time-editor in the "Edit Frame" window behaves weird when trying to apply small increases or decreases for the "Start Time" and "End Time" values. The edited timecode jumps back to it's native value when saving changes, or Start and End Time end up showing same value.

Ok, I will look into this.

I also wonder why the Duration value shows two decimals, where the unit is already milliseconds (ms).

No idea, but I agree. Should just be rounded to an integer value.

Yes this seems to be a behaviour on Window. On Linux I have also no console at startup.
One solution I have found was to start such a program in minimized state and bring it to normal state.

Appreciate the suggestion. I'll look into doing that.

[von Suppé]

I had a short play-around with your latest 1.0.4b. I noticed that in "Edit Frame" window, changing X and Y offsets don't work. After "Save Changes", offsets jump back to initial values. To be sure I also checked export result. Can you take a look? Also Center, Top and Bottom buttons seem to not respond.

With SUP, Y offset starts counting at the top pixel. Therefor, "top offset" value is pretty easy to visualize. What I'm missing in the "Frame Edit" window is the option to set a "bottom offset" value (in conjunction to the above-mentioned "Bottom" button). Of course one can back-calculate by "screensize minus Y offset minus image height", but it's too cumbersome. In the "move all captions" window this function is present. I think the option belongs in "single image edit" too.

[captainayy]

I had a short play-around with your latest 1.0.4b. I noticed that in "Edit Frame" window, changing X and Y offsets don't work. After "Save Changes", offsets jump back to initial values. To be sure I also checked export result. Can you take a look? Also Center, Top and Bottom buttons seem to not respond.

Yeah I figured it out. Seems to be the same issue I fixed here in this commit:

https://github.com/captainayy/BDSup2SubPlusPlus/commit/d28667cbd96b00d4745fe013da444fa3c9445ef7

Looks like the previous person working on this was trying to move some old-style for loops to the newer C++11 foreach loops but didn't do it properly so the loops only edit a copy of an object not the original objects itself when iterating over them. That seems to also be the issue you noticed in the Edit Frame dialog because as soon as I changed the loop to work on object references the values stuck around after you leave the text box. I'll have to go through the code and try to figure out where else this might have occurred.

With SUP, Y offset starts counting at the top pixel. Therefor, "top offset" value is pretty easy to visualize. What I'm missing in the "Frame Edit" window is the option to set a "bottom offset" value (in conjunction to the above-mentioned "Bottom" button). Of course one can back-calculate by "screensize minus Y offset minus image height", but it's too cumbersome. In the "move all captions" window this function is present. I think the option belongs in "single image edit" too.

I can look into this but no promises on changing things simply because I don't know the full scope and impact of such a change. It would require some exploration and probably feedback from other users as this would be a breaking change with old behavior. This will probably get pushed back a bit in lieu of fixing other bugs, but I've added it to my TODO list to look at.

[von Suppé]

Another option - if possible - I'd like to see is to be able to put in framenumber in the "Edit Frame" window, just like in the JAVA version.

https://i.ibb.co/CtgzG8N/framenumber.png (https://imgbb.com/)

[sfatula]

Can't seem to find any, in case it exists somewhere or easy to post, I need to make a build on arm64. Is there a place where the package requirements are documented?

[Stereodude]

I've only had a chance so far to open up the full-width subtitles.sup one but that one has an interesting thing where it looks like the x1 position value is overflowing a 32-bit signed integer value:

https://i.ibb.co/dg37KM9/image.png

As you can see in the next index the position values are correct again:

https://i.ibb.co/yFGJ06S/image.png

Interesting stuff...
FWIW, the forced subtitles in the English subtitle track from the 2D US Blu-ray of Avatar track do the same thing.

https://i.imgur.com/p4CilFa.png

The forced subtitles in the English subtitle track from the 3D US Blu-ray of Avatar does not.

BTW, thanks for your efforts! :thanks:

[r0lZ]

Avatar 3D is well known for the problem of their subtitles. In the BD3D, there are two subtitle streams with the same UIDs, one in the main AVC M2TS (the primary view, used when you watch the stream in 2D) and one in the AVC M2TS (dependent stream, used only for 3D). If you are using the 3D version of the BD, don't worry, as 2 streams with the same UID cannot be parsed correctly with most software demuxers !

[Stereodude]

Avatar 3D is well known for the problem of their subtitles. In the BD3D, there are two subtitle streams with the same UIDs, one in the main AVC M2TS (the primary view, used when you watch the stream in 2D) and one in the AVC M2TS (dependent stream, used only for 3D). If you are using the 3D version of the BD, don't worry, as 2 streams with the same UID cannot be parsed correctly with most software demuxers !
Interesting... I found the 2D version to be more broken than the 3D with the single .sup the demuxer's find, but I wasn't aware there were two subtitles streams with one for each eye. I watched the 3D Blu-ray rip (made with MakeMKV) with my GF over the weekend and discovered the forced subtitles were messed up. The .mkv only has 1 subtitle stream, so that's where I started. I now have a mkv of each with forced subtitles that have only the correct subtitles in them, that display for the right amount of time, that appear in the right place on the screen. There's only one .sup in each though.

Is there actually a way to handle the two subtitle streams for the 3D disc correctly in a .mkv?

Edit: Or a way to create a .mkv without re-encoding that has subtitles with the same 3D depth as the original Blu-ray?
Edit2: Seems like there is no way to assign a 3D plane to the .sup in a .mkv

[von Suppé]

Is there actually a way to handle the two subtitle streams for the 3D disc correctly in a .mkv?

3DBD usually carries one subtitle. Not one for each eye. Avatar is just an odd one out. Subtitle depth information is present in so-called "3D planes" which are carried by the MVC stream. A 3D compatible player can read this information and will create the second subtitle with the proper offset, and overlay this on frames for the other eye.

As such, mkv just carries the same one subtitle (for each language of course) that's in the AVC mainstream of a 3D disc. Regarding video, main difference between 3D bluray and 3Dmvc-mkv is that the AVC-stream and MVC-stream are interleaved into one elememtary videostream. This is what MakeMKV does.

[r0lZ]

Yes. And the number of the 3D-Plane associated with a particular subtitle stream is stored in the MPLS file on the 3DBD. Since that file is lost when MakeMKV muxes the tracks to the final MKV 3D, the 3D-Plane number was lost too, but I have asked to copy it in a special tag. That information is therefore available now (and is used by BD3D2MK3D) when the 3D MKV has been created by MakeMKV. I don't know if it is possible to modify or specify that tag manually.
BTW, a similar problem existed for the order of the main and dependent video streams (left/right or right/left eyes). With old versions of MakeMKV, that information was also lost, then incorrect, but it should be available and correct now.

[von Suppé]

From day one, I've always been creating BD-ISO for "movie-only" and my homebrew sups. Always worked on every 3D player. I have very limited experience with mvc-mkv.

...to copy it in a special tag. That information is therefore available now...

Am I right to consequently assume that displaying the (intended) subtitle depth will be at the mercy of a player's ability to read this special tag in the first place?
Interesting anyways. When I have time I'll rip a 3DBD with MakeMKV and go see for myself.

Edit2: Seems like there is no way to assign a 3D plane to the .sup in a .mkv
I don't know if it is possible to modify or specify that tag manually.

If not, there may be a workaround. First create a 3DBD with tsMuxer (where you can assign the right 3D-plane to a PGS stream). Rip that result with MakeMKV. Hopefully this works.

[Stereodude]

Yes. And the number of the 3D-Plane associated with a particular subtitle stream is stored in the MPLS file on the 3DBD. Since that file is lost when MakeMKV muxes the tracks to the final MKV 3D, the 3D-Plane number was lost too, but I have asked to copy it in a special tag. That information is therefore available now (and is used by BD3D2MK3D) when the 3D MKV has been created by MakeMKV. I don't know if it is possible to modify or specify that tag manually.
BTW, a similar problem existed for the order of the main and dependent video streams (left/right or right/left eyes). With old versions of MakeMKV, that information was also lost, then incorrect, but it should be available and correct now.
Mosu said there was no way to assign a PGS subtitle (.sup from Blu-ray) to a 3D plane in a .mkv container. How is MakeMKV putting that into the file? Additionally, do any software or hardware players use that tag?

[Stereodude]

3DBD usually carries one subtitle. Not one for each eye. Avatar is just an odd one out. Subtitle depth information is present in so-called "3D planes" which are carried by the MVC stream. A 3D compatible player can read this information and will create the second subtitle with the proper offset, and overlay this on frames for the other eye.

As such, mkv just carries the same one subtitle (for each language of course) that's in the AVC mainstream of a 3D disc. Regarding video, main difference between 3D bluray and 3Dmvc-mkv is that the AVC-stream and MVC-stream are interleaved into one elememtary videostream. This is what MakeMKV does.
Are you sure that all 3D versions of Avatar do this? Mine shows only 1 PGS subtitle and it's assigned to a 3D plane from the MVC. What tool should I use to see the 2nd subtitle track? (if it's there)

https://i.imgur.com/SA0UFkK.png

[Stereodude]

From day one, I've always been creating BD-ISO for "movie-only" and my homebrew sups. Always worked on every 3D player. I have very limited experience with mvc-mkv.
I came to that conclusion yesterday... That a "movie only" BD-ISO is a better way to rip 3D Blu-rays. I had only ripped a few to .mkv for testing. I used TSmuxer and the .mkv to make a .ISO from them. I used the original 3D Blu-ray to find the right plane to assign the PGS subs to.

[von Suppé]

How is MakeMKV putting that into the file?

Unless I'm missing something here, I think r0lZ has answered this. He asked for a special tag with that data and his request obviously was honoured. So when a MakeMKV-created 3D-mkv is imported in BD3D2MK3D, the tag can be read to determine the right 3D-planes.

Are you sure that all 3D versions of Avatar do this? Mine shows only 1 PGS subtitle and it's assigned to a 3D plane from the MVC. What tool should I use to see the 2nd subtitle track? (if it's there)

No, I am not sure. It's been a long time and don't remember how my Avatar disc layout looked like. Also I don't think I have the US version.
Doesn't the second subtitle show already in your screenshot (at the bottom, as disabled)? Isn't that the one used for 2D, like r0lZ said?

[EDIT] I just realised we're still in the bdsup2sub++ thread. To avoid further pollution, shouldn't we better continue this conversation in your "Avatar sups" thread?

[r0lZ]

Am I right to consequently assume that displaying the (intended) subtitle depth will be at the mercy of a player's ability to read this special tag in the first place?
Interesting anyways. When I have time I'll rip a 3DBD with MakeMKV and go see for myself.
Mosu said there was no way to assign a PGS subtitle (.sup from Blu-ray) to a 3D plane in a .mkv container. How is MakeMKV putting that into the file? Additionally, do any software or hardware players use that tag?
Honestly, I don't know. I have requested that tag for BD3D2MK3D, but I don't know if it is used by some players. It's theoretically possible but...

The tag is called "tag_3d-plane".

[r0lZ]

Are you sure that all 3D versions of Avatar do this? Mine shows only 1 PGS subtitle and it's assigned to a 3D plane from the MVC. What tool should I use to see the 2nd subtitle track? (if it's there)
That's exactly the problem. Since the 2 streams share the same UID, it is difficult for a software to discover that there are indeed two independent subtitle streams. Hence some major problems when you demux that streams with some demuxers (IIRC, with eac3to for example). The demuxer is confused by some overlapping subtitles and/or conflicting time-codes.

Note also that the main, normal subtitle track is, as it should, in the M2TS with the main 2D view (with the AVC video stream, all audio streams and the "standard" subtitle streams). The second track is in the "dependent M2TS", containing normally only the MVC video stream (for the second view, used only for 3D playback).

The second stream has NOT the same content than the first. It contains a full-screen panel with a message telling something like "put your 3D-glasses now". Not sure how a player is supposed to use that stream, and when it should be displayed (since, AFAIK, the player has no way to know if the 3D-glasses are used or not).

Of course, you can demux only the main M2TS. The demuxer will see only a single stream, and everything will work as expected. You can also try to demux the dependent M2TS alone, and you will probably succeed. The problem occurs when you try to demux the MPLS or the two M2TS at the same time.

Also, it is possible that recent editions of Avatar do not have the problem any more.

[r0lZ]

[EDIT] I just realised we're still in the bdsup2sub++ thread. To avoid further pollution, shouldn't we better continue this conversation in your "Avatar sups" thread?
Right. Unfortunately, I see this only now !

Perhaps a mod can move the last posts to the Avatar thread ? Thanks !

[r0lZ]

So over the last couple of weeks I've been working on knocking out a number of bugs and I thought I'd make a test build for people to try. That can be grabbed here (https://github.com/captainayy/BDSup2SubPlusPlus/releases/tag/1.0.4).
Indeed, some bugs are fixed. A crash of v1.0.3 has been reported here (https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-TAB-or-FS-MKV-Support-thread/page9#post2669892) (with the difficult subtitles of Avatar 3D). I have checked the problematic SUP stream with v1.0.4b and the crash doesn't occur any more. I have therefore decided to replace the official v1.0.3 with your beta in BD3D2MK3D.

Is it possible to provide a 32-bit version ? That will be useful for peoples with an old hardware, still supported by BD3D2MK3D. Also, do you plan to release a new beta, or a final version soon ?

Thanks anyway for the current beta !

[oniiz86]

I know this is completely trivial & inconsequential but was curious if anyone or @r0lZ has experienced the default language to be set to "Cree (cr)" when exporting to VobSub (IDX/SUB)? When exporting to SUP to SUP(BD) there is no such issue, it's such a shame that @captainayy hadn't developed it further as his 1.04b beta release was really promising. :(
https://i.imgur.com/1mHVB0X.png

[chompy]

Hello,

I've just installed v1.0.4b and I've found a little bug:

If a frame is excluded from export and you export the subtitle in XML/PNG format, the corresponding PNG to that frame is not created, but the reference to it in the XML file is not deleted (exporting to SUP works as expected).

Thanks

[chompy]

Hello,

There's another bug I've just found: X Offset and Y Offset does not work on SUP subtitles, you can change values, but then original values are written again.

Thanks

[hidef_rec]

Hi. Is there a way w/this tool or another to edit a .sup (PGS) subtitle to remove certain lines and save as .sup? Not convert.

[Music Fan]

Yes, with Subtitle Edit. I don't know if bdsup2sub++ can.

[Bandits]

Hi. Is there a way w/this tool or another to edit a .sup (PGS) subtitle to remove certain lines and save as .sup? Not convert.

What do you mean remove lines?

PGS are images. If you want to remove a whole frame, then yes you can do it with bdsup2sub. You have to export it as xml/png, remove the frames you don't want from the xml, then resave as sup.

I do this to merge forced events into the main subtitle stream when they are in separate streams. I made my own tool to do this in a gui so I could see what I was doing.

For manual way:
Open sup in bdsup2sub
Export to xml
Open the xml in text editor
Find the frame info in bdsup2sub
Delete the matching entry in the xml
Save the xml
Open the xml in bdsup2sub
Export to sup.

You don't have to worry about the png's. Your new file will only have what was listed in the xml.