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

[urthling]

Thanks r0lZ! After some tweaking, I was able to get the command to work in the processing batch file I use.

Use a command similar to this:

for %F in ("*.sup") do java -jar c:\BDSup2Sub\BDSup2Sub.jar "%~nF.sup" "output\%~nF.sup" /res:1080 /fps:keep /movin:2.40,24

Type for /? for more info.

[mjuhasz]

r0lZ, thank you for the example!
Let me take the opportunity to briefly explain what happened to the wildcard support.
When I revisited the command line interface implementation I found the existing one untested, non-standard and therefore hard to maintain. I rewrote that part using standard libraries which follow conventions such as short options along with GNU-like long options (e.g. -h,--help), etc. The wildcard support is supposed to be provided by the shell and not the application therefore I removed it. There are excellent shells out with which you can do batch operations easily.
I do realize that using shells is not everyone's thing. However, implementing a powerful and flexible batch processor requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

[r0lZ]

The wildcard support is supposed to be provided by the shell and not the applicationTrue under Linux and most decent operating systems, but not under Windows. Thanks M$!

[urthling]

mjuhasz -

No complaints here as there was a solution that existed to resolve the slight dilemma (due to my ignorance more than anything else). Thanks for your excellent work on the program and thanks r0lZ for the speedy assist.

[DoctorM]

Any progress identifying what can cause the jittery subtitles on some devices?
I assumed it was my interlaced display (an old CRT), but the latest version I tried still produces this on a new HDTV connected to the DVD player via HDMI.

[CatBus]

DoctorM asked me to post my findings regarding compatibility issues here.

First, some have mentioned that BD-SUP files created by BDSup2Sub flash for only one frame when played back in VLC (but they work fine in everything else I've tried). I've found that if you import and re-export the BD-SUP file in BDSupEdit, you end up with a BD-SUP file that works everywhere. I'm not sure what this means as far as where the bug is or how to fix it, but for users interested in maximizing compatibility, this is a simple enough process with no obvious downsides.

Second, the subtitle jitter issue is definitely due to the cropping of DVD subtitles. I've taken subtitles that displayed this jittery behavior and manually expanded them to fit the full frame, and the jitter goes away. If you don't have a hardware player that displays this issue (I have a Pioneer DV-333 that does it--it's old, but was a fairly well-regarded player for its time), you can open the subtitle in DVDSubEdit, and enable the zoom window. If the image in the zoom window wobbles up and down as you adjust the vertical position, that subtitle has the problem.

The jitter is a harder issue to fix, but I think I have something that should work. Right now, BDSup2Sub autocrops as it imports subtitles and that part is fine--it allows some nice features to work and I see no reason to change that. However, when BDSup2Sub exports any DVD subtitle, it should uncrop that subtitle first: i.e. create a transparent canvas the size of the full frame and position the subtitle on that canvas. That way, regardless of what the input format is, cropped or uncropped, and no matter what operation you want to perform, everything will still work, and the output will always have maximum compatibility. The downside to any fix for this issue is that the files for uncropped DVD subs are nearly twice as big as cropped subs. If this is considered a problem, perhaps the auto-uncrop feature could be optional. Either way, I think this problem may be more common than this thread indicates because techies tend to have newer hardware than the general population.

[paradoxical]

Can you post both a flickering SUP and the corrected output of BDSupEdit? That would definitely help pinpoint what the issue might be.

[CatBus]

Just confirmed that the flickering problem is actually not present in the current version--sorry! Was using easySUP, which includes a very old version of BDSup2Sub. The flicker can be fixed by either a current version of BDSup2Sub or BDSupEdit. DVD issues are still present in the current version AFAICT.

[marcusj0015]

On your site you say source code is available, but you just link to the thread (with fifty nine pages!), does anyone know the specific post with the source code?

[paradoxical]

For the last version done by deadbeef go here (http://javaforge.com/svn/bdsup2sub). For mjuhasz's work go here (https://github.com/mjuhasz/BDSup2Sub).

[CatBus]

Suggestion: BDSup2Sub should have an option to use hqx (http://en.wikipedia.org/wiki/Hqx) for subtitle scaling. I've done a test run scaling DVD subtitles to HD resolution using hqx and the results are fantastic, much better than any of the current scaling options in BDSup2Sub. This sort of scaling doesn't work well for photos and such, but it seems ideal for scaling DVD subtitles with their limited resolution and color palette. It may also work decently for HD subtitles, but I don't think there would be much benefit and it may cause a posterization effect because of the wider color palette. The big downside is that it is slow.

Basically, I used hqx to scale my DVD subtitle to 3x its normal resolution, then I used a more general-purpose scaling algorithm (Lanczos) to scale/stretch it back down to the exact right dimensions for HD. I then did a contrast boost to get back the sharpness/whiter whites/blacker blacks. I'm not sure how well it might work with other color combinations than black/white, but I think it would probably work quite well. I believe there is a sample implementation in both Java and C.

[mjuhasz]

Just confirmed that the flickering problem is actually not present in the current version--sorry! Was using easySUP, which includes a very old version of BDSup2Sub. The flicker can be fixed by either a current version of BDSup2Sub or BDSupEdit. DVD issues are still present in the current version AFAICT.

The flickering problem sounds like one of the issues I fixed in v4.0.1:

Fixed: Flashing subtitles - if the end time of the current subtitle picture is beyond the start time of the next one the subtitle was set to zero length.

Fixed: Incorrect (too short) subtitle duration for dvd subtitle frames using subtitle effects

[mjuhasz]

Any progress identifying what can cause the jittery subtitles on some devices?
I assumed it was my interlaced display (an old CRT), but the latest version I tried still produces this on a new HDTV connected to the DVD player via HDMI.

I am trying to collect information about the jittery subtitle issue but this thread is very long so if someone could recap what the actual problem is, how to reproduce it and if there is any workaround for it that would speed things up.

[mjuhasz]

Second, the subtitle jitter issue is definitely due to the cropping of DVD subtitles. I've taken subtitles that displayed this jittery behavior and manually expanded them to fit the full frame, and the jitter goes away. If you don't have a hardware player that displays this issue (I have a Pioneer DV-333 that does it--it's old, but was a fairly well-regarded player for its time), you can open the subtitle in DVDSubEdit, and enable the zoom window. If the image in the zoom window wobbles up and down as you adjust the vertical position, that subtitle has the problem.

The jitter is a harder issue to fix, but I think I have something that should work. Right now, BDSup2Sub autocrops as it imports subtitles and that part is fine--it allows some nice features to work and I see no reason to change that. However, when BDSup2Sub exports any DVD subtitle, it should uncrop that subtitle first: i.e. create a transparent canvas the size of the full frame and position the subtitle on that canvas. That way, regardless of what the input format is, cropped or uncropped, and no matter what operation you want to perform, everything will still work, and the output will always have maximum compatibility. The downside to any fix for this issue is that the files for uncropped DVD subs are nearly twice as big as cropped subs. If this is considered a problem, perhaps the auto-uncrop feature could be optional. Either way, I think this problem may be more common than this thread indicates because techies tend to have newer hardware than the general population.

Very useful, thank you for posting!

[DoctorM]

I have seen the same issue in a Pansonic DVD player, also considered fairly good. It seems to be from the player not output since the jitter will appear on 4x3 CRT TVs via svid cables or as upscaled progressive scan HD via HDMI.
Just opening and saving subtitles with BDSup2Sub without any changes will produce this. It is definitely to do with the autocropping that occurs.

[TheSkiller]

It is definitely to do with the autocropping that occurs.
Yes, that's causing it.
I've been telling this often: for DVD better don't use cropped subtitles.
It's not going to save much bits anyway because the bitmaps (on DVD) are RLE compressed, so any unused space hardly eats any bits.

Anyway, you can prevent BDSup2Sub from cropping the subpics by launching it via commandline (or create a BAT for convenience), adding "/acrop:0".

[DoctorM]

Yes, that's causing it.
I've been telling this often: for DVD better don't use cropped subtitles.
It's not going to save much bits anyway because the bitmaps (on DVD) are RLE compressed, so any unused space hardly eats any bits.

Anyway, you can prevent BDSup2Sub from cropping the subpics by launching it via commandline (or create a BAT for convenience), adding "/acrop:0".

If autocrop can be turned off, why can't the GUI have a selectable option for this?

[CatBus]

Yes, that's causing it.
I've been telling this often: for DVD better don't use cropped subtitles.
It's not going to save much bits anyway because the bitmaps (on DVD) are RLE compressed, so any unused space hardly eats any bits.

Anyway, you can prevent BDSup2Sub from cropping the subpics by launching it via commandline (or create a BAT for convenience), adding "/acrop:0".

The problem is that if you're converting from Blu-ray to DVD format, the subtitles are (typically) already cropped to begin with, so the /acrop flag doesn't do anything helpful in this scenario. For myself, I've used a Perl/ImageMagick scripted solution to uncrop each subtitle before feeding it to BDSup2Sub (with the /acrop flag) to create DVD-format subs from BD-format sources. But if BDSup2Sub did this automatically, that would obviously be better.

[kukushka]

is some rare cases (russian, spanish bd's) i encounter some weird subs that after standart processing within bdsup2sub are losing their transparency (even that within bdsup2sub or supread they still look ok)
here's how it looks like http://gyazo.com/43a96dec65f19f8db5eadfe75c52f70e
and here are a few lines from problematic subs before bdsup2sub, they still can be muxed fine if they won't get processed through bdsup2sub
https://dl.dropboxusercontent.com/u/372935/test.sup
does anybody know any way around this problem? thanks
tried with ++ - same effect

[De_Hollander]

delay is not woring well with a blu-ray sup, I give in 7250 ms delay, the first lines are good but in the middel it's go's wrong.
I working with BDSup2Sub511

[De_Hollander]

problem is solved

[DoctorM]

Where can the most recent version be found? I'm wondering if this should be spun off to a new thread so the first post can be kept up to date.

[Sparktank]

Where can the most recent version be found? I'm wondering if this should be spun off to a new thread so the first post can be kept up to date.

Development has been taken over by paradoxical (who is no longer a member of the forum) and renamed to BDSup2Sub++.

The latest version is over at his new thread: http://forum.doom9.org/showthread.php?t=167051

[mjuhasz]

The original Java version is maintained here:

https://github.com/mjuhasz/BDSup2Sub/wiki

Development has been taken over by paradoxical (who is no longer a member of the forum) and renamed to BDSup2Sub++.

The latest version is over at his new thread: http://forum.doom9.org/showthread.php?t=167051

[DoctorM]

Thanks, I'll take a look.

[mood]

I have problem with this sup file in BDSup2Sub 5.1.1

the BDSup2Sub 5.1.1 only load 2084 lines but the total of lines is 2088.

BDSup2Sub++ 1.0.2 load all the 2088 lines without problem, but BDSup2Sub 5.1.1 misse 4 lines only load 2084.

Here is my sup file: http://www28.zippyshare.com/v/12124972/file.html

[Chetwood]

I'm also only slightly confused on who's doing all the versions of BDSUP2SUB. I was wondering if someone could shed some light on how to identify forced subs on BDs (http://forum.doom9.org/showthread.php?p=1659305#post1659305).

[laserfan]

I'm also only slightly confused on who's doing all the versions...

I am more than slightly confused! :p

[mjuhasz]

BDSup2Sub was originally written by Volker Oth (0xdeadbeef) in 2009. I have been using this tool extensively, did some bugfixes for myself and I wanted to mainline them. In February 2012 I contacted Volker Oth who confirmed that he had stopped development and participation in the Doom9 thread and he did not see see much of a chance of getting back to BDSup2Sub again. With his permission I moved the codebase (https://github.com/mjuhasz/BDSup2Sub) and documentation (https://github.com/mjuhasz/BDSup2Sub/wiki) to GitHub and started maintaining the application. Time permitting I do some development on it but it is mainly in maintenance mode. I do monitor this forum thread and the issue tracker on GitHub.

BDSup2Sub++ is a port of the original BDSup2Sub by 0xdeadbeef to C++ and QT. I am not in contact with its developer and there is no compatibility maintained between the applications. The command line interface is different, there is difference in terms of features and possibly bugs as well.

It is unfortunate that the distinction between the tools are not clear. While they share the same roots they don't have much to do with each other and it would be better to have stronger separation: separate forum threads, VideoHelp (http://www.videohelp.com/tools/BDSup2Sub) page, etc.

[laserfan]

Thanks for the explanation, I appreciate it mjuhasz! I think I might still have 3.9.9 or 4.0.0 but I will try your 5.1.1 now.

BDSup2Sub was originally written by Volker Oth (0xdeadbeef) in 2009. I have been using this tool extensively, did some bugfixes for myself and I wanted to mainline them. In February 2012 I contacted Volker Oth who confirmed that he had stopped development and participation in the Doom9 thread and he did not see see much of a chance of getting back to BDSup2Sub again. With his permission I moved the codebase (https://github.com/mjuhasz/BDSup2Sub) and documentation (https://github.com/mjuhasz/BDSup2Sub/wiki) to GitHub and started maintaining the application. Time permitting I do some development on it but it is mainly in maintenance mode. I do monitor this forum thread and the issue tracker on GitHub.

BDSup2Sub++ is a port of the original BDSup2Sub by 0xdeadbeef to C++ and QT. I am not in contact with its developer and there is no compatibility maintained between the applications. The command line interface is different, there is difference in terms of features and possibly bugs as well.

It is unfortunate that the distinction between the tools are not clear. While they share the same roots they don't have much to do with each other and it would be better to have stronger separation: separate forum threads, VideoHelp (http://www.videohelp.com/tools/BDSup2Sub) page, etc.

[AGKnotUser]

I checked the issue tracker at GitHub and found a report about the same issue I'm having with versions 5.1.0 thru 5.1.2. Avatar forced frames are not working properly. Many are blanked and generate errors. I saw that the report was generated 5 months ago. Just wanted to know if you need a new sample of the .sup files?

[r0lZ]

I have noticed a similar problem with Avatar and other BDs, but with BDSup2Sub++. I guess both versions have the same bug, but I'm not sure.
It seems that indeed, when some subtitles are analysed, the program thinks they have fades or something similar, and it tries to generate several pictures for the same subtitle. However, some pictures are totally black (without transparency), some are missing, and only a few are correct. That bug is obvious when converting to PNG/XML. Since some pictures are referenced in the XML file but missing in the directory, the program cannot reload the stream it has produced.
However, I have noticed that converting the original SUP file to another SUP seems to fix the problem. That second SUP can successfully be converted to PNG/XML. Also, I did a quick test with BDSup2Sub.jar, and I didn't notice that bug.
AGKnotUser, try my trick, and please let us know if it works also with BDSup2Sub.jar, and if the problem you have described is really similar to mine.

[AGKnotUser]

I have noticed a similar problem with Avatar and other BDs, but with BDSup2Sub++. I guess both versions have the same bug, but I'm not sure.

I had the same problem with the ++ version and reported it in that thread. That was about 8 months ago. I went back to the 5.0.0 .jar version.

However, I have noticed that converting the original SUP file to another SUP seems to fix the problem. That second SUP can successfully be converted to PNG/XML. Also, I did a quick test with BDSup2Sub.jar, and I didn't notice that bug.
AGKnotUser, try my trick, and please let us know if it works also with BDSup2Sub.jar, and if the problem you have described is really similar to mine.

Ok, I tried your suggestion with both 5.1.2 .jar and ++ 1.0.2. Neither worked. Will wait and hope.

[r0lZ]

I went back to the 5.0.0 .jar version.Why v5.0.0, and not the latest? Is it the last version that did not have that bug?

[AGKnotUser]

Why v5.0.0, and not the latest? Is it the last version that did not have that bug?

I tried the latest (5.1.2) and it still had the problem. I will try it again to be sure.

Edit: Just retried 5.1.2 and the latest snapshot. Neither fixed the problem.

[Conspicuous57]

WARNING: Language id en(index:1) inactive -> ignored
WARNING: Language id en(index:2) inactive -> ignored
WARNING: Language id fr(index:3) inactive -> ignored
WARNING: Language id es(index:4) inactive -> ignored


For those who want to convert the ignored tracks;

First drag and drop your idx file into MKVMerge GUI. Then tick the track (only one) you want to preserve. Save as .mkv.
Drag and drop the new mkv into MKV Extract GUI. Then extract the track. You will have a new sub-idx pack includes only the track you wish to have.
Then Let the BDSUP do its job.

[bugmen0t]

I cannot get BDSup2Sub to work. Every sup I open only contains odd line numbers. The even lines are completely missing. It only shows (n / 2) or (n / 2 - 1) lines where n is the original line count. Other tools like SupRip are loading the files correctly.
All files were extracted with mkvextract or eac3to (doesn't matter) from a mkv coming out of DVDFab (BluRay-Ripper). Is this a bug?

[DoctorM]

Weird thing... I was trying to convert PGS subs to IDX/SUB format for DLNA streaming (my BD player recognizes SUB but not PGS in MKV files).

Anyway, quick conversion and the subtitles work on my PC, but not on the standalone device.
I tried resizing to 720p and 480, and while they work, they are shrunk and in the wrong position because of the reduced size.

Does the resizing do something BESIDES resize that isn't normally done when converting formats?
I tried using resize to 1080p and BDSup2Sub appears to ignore the setting (although I haven't tested it on the standalone yet).
Edit: Resizing 1080p to 1080p doesn't fix it.
Edit 2: It appears the device doesn't handle 1080 sized subtitles. That's my guess.

[CatBus]

r0lZ, thank you for the example!
Let me take the opportunity to briefly explain what happened to the wildcard support.
When I revisited the command line interface implementation I found the existing one untested, non-standard and therefore hard to maintain. I rewrote that part using standard libraries which follow conventions such as short options along with GNU-like long options (e.g. -h,--help), etc. The wildcard support is supposed to be provided by the shell and not the application therefore I removed it. There are excellent shells out with which you can do batch operations easily.
I do realize that using shells is not everyone's thing. However, implementing a powerful and flexible batch processor requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

FWIW, I had been using 4.01 until very recently for the wildcard support (I do a lot of batch processing). Although I understand that re-implementing any sort of application wildcard processing is likely to get overly-convoluted very fast, there is a way to better support shell wildcard processing without actually adding wildcard processing to the application.

In particular, the bash shell (which is the default shell on most non-Windows systems), does something called wildcard expansion. Any unquoted wildcards are expanded out like below:

test -o "*.xml" *.sup

...is expanded into...

test -o "*.xml" file1.sup file2.sup file3.sup

Right now, if you pass more than one input file to BDSup2Sub, you get a "too many input files" error. But, if you support 1) the single-asterisk for the output file, and 2) an unlimited list of input files when condition (1) is met, then suddenly batch processing becomes much, MUCH easier. At least on non-Windows systems, that is.

Yes, you can also use a more convoluted syntax to get the current version working in bash (and that's what I'm doing right now), but I thought it would be worth pointing this out.

[Ghitulescu]

The last version 5.1.2 seems to load all images off an XML/PNG series, then displays only the first image and grays all the menus (thus unusable). Version 5.1.1 behaves correctly in this respect.

[Ghitulescu]

You can create one as follows:

- load a blu-ray sup file
- export it as SUP/IDX
- load the exported sup/idx file
- change the palette mode to 'Create new'
- check the colors in use under 'Edit DVD Frame Palette'
- edit the palette under 'Edit imported DVD palette'
- export it back as SUP(BD).

I have a BD subtitle that uses colours to identify the speaker (nicer than JOHN: Yes? MR. RAMSBOTTOM: So what?). During the red step these are lost.
What I need is a simple way of removing the black box (http://forum.doom9.org/showthread.php?t=170327) (the background) without affecting the colours. Something like DVDSibEdit could do.

[AllisterFiend]

I tried to do a search through the forum for my question but could not find anything.

Normally I use the windows GUI version and simply go to 'Edit', Then 'Move All Captions', I then select only 'Move Outside Bounds' and leave everything else at it's default, which includes the x and y offsets (10) and the screen ratio/aspect ratio. This has worked for me for a while with no issues.

Recently, I have decided to redo some older subtitles and decided to try and automate this process since it involves many files. I want to use the command line to do this but I have a question about one of the switches needed to move the captions.

The command line option is( -O,--move-out <ratio, offset> ). The offset I would set to '10' which is the normal default in the gui settings. But the ratio is not something I normally have to deal with and I do not see a way to set it as a default or 'keep'.

Most of the files these subtitles come from have 1920x1080 resolutions, but I do have some other sizes mixed in.

Am I reading too much into this, Any suggestions on how to handle this without going into each .sup file (which defeats the purpose of automating this project) and seeing what the program has chosen for the screen ratio.

Hope this question is clear, if not, let me know and I will try to explain in a different way.

Thanks for your time,

AllisterFiend

[Ghitulescu]

http://i58.tinypic.com/15542s2.png

Newer versions dropped the timing infos from the before and after boxes. As indicated with magenta above. This makes the synchronising (verifying it) very difficult, as one has now to go onto EDIT -> EDIT FRAME to actually see whether the timings were correctly set. This is extremely counter-productive, in particular with subtitles that are not obtained from ripping, but self-made.

Secondly, going through SUB/IDX, as suggested above, will remove the colours. Not only, it will incorporate the antialiasing into the block of the letter, making it look fatter.

From the manifest of the original software I gathered that it was supposed to work with bitmap (PGS) subtitles in the BD realm (like DVDSubEdit did it in the DVD realm), but apparently went into the same direction as a million other OCR-software, risking thus to get lost into the anonymity.

[r0lZ]

The IDX/SUB (aka VobSub) format has only 4 colors (to select in a palette of 16 colors), and usually one of them is fully transparent: the background. Therefore, there are only 3 colors to render everything: the font, the outline and the antialiasing. For that reason, you cannot expect to see the same colors than in the "before" box. Furthermore, the palette is fixed (but can be changed manually), so BDSup2Sub has to select the "best" colors from the palette. It has probably not exactly the light blue and light green used in the original SUP and it selects the nearest color, the light grey.

If you want to keep the original colors unchanged, you have to select an output format that can use any color and transparency level: SUP or XML/PNG. Unfortunately, they are not compatible with the vast majority of players or TVs.

I fully agree that the timing info is important and should be visible in the main window.

[Ghitulescu]

The IDX/SUB (aka VobSub) format has only 4 colors (to select in a palette of 16 colors), and usually one of them is fully transparent: the background. Therefore, there are only 3 colors to render everything: the font, the outline and the antialiasing. For that reason, you cannot expect to see the same colors than in the "before" box.

This I know. In fact these subtitles are DVD compatible, so the colours can be kept, just that they are not. To clear the things, the bicolour subtitles originate from SDTV version of the same program, which can directly be muxed into a DVD, that were later on "fixed" into HDTV. If this software can import the subtitles without changing their colours, why it changes them when reverting back to their initial format?
Furthermore, the palette is fixed (but can be changed manually), so BDSup2Sub has to select the "best" colors from the palette. It has probably not exactly the light blue and light green used in the original SUP and it selects the nearest color, the light grey.
The fixed palette is new to me, yet IIRC the palette can be changed, I mean probably the number of entries is fixed, but not their indexes (colours). This is however beside the point, I just wanted to show that there is no way so far to solve the transparent background for BD subtitles.

If you want to keep the original colors unchanged, you have to select an output format that can use any color and transparency level: SUP or XML/PNG. Unfortunately, they are not compatible with the vast majority of players or TVs.
I don't want the original colours, in the sense that I would like to change the background or one of the fixed colours of the original subtitles, while I would like to keep the rest of the colours unchanged.

I don't care about mediaplayers or others, I believe that sticking with the standard should do the trick.

So far, it appears that either I have to OCR the bitmaps, correct the punctuation and spelling, recompile them into PGS via eg tsMuxer or EasySup
or
do the background change of each 4500 bitmaps (I have 12 episodes of ~380 subtitles each) in format XML/PNG, of course blindly, as I have no idea what colour is matched to the transparent background :)

I am old enough to remember the same problems when the DVD had the same age as the BD has today. Well, I don't wanna die before this issue is solved :) .

[DoctorM]

I finally decided to give the "/acrop:0" a try, and I can't get it to work. (Proggy just won't load at all, no error.)

How do you get BDSUP2Sub to launch with a command line switch like that? I'm using v5.1.1.

Is there some way to just add the option to the .ini or create a shortcut with the switch?

Edit: I would like to re-request having this option under the GUI. Maybe just under 'File' add a second Open called 'Open Without Cropping'.
Edit 2: Actually trying to load it PROPERLY under a cmd prompt, I get 'ERROR: Input file not found: C:\acrop:0"
Seriously, any suggestions what I might be doing wrong?

[DoctorM]

Thanks to Catbus I now know that the switch has been quietly changed to "-a 0" in the most recent version.
Testing has also shown me that once you use it, you must use "-a 1" on your next session because these switches are persistent.

I also want to mention that the resize algorithm goes funny if you don't crop. Shrinking test subs both with and without the crop has shown that with cropping will cause anti-aliasing (grey) to be painted outside the outline (black). It appears to be true in varying ways for all resize algorithms.
Be great to get a bug fix on that.

720x576 to 720x480

Cropped (default):
http://110.imagebam.com/download/DzxpvilYLK_0Sa6RunA-ig/33998/339971202/Uncropped.jpg

Uncropped:
http://111.imagebam.com/download/kfXREj2znPZng4YB-1lCKQ/33998/339971200/Cropped.jpg

Edit: The issue appears to be that on resizing, BDSup2Sub does not take into account full transparent colors.
As a result it averages the black outline with the invisible background's color to create anti-aliasing.

A quick and dirty fix until this is corrected:
After loading subtitles, select Edit/Edit Frame Palette.
Find the background (the color with an Alpha of 0), and change the color to the same as the outline (usually black).
Click "Set All", then Ok.

Now the resize will assume it is a black border on black background and the resize filter won't make a mess of it.
Of course if the border isn't the same color throughout, this really doesn't help.

[r0lZ]

I have noticed a very strange problem when some subtitles are converted from XML/PNG to SUP. The transparencies are correct if the input XML or the output SUP file are loaded in the GUI, but the transparencies are wrong when the SUP file is played with any software player. (I use mainly PotPlayer, but other players have the same behaviour.)

In the original PNGs, the background is transparent, as it should, and the outline is opaque, also as it should. But when the output SUP file is played, it's the opposite: the background is opaque, and the outline is transparent. (The white body of the characters is displayed normally.)

That problem occurs only with some streams, so I suspect something odd in the XML/PNG files, but since the PNGs are correctly displayed in all image players or editors I have tested, there is obviously a bug in BDSup2Sub. (BDSup2Sub++ has the same problem.)

I have tried to change the resize filter and the output palette mode, without success. In the other hand, converting to VobSub works fine. Also, converting to a new XML/PNG stream and then from that new stream to SUP works fine too. That's really strange because the original XML/PNG has also been created with BDSup2Sub.jar.

Here is a sample (http://download.videohelp.com/r0lZ/tmp/test_subs.7z). (The archive includes the source XML/PNG with 5 subtitles only, appearing during the first 30 seconds of the movie and a SUP file converted with BDSup2Sub.jar v5.1.2, to be played with any 1080p movie in any software player.)

[Lyris]

I'm confused by this tool. It says in the documentation that it can export BDN XML files, but after I load my .SUP file, I can't see this option anywhere. Going to File > Save/Export only saves as a .SUP file. What am I missing?

[r0lZ]

On top of the main window, change the Output Format to XML/PNG, then export your subtitles (in an empty directory!)