bdsup2sub++ - convert and tweak bitmap subtitles.

[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/BDSup2...sPlus/releases

[jpsdr]

Euh... New version ???

released this on 10 May 2018

[outgoing]

Originally Posted by jpsdr

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 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. 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 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 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é]

Originally Posted by 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.

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]

Originally Posted by 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 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. 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 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 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.p...27#post1828627

[von Suppé]

Originally Posted by Bandits

Have you looked at this post?

https://forum.doom9.org/showthread.p...27#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]

Originally Posted by Bandits

Have you looked at this post?

https://forum.doom9.org/showthread.p...27#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]

Originally Posted by von Suppé

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.

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]

Originally Posted by 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?

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

[r0lZ]

Originally Posted by captainayy

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

full-width subtitles.sup

Bad Palette Sample.sup

Multiple_ODS_sample.sup

[captainayy]

Originally Posted by r0lZ

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

full-width subtitles.sup

Bad Palette Sample.sup

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:



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



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:



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.





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]

Originally Posted by captainayy

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]

Originally Posted by r0lZ

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

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]

Originally Posted by mood

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.