bdsup2sub++ - convert and tweak bitmap subtitles.

[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)