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

[r0lZ]

AFAIK, the subtitles for UHD movies are identical to the subtitles for Full-HD (2K). It is the responsibility of the player to upscale them to 4K at playback time.

However, me too, I would like support for larger subtitles, not for UHD, but for 3D in Full-SBS or Full-T&B format.

[jpsdr]

What is the actual status of developement ?

[asarian]

The whole program (4.0) doesn't sppear to be available on the server any more. :( Is this tool dead?!

[r0lZ]

You can download any version at VideoHelp (https://www.videohelp.com/software/BDSup2Sub). But the most recent version is not necessarily the best. See here (https://forum.doom9.org/showthread.php?p=1828627#post1828627).

And yes, the development has stopped, although from time to time someone claims that he wants to continue it... and he abandons a few weeks later.

[asarian]

You can download any version at VideoHelp (https://www.videohelp.com/software/BDSup2Sub). But the most recent version is not necessarily the best. See here (https://forum.doom9.org/showthread.php?p=1828627#post1828627).

And yes, the development has stopped, although from time to time someone claims that he wants to continue it... and he abandons a few weeks later.

Thanks for the reply. :)

[asarian]

I just tried BDSup2Sub++, to relocate (lower) my subs. Unlike it Java predecessor, which could export to another .sup file again, BDSup2Sub++ however exports to a much smaller .sub file. :( I have no idea what to do with that.

EDIT: Seems core.sub.ImageFile can handle the resulting .idx files. :) Solved.

[asarian]

Because you didn't change the Output Format to SUP(BD)?

https://i.postimg.cc/Hk2cDDNv/BDSup2-Sub.png

Dang, missed that one. :) Anyway, see above, core.sub.ImageFile could handle the .idx file just fine. But it's good to know, thanks.

[asarian]

After the loading of a .sup-file with BDSup2Sub++ 1.0.3 some subtitles are duplicated. The time stamp shows:
subtitle 10:
start 01:31:41.663
end 01:31:43.665

subtitle 11:
start 01:31:43.665
end 01:31:45.041The text of subtitle 10 and 11 are identical. Subtitles 10 and 11 should be displayed as a single subtitle.
The same file opened with Subtitle Edit 3.5.6 doesn't show this behaviour.

https://www.file-upload.net/download-13138212/Asura_t00ID5German.sup.html

Sadly, I got the same issue. :( Extracted with eac3to, my original 'Cutie Honey' Blu-ray contains 796 subs. After I lowered them all, with BDSup2Sub++ (to idx), the amount is still 796, but many subtitles (across the entire movie, around 50 times) are duplicated, shortly after appearing (with like a 0.2 sec interval inbetween).

Since the total amnount of subs remains the same, the only logical inference is that BDSup2Sub++ already messes them up (slightly) on importing them.

This is an annoying way of looking at subs, as it makes them jittery and redundant.

EDIT: Just looked closer, and yes, it's already in the imported list of subs. For instance, sub 140 and 141 are identical (very shortly following each other).

EDIT2: Just tried Subtitle Edit. It only shows 643 subs (meaning BDSup2Sub++ actually yields 153 duplicated subs, instead of my modest ~50 estimate). Unfortunately, Subtitle Edit immediately crashes when you click OK (it seems to want to OCR things).

[r0lZ]

After the loading of a .sup-file with BDSup2Sub++ 1.0.3 some subtitles are duplicated.
I have had the same problem with ++ and a specific BD (I don't remember which one). However, the Java version doesn't have that problem.

Also, note that the two versions have a CLI option to control the merging of the identical subtitles. It defines the maximum duration between two identical subtitles before they should be considered as two different subtitles. The option is -x <time_in_ms> or --merge-time <time_in_ms> and the default value is 200 ms for both versions. I don't know if that option is available in the GUI. And I don't know why that option doesn't work with BDSup2Sub++ and some specific subtitle streams.

Again, I suggest to keep the two versions of BDSup2Sbb and use the one that works best for each case.

(I have updated the list of bugs of the two versions here (https://forum.doom9.org/showthread.php?p=1828627#post1828627).)

[asarian]

I have had the same problem with ++ and a specific BD (I don't remember which one). However, the Java version doesn't have that problem.

Also, note that the two versions have a CLI option to control the merging of the identical subtitles. It defines the maximum duration between two identical subtitles before they should be considered as two different subtitles. The option is -x <time_in_ms> or --merge-time <time_in_ms> and the default value is 200 ms for both versions. I don't know if that option is available in the GUI.

That's cute, but duplicate subs, in 'real life', so to speak, rarely occur to begin with (like maybe when calling out someone's name, or with other expletives -- which is also the reason, btw, why the CLI method is tricky/unreliable). More importantly, though, why have a CLI that tries and fix errors you made yourself in the first place!? BDSup2Sub++ simply shouldn't duplicate subs on import, period. Just feels like a grave bug to me.

For now, I went with the old 'just download some .SRT from the internet' route, for my Cutie Honey Blu-ray. Problem with those, of course, is that you'll spend the next hour(s) or so repairing all sorts of typos/spelling errors in them, before you can actually use those (which is why I hate OCR). So, in general, I'd rather just use the official .PGS data; and for that a program like BDSup2Sub++ is needed.

Thx for the info, though.

[r0lZ]

I agree that the subtitles *should* be read correctly in the first place, but things are much more complicated. BD subs are really complex, with for example, the possibility to display several subtitles at the same time ("multiple ODS"). It is therefore not easy to distinguish when and why a subtitle appears several times in the source stream. Hence the CLI trick to merge them.

Anyway, unfortunately, BDSup2Sub is not developed any more, and we have to live with its limitations and bugs.

[asarian]

I agree that the subtitles *should* be read correctly in the first place, but things are much more complicated. BD subs are really complex, with for example, the possibility to display several subtitles at the same time ("multiple ODS"). It is therefore not easy to distinguish when and why a subtitle appears several times in the source stream.

Identical subtitles, appearing within miliseconds after each other, at the same screen location, I think anyone writing a subtitle program could safely merge those. :) But anyway, like you say, the point is moot, as BDSup2Sub++ is apparently no longer maintained.

P.S. Nice write-up on all the bugs. :) It's appreciated.

[LeXXuz]

I usually just use BDSup2Sub to shift PGS subtitles into bounds of the movie after black bars have been cropped in a recode.

I noticed the exported PGS always increase in file size, roughly around 10%, compared to the source PGS. Any reason for this?

I'm not talking about PGS with multiple PDS/ODS which may explain the increase. It happens even with simple PGS I created with SubtitleEdit.

[r0lZ]

I have noticed the same thing, and me too, I wonder why. Since the bitmaps of the PGS subtitles are compressed, the compression ratio may be less efficient when BDSup2Sub saves the stream, but modifying only the Y position should not require to recompress the bitmap (except if the subtitle is in a full-screen mainly transparent bitmap that must be cropped, but it's rarely the case). I guess BDSup2Sub recompresses it anyway.

[sneaker_ger]

Maybe the increase isn't due to the bitmaps themselves but other parts of the bitstream? What format are the bitmaps? Does it make a difference if you only move by mod4 or mod2?

Can you upload source+output as example?

[LeXXuz]

I think r0lZ thoughts about different compression efficiency may be correct.

Even if you don't touch the stream at all, meaning simply load and export again, you'll get a bigger file with almost any PGS.

EDIT: Okay I'm not sure about the compression anymore. As the export of an export gets even bigger in file size. Something seems to produce an overhead. But what?

[r0lZ]

Can you upload source+output as example?I don't have the source.

My program BD3D2MK3D uses BDSup2Sub to convert the subtitles to 3D, and it saves also a 2D version of the same stream, without real modifications, and usually it is around 10% larger than the original file, extracted from the BD with tsMuxeR 3D.

I think (but I'm not sure) that the PGS bitmaps are compressed with the LZH algorithm, like the PNG images. LZH can compress very well, but that requires much time. Maybe BDSup2Sub compresses faster, and therefore less.

[LeXXuz]

See my edited post. Shouldn't the resulting file size stay the same in that scenario?

[r0lZ]

EDIT: Okay I'm not sure about the compression anymore. As the export of an export gets even bigger in file size. Something seems to produce an overhead. But what?Just did the test, and indeed, when BDSup2Sub++ re-saves the same stream, there is an additional increase of the file size. But that doesn't happen with the Java version.
So, it seems that the ++ version has an additional bug... :-(

[EDIT] I've added that little bug as bug #10 in the bugs list here (https://forum.doom9.org/showthread.php?p=1828627#post1828627).

[hubblec4]

Many thanks for finding this bug. I know what you both mean and I thought this is OK, but now I know it is a bug.
The Java versions seams to be the better one.

[Ditleg]

Yes:), some Bluray titles don't have subtitles that the DVD versión does have, and sometimes de DVD version is better placed or have better font (Warner BR subtitles are placed in the black bars if the movie is 2.35, some of us hate that, and right now there's no way to change the position, the DVD subtitles can be placed inside the 2.35 image itself).

Another petition, an option to resize BR subs from 1080p to 720p, currently it's not possible to have BD5 at 720 with subtitles because no program exist that converts the subs from 1080p to 720p.

:thanks:
Yes, you can't convert the subs from 1080p to 720p, cuz it's none of video resolution business.

[Arbie]

I'm sure this has been asked and answered, but the forum doesn't seem to let me search only one thread and it's 73 pages now...

--> Is there a Windows version?

Thx

[LigH]

This is a Java application. If you install a Java Runtime Environment to your Windows, it runs under Windows.

[r0lZ]

There is also a Windows version written in C++ that doesn't require Java: BDSup2Sub++ (http://forum.doom9.org/showthread.php?p=1613303). It has some bugs, but no more than the Java version.

[Sparktank]

There is also a Windows version written in C++ that doesn't require Java: BDSup2Sub++ (http://forum.doom9.org/showthread.php?p=1613303). It has some bugs, but no more than the Java version.

It looks like he's created a new account and has more updates here:
https://github.com/amichaeltm/BDSup2SubPlusPlus
This branch is 78 commits ahead of amichaelt:master.

https://github.com/amichaeltm/BDSup2SubPlusPlus/releases
1.0.3
513f6c4
amichaeltm released this on May 9, 2018

[LigH]

@Arbie: My mistake, sorry :o didn't notice that the VideoHelp software list leads to the same page for both editions, and read "requires Java runtime" on both...

[ehudik]

יש מדריך גם בעברית לבניית כתוביות?

[hubblec4]

יש מדריך גם בעברית לבניית כתוביות?

No, I don't think so.

Welcome to Doom9. Please use English.

[markfilipak]

BDSup2Sub++ 1.0.3 appears to work well. The problem I'm having is with creation of the SUP file(s) for BDSup2Sub and hence, import into MKVToolNix GUI 41.0.0 64-bit. I seek help/advice here because I don't know of anywhere else I can ask. :-(

The problem is that beginning at 1:13:21 of the video, and thereafter, the subtitles are displayed 10 seconds early. The following is from DVDSubEdit:
Subpic# | StreamID | LBA | V/CID | PTS | Duration | TimeCode
1494 (735 in stream) | 0x20 | 375776 | 1/20 | 395840034 | 1.968s | 01:13:13,633 --> 01:13:15,601
1496 (736 in stream) | 0x20 | 376538 | 1/20 | 396026220 | 3.236s | 01:13:15,699 --> 01:13:18,936
1498 (737 in stream) | 0x20 | 380791 | 2/1 | 17607 | 0.033s | 01:13:15,500 --> 01:13:15,533
1502 (738 in stream) | 0x20 | 380792 | 2/1 | 110700 | 3.703s | 01:13:16,533 --> 01:13:20,236


Bottom Line: I assume Subpic# 1498 is at a layer change that is throwing PTS off. Does anyone know of a SUP subtitle exporter that will handle it?

SubRip 1.57.1:
SubRip will save SUP subtitles, but it has no setting to select only the widescreen (16:9) subtitles. It has a "Enable this box if time restarts in the middle of the DVD" check box, but the extra (letterbox) subtitles are screwing up the export.

DVDSubEdit 1.52:
This will save SUP subtitles, but it has no setting to fix the errors at the layer change. It can retime individual subtitles, and it can retime entire streams, but it apparently can't retime a subtitle and than propagate that delta-time to the remainder of the stream (least not for SUP subtitles).

SRT textual subtitles are out of the question.

Thanks for any help you can provide, and again, I appologize for posting this here. Regards,
Mark.

[Peter_A]

I have had the same problem with ++ and a specific BD (I don't remember which one). However, the Java version doesn't have that problem.

Also, note that the two versions have a CLI option to control the merging of the identical subtitles. It defines the maximum duration between two identical subtitles before they should be considered as two different subtitles. The option is -x <time_in_ms> or --merge-time <time_in_ms> and the default value is 200 ms for both versions. I don't know if that option is available in the GUI. And I don't know why that option doesn't work with BDSup2Sub++ and some specific subtitle streams.

Again, I suggest to keep the two versions of BDSup2Sbb and use the one that works best for each case.

(I have updated the list of bugs of the two versions here (https://forum.doom9.org/showthread.php?p=1828627#post1828627).)

Regarding "duplicate" subtitles, I found a different issue. On at least one title, there were consecutive subtitles, where the second began at the same timestamp as the first ended, but the captions were not the same (the first one was actually blank and very long in duration, so it probably shouldn't have been there in the first place, but it was, and the second one was a real caption). The Java-based BDSup2Sub merged them (dropped the second one and extended the time of the first, which was blank, to cover the time for both subtitles). So, the second subtitle (with a real caption) was lost completely. For the same title, BDSup2Sub++ maintained them both correctly. This may be a rare occurrence, but dropping a subtitle completely is much worse, in my opinion, than having duplicates, especially if the duplicates are there to begin with (i.e., not introduced by the program one is using).

[r0lZ]

Thanks for the interesting bug report. It is strange that both versions try to merge the two subtitles, as their content are obviously different. Can you confirm that their coordinates on screen are different too ? Also, have you tried to change the --merge-time (or -x) option ? Perhaps setting it to 0 is sufficient to solve the problem...

[Peter_A]

Thanks for the interesting bug report. It is strange that both versions try to merge the two subtitles, as their content are obviously different. Can you confirm that their coordinates on screen are different too ? Also, have you tried to change the --merge-time (or -x) option ? Perhaps setting it to 0 is sufficient to solve the problem...

If you're replying to my post, both versions did not try to merge the two subtitles. Only the Java one did. C++ version worked fine. Coordinates are different. I have not tried anything via CLI; my use was via the GUI.

[CatBus]

I think I've found a bug in the Java version of BDSup2Sub (can't confirm C++). It looks like the colors of the subtitles get subtly changed when converting from BDN+XML to BD-SUP, in scenarios where I can't see a reason for this happening. You can magnify this by round-tripping the conversion multiple times.

Example: if the text in a BDN+XML subtitle is #E4E6E0, it gets converted to #E5E6E3 when you turn it into a BD-SUP. If you convert that BD-SUP back into BDN+XML, the color stays #E5E6E3. But then if you convert it back into a BD-SUP again, it then becomes #E5E5E5. Basically, every conversion from BDN+XML to BD-SUP slightly desaturates the colors.

I can't really tell where the conversion error is, but it may be in creating the image palette from the PNG files.

[CatBus]

I think the issue I described above is related to colorspace conversion (RGB->YCbCr), and it may well be that this is a normal amount of color shift due to lack of 100% color overlap between colorspaces. And the roundtrip magnification is why you should always try to reduce your colorspace conversions.

TL;DR: this may not be a bug at all, but just the normal weirdness that comes with colorspace conversion.

[DeafYakuza]

Is there anyway to convert to 2160p for 4K UHD?

I'm not happy with Subtitle Edit because it has issues on ASSA-Subtitles.

[screamingtrees]

Can I request a feature? The ability to use keyboard shortcuts. I'm trying to delete lyrics from a bunch of anime .sups, and so far going through each edit dialog, clicking the bottom left box "exclude" and upper right box "store changes and skip" is proving to be pretty tedious. Open to other suggestions on how to do this (other than converting from PGS). Even an --exclude option for the command line would be better.

[DeafYakuza]

Where can I find a logfile outside BDSup2Sub?


https://abload.de/img/bdsup2sub_logzzip0.jpg (https://abload.de/image.php?img=bdsup2sub_logzzip0.jpg)

[r0lZ]

You can check the warnings in the bottom pane. Also, there is a bdsup2sub directory here C:\Users\<you>\bdsup2sub, but AFAIK, it contains only the .ini

[Gabu]

Hello. I'm trying to shift PGS subtitles with BDSup2Sup. Problem is, I can't never seem to make it just right. And by that I mean, but them right above the letterboxed bars.. but they don't seem to be perfect. Some lines stay just right but others go a bit below. It's strange. If anyone else uses BDSup2Sub, what do you do to shift the subs just right and perfect? I'd appreciate the input and help.