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


Pages : 1 [2]

SassBot
28th June 2012, 21:31
Yes, it does. Though, don't get too tied to the current options as things will change somewhat. The options are going to be changed to be more like Unix-style options and and there will be no more need to double quote escape anymore like the old Java version required if you used wildcards for input or output. The general form will be bdsup2sub++ [options] -o outfile infile. I'm also going to be splitting any options that currently take two parameters to separate options that take one parameter a piece as this will help simplify parameter checking. I should have more solid info on the final decision either later tonight or tomorrow.

Selur
29th June 2012, 06:41
I should have more solid info on the final decision either later tonight or tomorrow.
Nice :) Thanks for the info!

Cu Selur

Ps.: Are you planning to also compile Linux&Mac versions of 'bdsup2sub++' ?

SassBot
29th June 2012, 15:15
I have no Mac so I would be unable to compile for OS X at this time but if someone would like to do so that would be a great help. :) I am working to get it packaged and included into Debian Testing, though. I am waiting to finish up the new CLI options before I submit that for approval. Once I get that done, I can look at other distros. The problem is that with my using GCC 4.7.x it makes it a bit more difficult to support something other than pretty recent distros at least using online automated build systems. I looked into using OpenSUSE Build but I couldn't get it to work for any of the Debian or Ubuntu versions due to the GCC version dependency. I might be able to get it to compile a package for Fedora 17 though.

SassBot
29th June 2012, 15:25
So here is the output of doing "--help". Let me know what you think about the options and please offer any suggestions on name changes that would be better.


Syntax:
bdsup2sub++ [options] -o outfile infile

Options:
-h, --help List options
--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 inside screen ratio <x>.
--move-in-offset x Set +/- offset to move captions by.
--move-out-ratio x Move captions outside screen ratio <x>.
--move-out-offset x Set +/- offset to move captions by.
--move-x x Move captions horizontally. May be left,right,center.
--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.
--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.
--fix-invisible Fix zero alpha frame palette.
--verbatim Switch on verbatim console output mode.

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 luma low/med threshold 0..255.
--med-hi-thr x Set luma 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'
Press <RETURN> to close this window...

To note, for r0lz's feature request the move-x option would also accept a value of "origin" to support moving from the original x position. I just didn't include it in the help text yet.

r0lZ
29th June 2012, 15:44
Great!
so, to move all subpics to the left by 10 pixels, I should use "--move-x -10". Right?

BTW, it may be a good thing to add an option to ignore the INI file. Currently, all arguments must be specified in the command line if you need to overwrite the user's defaults. It's not easy. An option to use the hardcoded defaults would be nice.

SassBot
29th June 2012, 15:47
It would be "--move-x origin --move-x-offset -10". Ok, I can add an option to ignore that. Something like "--ignore-settings"?

r0lZ
29th June 2012, 15:50
Ah, OK!
Yes, --ignore-settings is fine.
Thanks!

SassBot
29th June 2012, 15:53
Just remember you pass the same values as before it's just for ones that would normally be comma delimited I've split into two separate options to make it easier to validate the values since I don't need to do string splitting, etc. So this affects the fps, movin, movout, movex and scale options from the original version.

r0lZ
29th June 2012, 16:01
I've seen that. It's easier for me too! :-)

SassBot
29th June 2012, 17:28
So whilst working on these commandline options, I've noticed that both through the GUI and through the CLI that the program applies a frame rate conversion to BD SUP or XML/PNG if you don't specify /fps:keep or set the target frame rate in the conversion settings dialog. Does this behavior make sense to anyone? It makes more sense to me that you would never apply any frame rate conversion unless specifically told to do so, yet it does the opposite for these formats.

r0lZ
29th June 2012, 17:31
I agree. /fps:keep should always be the default.
Perhaps you have a setting in your INI that forces the conversion?

SassBot
29th June 2012, 17:47
No, it's just weird because if I run a file through without setting /fps:keep I get a different result from setting it. Same with the GUI. If I don't make sure the target fps matches the source FPS and check the convert FPS check box the subtitle timings change.

r0lZ
29th June 2012, 17:58
IMO, it's a bug.

SassBot
29th June 2012, 18:01
Yeah, whenever I don't specify /fps:keep the program always outputs to the console: "Target frame rate set to 25fps". So I'm definitely going to fix that.

I'm also thinking of switching the "ignore-settings" option to being "load-settings" so that you have to specifically tell it you want to use the INI settings rather than the other way around when using the CLI. Unless someone has a good reason to object.

r0lZ
29th June 2012, 18:13
Unless someone has a good reason to object.Personally, no, as long as it is still loaded by default when the GUI is opened.
The problem is that the GUI is opened also when a single file argument is given. IMO, it should load the user settings in that case.

SassBot
29th June 2012, 18:14
Okay, I at least now see why it's doing this via the CLI now. The help text doesn't make this very clear but apparently as is you pretty much have to specify the resolution and target fps because otherwise it's going to always assume PAL resolution and thus set your target frame rate to 25fps. Now I still don't know why the GUI is shifting timing, though, but that can be fixed.

Personally, no, as long as it is still loaded by default when the GUI is opened.
The problem is that the GUI is opened also when a single file argument is given. IMO, it should load the user settings in that case.

Yes, the code will be such that the settings file is only read in if the GUI is opened which would also cover the case you mention too.

SassBot
29th June 2012, 22:02
Ok, this should hopefully be the latest beta version until I push the 1.0.0 release. The CLI options parsing is finally done. Please bang on it to see if this switch over introduced any bugs that I might have missed. It also now supports the "move-x origin" option you wanted, r0lz.

As always, the download is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

Below is the latest version of the help output with all the options.


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-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.
--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.
--fix-invisible Fix zero alpha frame palette.
--verbatim Switch on verbatim console output mode.

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'
Press <RETURN> to close this window...

SassBot
29th June 2012, 22:12
Download has been updated. I had a logic bug on whether not to convert resolution which was causing the resolution parameter to be ignored.

mood
30th June 2012, 00:38
Hi, SassBot...

can you fix the GUI too??, not only the CLI??

Can you make a change log for new versions or fix.

In gui, menu item exit not work.

The last version number is a same was a few days b4, please make a change log.

Thanks for your work in this great tool. :)

SassBot
30th June 2012, 02:12
Hi, SassBot...

can you fix the GUI too??, not only the CLI??

Such as?


Can you make a change log for new versions or fix.


I can when I push out the full release.


In gui, menu item exit not work.

Weird. I must have overlooked that and no one else noticed. :o

The last version number is a same was a few days b4, please make a change log.

No, the version I released today is bumped to beta 5. The one from a couple of days ago was beta 4. I only really bump the number when I feel like it warrants it since I'm rapidly fixing and changing things for the real release and bumping the number for a bunch of quick fixes is too tedious.

I'll be doing a more thorough changelog once it hits release.

Thanks for your work in this great tool. :)

You're welcome.

SassBot
30th June 2012, 02:21
Download refreshed to fix the bug mood reported. As usual get it here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

mood
30th June 2012, 03:42
thanks SassBot...

when i save to idx/sub one opened subtitle created by AVIAddXSub 9.11...

bdsup2sub++ crash after save.

Thanks again for your great work.

SassBot
30th June 2012, 04:37
Post the file and I'll look into it.

mood
30th June 2012, 05:03
Oki here is it:http://www.mediafire.com/?ji2ycxe11roscrs

SassBot
30th June 2012, 05:08
I loaded that file and saved it to all 4 formats and no crash. Was there something in particular you did?

mood
30th June 2012, 05:26
I loaded that file and saved it to all 4 formats and no crash. Was there something in particular you did?

i change the color palette, because it turn subtitles Green.

but save always in green.

In palette option i use keep, and I move first line to top.


http://img577.imageshack.us/img577/2313/capturariv.png

http://img440.imageshack.us/img440/8214/capturar2b.png

The subtitle must be white with black border, not green.

sorry for english ;)

SassBot
30th June 2012, 06:11
So I finally got it to reproduce. Seems that file triggered some race condition that caused the processing thread to try to destroy itself while still running. With the changes I made, I have not been able to reproduce the crash anymore. New version can be downloaded here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z). Please let me know if you still see any problems still or find others. :)

mood
30th June 2012, 06:28
So I finally got it to reproduce. Seems that file triggered some race condition that caused the processing thread to try to destroy itself while still running. With the changes I made, I have not been able to reproduce the crash anymore. New version can be downloaded here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z). Please let me know if you still see any problems still or find others. :)

Oki thanks...

Not crash... but bug in exit menu item is back and turn the color of subtitle green like i show in post above.

but no problem i will wait for stable version.

thanks...

r0lZ
30th June 2012, 10:13
I don't use the GUI much, but IMO, it needs an improvement. The dropdown button to select the subpic number is not handy. I would prefer something like a spinbox, or if the current dropdown is maintained, two "-" and "+" buttons to select the previous or next subpic will be handy.
The original doc tells something about hotkeys, but they have never worked for me. I suggest PageUp and PageDown to select the next and previous subpic.
(Currently, the only way I've found to quickly go to the prev or next sub is to select a subpic with the mouse, then use the up and down keys. But that doesn't work when another part of the GUI gets the focus.)

SassBot
30th June 2012, 15:27
Oki thanks...

Not crash... but bug in exit menu item is back

What bug? I hit the exit menu item and it closes.

and turn the color of subtitle green like i show in post above.

I'm not seeing green subtitles. I'm seeing light red subtitles. I need the exact same file you use to get green subs. And it doesn't necessarily mean it's a bug. When you convert to SUB/IDX it has to map the pixel values to the DVD Palette which means you might get what you don't expect, but it's not necessarily a bug.

SassBot
30th June 2012, 16:18
I don't use the GUI much, but IMO, it needs an improvement. The dropdown button to select the subpic number is not handy. I would prefer something like a spinbox, or if the current dropdown is maintained, two "-" and "+" buttons to select the previous or next subpic will be handy.
The original doc tells something about hotkeys, but they have never worked for me. I suggest PageUp and PageDown to select the next and previous subpic.
(Currently, the only way I've found to quickly go to the prev or next sub is to select a subpic with the mouse, then use the up and down keys. But that doesn't work when another part of the GUI gets the focus.)

Sounds good to me.

Chetwood
1st July 2012, 06:46
I'd also see like to see improvements to the GUI, my suggestions:


Please preselect the OK button in the conversion Options window so when opening a sub pressing SPACE will skip this window pretty fast. ALT-O is very hard to press with one hand and since both Store and OK have the same accelerator it won't work anyway.
add an accelerator like CTRL-S to open the subpic dropdown box or better yet, have it selected automatically so we only need to press CURSOR DOWN to browse them
additionally let SPACE go one sub down.

Thx.

Superb
1st July 2012, 18:30
There's a quick flashing command prompt before the GUI opens. Is this on purpose? Any chance to get rid of it?
Also, could you open a separate forum thread for your port? :) (it's hard to follow new builds)

SassBot
1st July 2012, 23:09
There's a quick flashing command prompt before the GUI opens. Is this on purpose? Any chance to get rid of it?
Also, could you open a separate forum thread for your port? :) (it's hard to follow new builds)

Yes, that is completely normal. It's what happens when you have a Qt GUI app that also supports console output. There's nothing I can do to change it.

r0lZ
1st July 2012, 23:31
I've found a new GUI bug in b5. The program remembers the window position and size from session to session, but now, each time the program is launched, its window becomes bigger. (The position doesn't change and is correct.)

Selur
2nd July 2012, 09:38
I have no Mac so I would be unable to compile for OS X at this time but if someone would like to do so that would be a great help.
Tried to compile it with Qt Creator -> no-go due to all the initializations that you do in the header files,... (I guess a lot of your constants should be part of namespaces and not classes,... code is not ISO C++ compatible,.. ;))

r0lZ
2nd July 2012, 11:06
SassBot, I have a few questions about the CLI.

When a DVD Sup is converted (and the IFO loaded), AND the --palette-file argument is provided, can you confirm that the palette takes precedence and that it is not retrieved from the IFO?
Same question for the --resolution, --fps-source and --language arguments.

When the output file argument is not provided, but other arguments are provided (with or without the input file), the INI file is loaded (unless the arg to not load it is present). Again, can you confirm that all arguments passed via the command line overwrite the default values coming from the IFO or the INI?

In other word, is this always the parsing order:
1. hardcoded defaults
2. INI file
3. IFO file
4. CLI arguments

I have also a problem with --fix-invisible (and other boolean flags).
I want to disable that feature. The java syntax is /fixinv- but with your syntax, it is only possible to enable the feature, not to disable it. So, if it has been set in the INI, there is no way to change it.
I know that I could disable the INI, but it's not always a good thing. It may be preferable to keep some user settings.
So, IMO, your current syntax is not sufficient. You should add also the arguments to disable each feature, such as --no-fix-invisible, or by adding a boolean flag after each on/off argument, like "--fix-invisible 0". (I prefer the second method, easier to handle by an external GUI.)

Or, perhaps, I've missed something and it is possible to specify --fix-invisible+ or --fix-invisible-, like in the java version? I guess that syntax is not your cup of tea!

SassBot
2nd July 2012, 12:02
Tried to compile it with Qt Creator -> no-go due to all the initializations that you do in the header files,... (I guess a lot of your constants should be part of namespaces and not classes,... code is not ISO C++ compatible,.. ;))

You need GCC 4.7.x as I said in the post you quoted from as it's the version where the C++11 feature for non-static member initialization is supported. And my constants are using enum classes because then they are scoped and I can reuse names like the Java version. As I said earlier when I first started, I'm using lots of C++11 features to reduce code bloat to get around the lack of these features in C++98 and I don't want to use non-standard compiler extensions.

SassBot
2nd July 2012, 12:11
SassBot, I have a few questions about the CLI.

When a DVD Sup is converted (and the IFO loaded), AND the --palette-file argument is provided, can you confirm that the palette takes precedence and that it is not retrieved from the IFO?
Same question for the --resolution, --fps-source and --language arguments.

When the output file argument is not provided, but other arguments are provided (with or without the input file), the INI file is loaded (unless the arg to not load it is present). Again, can you confirm that all arguments passed via the command line overwrite the default values coming from the IFO or the INI?

Yes, they do. If they don't there's a bug.

In other word, is this always the parsing order:
1. hardcoded defaults
2. INI file
3. IFO file
4. CLI arguments

Something like that.


I have also a problem with --fix-invisible (and other boolean flags).
I want to disable that feature. The java syntax is /fixinv- but with your syntax, it is only possible to enable the feature, not to disable it. So, if it has been set in the INI, there is no way to change it.
I know that I could disable the INI, but it's not always a good thing. It may be preferable to keep some user settings.
So, IMO, your current syntax is not sufficient. You should add also the arguments to disable each feature, such as --no-fix-invisible, or by adding a boolean flag after each on/off argument, like "--fix-invisible 0". (I prefer the second method, easier to handle by an external GUI.)

Or, perhaps, I've missed something and it is possible to specify --fix-invisible+ or --fix-invisible-, like in the java version? I guess that syntax is not your cup of tea!

No need for another switch or a value. I'll just make it so it turns off the fix feature if the switch isn't specified. I forgot to do so. Any of the boolean switches will default false (and override your INI) unless you specify them. But if you do want a way to explicitly turn it off, I think the -no-fix-invisible is better as that's how things like GCC do it rather than passing a value to the switch.

r0lZ
2nd July 2012, 12:37
No need for another switch or a value. I'll just make it so it turns off the fix feature if the switch isn't specified.
But it's a problem if the INI is loaded. It is not possible to turn off a setting that has been set in the INI. Since the INI is loaded anyway when the GUI is opened even without specifying --load-settings, it is impossible to turn off a boolean flag in that case (and if --load-settings is provided). IMO, it's confusing, and limited. So, yes, I think that args to turn off the boolean options is important. (The GCC syntax is OK for me.)

SassBot
2nd July 2012, 12:41
But it's a problem if the INI is loaded. It is not possible to turn off a setting that has been set in the INI. Since the INI is loaded anyway when the GUI is opened even without specifying --load-settings, it is impossible to turn off a boolean flag in that case (and if --load-settings is provided). IMO, it's confusing, and limited. So, yes, I think that args to turn off the boolean options is important. (The GCC syntax is OK for me.)

But if you are using the GUI why would you be specifying the settings via the CLI? That seems like a weird use case to me.

Also, I just realized that I somehow lost the code I added for switching between languages in multiple language IDX/SUB files. I'll be adding that back in before the 1.0.0 final.

SassBot
2nd July 2012, 12:51
So to add, I'm adding explicit flags to disable those options, so that if you want to read in the INI file as well you can disable select options.

r0lZ
2nd July 2012, 13:09
But if you are using the GUI why would you be specifying the settings via the CLI? That seems like a weird use case to me.
Well, that can be useful. For example, when converting a DVD SUP, the defaults for --alpha-thr and --minimum-time (especially --minimum-time) are not very good, as many DVDs have hidden (fully transparent) subs, usually with a very short duration. Forcing a minimum duration of 500 ms (the default) may have an impact on the following subtitles. Also, --fix-invisible must be turned off, as otherwise garbage appears.

It would be nice to be able to create a shortcut to BDSup2Sub++ with the option --load-settings --no-fix-invisible --minimum-time 0 --alpha-thr 40, to open the GUI in "DVD mode", without changing the other user settings. It's currently not possible, due to the missing --no-fix-invisible.

Also, currently, my GUI converts normally the subs automatically (without loading the settings file), but it has an option to load the SUP in the GUI, and let the user modify what he wants before saving the converted sub manually. In that case, I would like to load the INI for some defaults, but force the "DVD mode". (Of course, the user can change the forced options, but it's his responsibility.)

BTW, it's certainly why the java version has that possibility.

[EDIT]
So to add, I'm adding explicit flags to disable those options, so that if you want to read in the INI file as well you can disable select options.
:)

r0lZ
2nd July 2012, 13:15
I've found another bug. When trying to load a palette with the --palette-file arg, the program outputs always the same error message: ERROR: Not a valid palette file

The palette I was trying to load has been generated by my GUI, and the java version loads it without problem.
I've tried to export a palette with the ++ version, and noticed that the file format is different. Now, it has a "[General]" category, not present in the java versions.
So, I did the test again, this time with a file of the correct format, but the same error happens. Not sure why.

BTW, I agree that the new format is better, as it's a real INI, but the new format will not be compatible with many other programs (including PgcEdit). That might be a problem.

SassBot
2nd July 2012, 13:19
Can you upload the file? It should read the INI file just fine as I tested loading palette ini's exported from the Java program to verify it worked via the GUI. There's a bug in the CLI code probably.

The reason the output looks different is that I'm using Qt's INI writing class which uses the Win32 APIs whereas the Java used custom code to write it and that's why it looks different.

SassBot
2nd July 2012, 13:25
Ok, it's just a flaw in checking that it was a valid palette INI file via the CLI. Fixing now.

SassBot
2nd July 2012, 13:27
BTW, I agree that the new format is better, as it's a real INI, but the new format will not be compatible with many other programs (including PgcEdit). That might be a problem.

If it's due to the color ordering I can swap them around and get rid of the general heading. I didn't think about that.

r0lZ
2nd July 2012, 13:32
Indeed, the palettes can be loaded in ++ with the GUI. It's certainly a CLI bug.

bdsup2sub++.exe --language fr --palette-file "E:\TEMP\PGC2MKV TEMP\Subtitles_palette.ini" --alpha-thr 40 --minimum-time 0 -o "E:\TEMP\PGC2MKV TEMP\Subpictures_22.sub" "E:\TEMP\PGC2MKV TEMP\Subpictures_22.idx"

Note the space in the path. Could it be the reason?

Given the tests I've made with the java version, it requires a comment as the first line, beginning with "#COL".
Without that line, I have never been able to load a palette (from CLI or GUI).
But this palette can be loaded in both versions (GUI only for ++):

#COL - VTST 2, 1 TTN 1 (2:51) Title 3
# Exported by PgcEdit's PGC2MKV plugin
[General]
Color_0=0, 0, 0
Color_1=0, 0, 0
Color_2=0, 0, 0
Color_3=0, 0, 0
Color_4=0, 0, 0
Color_5=0, 0, 0
Color_6=0, 0, 0
Color_7=0, 0, 0
Color_8=0, 0, 0
Color_9=0, 0, 0
Color_10=0, 0, 0
Color_11=0, 0, 0
Color_12=0, 0, 0
Color_13=204, 204, 204
Color_14=0, 0, 0
Color_15=0, 0, 0


(The lines begin with two TABs, for historical reasons, but they are not necessary.)

SassBot
2nd July 2012, 13:38
Yeah, I'm rewriting the code to output the palette so it's like the Java one. The program INI file will still use the Qt class so there will probably be incompatibilities there, but I don't really want to have to use a bunch of custom code for that.

r0lZ
2nd July 2012, 13:41
Oh, I think the CLI palette bug could be caused by the single \ characters. Is it necessary to convert them to / or \\ ?

r0lZ
2nd July 2012, 13:42
Yeah, I'm rewriting the code to output the palette so it's like the Java one. The program INI file will still use the Qt class so there will probably be incompatibilities there, but I don't really want to have to use a bunch of custom code for that.
As long as the "#COL" comment is present in the first line, it's perfect!
Pity: it is probably not easy to add a comment in the INI with the Qt class.

SassBot
2nd July 2012, 13:46
Oh, I think the CLI palette bug could be caused by the single \ characters. Is it necessary to convert them to / or \\ ?

What single slash? The bug was the way I was testing whether the file had the Color lines in it to make sure it was a palette file.

r0lZ
2nd July 2012, 13:54
OK. But why dit it fail from the CLI but not in the GUI? Is it not the same code?

SassBot
2nd July 2012, 14:13
No, it's a different code path.

SassBot
2nd July 2012, 14:37
Ok, well I have to go to work now. Palette writing code matches what Java version does when you export the DVD Palette and the detection code for specifying an input palette INI is fixed. I got the complementary "--no" CLI options in for the boolean options that can be read from the INI file (export palette, fix invisible frames, and verbatim logging) so they can be overridden if you want to also read in your settings INI. Also, in the GUI I've added default settings to the buttons in popup the dialogs so you can use the enter key to hit the okay button in the conversion dialog, to activate the move all in the move dialog, etc.

Changes that are set to be made are so that if you pass a non-wildcard input file but specify no output that it will load the GUI and set the options you passed in. Also there were two suggestions about switching between subtitles from the GUI by either using spacebar or pgup/pgdown. The keyboard shortcut will be implemented as well. Since this will take more time than I can do right now it'll have to wait until either tonight or tomorrow.

New version to download is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

r0lZ
2nd July 2012, 15:04
Thanks! I'll test it tonight...

r0lZ
2nd July 2012, 15:25
Just did a test. There are still some problems:

bdsup2sub++.exe --language fr --palette-file Subtitles_palette.ini --alpha-thr 40 --minimum-time 0 -o Subpictures_22.sub Subpictures_22.IFO
OPTION: Set alpha threshold to 40
OPTION: Set language to French (fr)
OPTION: Loaded palette from Subtitles_palette.ini
OPTION: Set delay to 0
QxtCommandOptions: option "no-verbatim" not found
QxtCommandOptions: option "no-fix-invisible" not found

Converting SUB/IDX

There was 1 warning

Conversion of 1 file(s) finished

What warning?
The original java version issues this warning:

# 1
WARNING: Invisible caption due to zero alpha (not fixed due to user setting).

And a lot of other messages. (Most of them are not necessary, but the ++ version displays almost nothing.)

The QxtCommandOptions messages are printed to stderr, so my GUI assumes that an error occurred, although it's not really the case.
Anyway, these messages are abnormal.

SassBot
2nd July 2012, 16:17
Hmm, I don't know why you get those messages since those options were added to the QxtCommandOptions class. Also, passing options to a program that it doesn't recognize seems to be an error to me so I don't see the problem with it writing that to stderr. Although it should have quit had it gotten unrecognized options so I'll see why it didn't.

And I don't know why the messages don't print out. I'll double check to make sure the signals/slots are all connected properly and being emitted as they should.

Edit to add: I figured out the problem with the new options. I had accidently left out a , when I added to "no-verbatim" switch to the method that takes the option name and description. This caused it to be unrecognized. Though when I tested it it immediately showed the error, displayed the options list and then exited. Why it didn't exit for you I don't get.

Also the console logging issue is fixed too. The way I was checking to see whether we were logging for the GUI or console had an issue. I'll be able to push out a version here in a few minutes.

SassBot
2nd July 2012, 16:51
New version here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z) with the aforementioned fixes.

So I was just testing the keyboard shortcut to rapidly change between subtitle numbers in the GUI and pgup/pgdown will be problematic due to the image windows that also accept those key presses. Spacebar would be a good key since it won't be used by those. Unless someone has a better key suggestion.

SassBot
2nd July 2012, 17:55
Ok, so space doesn't really work since it doesn't cover going backwards in the list of items. Maybe ctrl-pageup and ctrl-pagedown?

r0lZ
2nd July 2012, 18:43
Thanks for the fixes.

Also, passing options to a program that it doesn't recognize seems to be an error to me so I don't see the problem with it writing that to stderr.
The problem was that I haven't typed them, as you know now. With the previous version, it was impossible to not have the two messages. Anyway, it's fixed now.

[...] Though when I tested it it immediately showed the error, displayed the options list and then exited. Why it didn't exit for you I don't get.
I don't know. Have you typed similar arguments than mine?
Usually, when there are errors in the command line, it displays the list of options and exits for me too.

Ok, so space doesn't really work since it doesn't cover going backwards in the list of items. Maybe ctrl-pageup and ctrl-pagedown?
Is Up/Down or Left/Right available? Or [ and ], or even p and n, - and +, or any pair of keys easy to remember? I would prefer unqualified keys.
If it's not possible, I vote for Ctrl-PgUp/Down, and, in addition, Space to go forward.

SassBot
2nd July 2012, 18:46
Up/Down and left/right don't work well because of the same reason as plain pageup/pagedown because if those image areas have focus they will grab the key events. I was thinking ctrl-pgup/pgdown because most browsers use that for tab switching so I thought it wouldn't be that awkward to use here, too and would be a familiar set of shortcuts. But before I make a final choice more feedback would be appreciated.

r0lZ
2nd July 2012, 18:58
Seems the last version is still the old one. The QxtCommandOptions errors are still there. (Maybe a server issue. I have very often site down problems when downloading the archives.)

SassBot
2nd July 2012, 19:04
No, it's a new executable. It works fine here. Clear your cache and redownload.

r0lZ
2nd July 2012, 19:16
No, after having cleared the cache, it's still b7, with exactly the same file size, and the same bugs.

SassBot
2nd July 2012, 19:18
No, after having cleared the cache, it's still b7, with exactly the same file size, and the same bugs.

Then you have some issue with Github. Because I redownloaded it twice and it's beta 8 with the fixes.

SassBot
2nd July 2012, 19:19
So last new version for today at beta 9. This has another CLI fix for a bug I uncovered, has support for switching between sub languages again and for right now uses Ctrl-PageUp/PageDown to switch between subpictures in GUI. Those key combos aren't set in stone but they can at least be tried out.

Download as always is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

SassBot
2nd July 2012, 19:23
Ok, so github seems to be slow to refresh the download link if it has the same name. So some people may see outdated file versions so just give it a little bit of time.

r0lZ
2nd July 2012, 19:25
OK, finally got b9, and for the first time, I was able to use it with my GUI. It has created the SUB and IDX files. I still have to verify the content of the files. (Currently, I've tested almost only the CLI.)

Anyway, good work! :)

SassBot
2nd July 2012, 19:26
Yeah, I don't know what is going on with Github today. It's being wonky with refreshing the file apparently, but glad you finally got it.

r0lZ
2nd July 2012, 19:38
I have always had many problems when downloading your files. Server down, timeouts, 404 not found... But when I insist, I have always been able to finally download it (except b8).

And BTW, I have also regularly a similar problem with the doom9 forum: server down. I have to click 4 or 5 times on the Retry button, and finally the page loads. The problem is too short to be a real server problem, so I suspect a problem with my internet connection or my ISP. I have never experienced that problems before, and I can visit most sites without this kind of issue. They appeared one month ago or so, for D9 only. Someone has had similar problems here?

r0lZ
2nd July 2012, 19:46
Oops, I haven't noticed that there is still a problem in b9:

QxtCommandOptions: option "no-fix-invisible" not found

The no-verbatim problem is fixed, but not this one. (I haven't noticed it immediately because I've implemented a workaround to ignore some errors printed to stdout.)

SassBot
2nd July 2012, 19:51
Oops, that was due to a typo. Thanks for spotting that. I accidentally typed the option as "no-fix-invisibile". :o Refreshed with the fix as beta 10 here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

r0lZ
2nd July 2012, 20:06
I got b7 from your last link! Really strange!

r0lZ
2nd July 2012, 20:49
Sorry, really, it's b7 on github. Even after having cleared the cache, reset my router and rebooted (just to be sure), I can't get b10.
Strangely, b9 was the last version I've been able to download, but now, it took me back to b7! There is really something odd. A mismatch with the internet time machine? ;)

SassBot
2nd July 2012, 20:57
No, there must be going on with Github's cloud sharing. I double and tripled checked the archive I uploaded and even reuploaded it again just to make sure. I also downloaded the file on my phone and transferred it over to my computer and it was beta 10.

r0lZ
2nd July 2012, 20:58
OK. Anyway, I'll not work tonight. I'll retry tomorrow...

SassBot
2nd July 2012, 21:10
Well in the mean time you can always misspell the option as "no-fix-invisibile" until Github serves you the proper version.

Edit to add: I've renamed the exe and the archive and hopefully that will be enough to get Github to refresh it for you. Download link is now here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100b10.7z).

r0lZ
2nd July 2012, 23:17
OK, got it. Tx!

r0lZ
3rd July 2012, 00:01
No problem with the CLI any more. :) (I still have to check the new "no" options, but without the INI and the switches, the command works fine, without messages to stdout.)

So, I did a complete test and watched it on my TV. Bad news: The colours of the subtitles are wrong. :( The original subs are light grey with black outline, and the subs generated with the ++ version are blue. (Not sure the outline is also blue or is fully transparent, but I can't see it.)

The original jar version has also a bug. The text colour is correct (grey), but the outline is also missing, or is also grey.

No problem with SubtitleCreator.

I'll have a look at the IDX files tomorrow. Time to go to bed!

SassBot
3rd July 2012, 00:10
Can you post the input file? I can look into it. I've also got it working where you can specify options for when you want to also load the GUI (by either not specifying neither a source nor a output file or a source file with no output).

mood
3rd July 2012, 01:26
No problem with the CLI any more. :) (I still have to check the new "no" options, but without the INI and the switches, the command works fine, without messages to stdout.)

So, I did a complete test and watched it on my TV. Bad news: The colours of the subtitles are wrong. :( The original subs are light grey with black outline, and the subs generated with the ++ version are blue. (Not sure the outline is also blue or is fully transparent, but I can't see it.)

The original jar version has also a bug. The text colour is correct (grey), but the outline is also missing, or is also grey.

No problem with SubtitleCreator.

I'll have a look at the IDX files tomorrow. Time to go to bed!

I had said in my last post the colors of subtitles are green or blue. ;)

So the problem is not my configuration ;)

SassBot
3rd July 2012, 01:42
I had said in my last post the colors of subtitles are green or blue. ;)

So the problem is not my configuratin ;)

Yes, but the IDX/SUB files you gave me decoded as red hence why I asked for a file that shows the issue.

mood
3rd July 2012, 02:20
Yes, but the IDX/SUB files you gave me decoded as red hence why I asked for a file that shows the issue.

Yes is red, but in mpc-hc or in my hdtv show in green or blue.

like in image i post before.

r0lZ
3rd July 2012, 10:32
Can you post the input file? I can look into it.
Here it is: http://download.videohelp.com/r0lZ/tmp/Subtitles_test.7z

The archive contains the original SUP, the IFO and the Subtitles_palette.ini I've used to generate the SUB/IDX files.
The IDX files generated by SubtitleCreator and the java and c++ versions of BDSub2Sub are also included.
The two log files are stripped down versions of the output of the BDSup2Sub programs.

The command lines were:

SubtitleCreator.exe Subpictures_22.sup -vfr -iSubpictures_22.IFO

bdsup2sub++.exe --language fr --palette-file Subtitles_palette.ini --alpha-thr 40 --minimum-time 0 -o Subpictures_22.sub Subpictures_22.IFO

java -Xmx256m -jar BDSup2Sub.jar /forced- /res:keep /fps:keep /lang:fr /pal:Subtitles_palette.ini /dly:0 /atr:40 ^
/scale:1.0,1.0 /tmin:0 /swap- /forceall- /exppal- /fixinv- /verbatim- Subpictures_22.IFO Subpictures_22.sub


As you can see, the palette is correct in the SC and java versions, but not in the c++ version. It seems to have kept its hardcoded palette, despite the fact that an IFO was loaded and that a palette.ini file was provided via the command line. Seems there is still a problem with the precedence order.

Note that my GUI overwrites the original palette of the INI saved by SubtitleCreator, as I can't be sure that it picks the palette of the right PGC in the IFO. I can of course do it also for BDSup2Sub++, but the bug must be fixed anyway.

All other fields of the IDX files are identical, except the "custom colors:" line, that should be ignored anyway.

I can't understand why the outline is not visible in both versions of BDSup2Sub. IMO, there is also a bug in the SUB files, related to the transparency or the way the colours are mapped to the pixels. Anyway, there must be some differences in the SUB files as well, but I can't easily locate them.

r0lZ
3rd July 2012, 11:01
Just did another test with ++. Same command as above, except that I've removed the "--palette-file Subtitles_palette.ini" option, to check if the program takes the IFO palette into account when no external palette is provided. Same bug. :(

Then, I've loaded the IFO file in the GUI, and verified the palette. It was correct. I've exported the SUB, and the palette was again wrong in the IDX. So, IMO, the bug is not when the IFO/SUP/palette are loaded, but when the palette is saved. It saves always the default palette, instead of the imported palette.

SassBot
3rd July 2012, 12:14
Yes is red, but in mpc-hc or in my hdtv show in green or blue.

like in image i post before.

Then you have something broken. I played the IDX/SUB files you gave me in MPC-HC and it shows up with the same colors as I get when loading it in both the original Java and my BDSup2Sub. Unless that SUB/IDX isn't the source file you used I can't help you any further with that since I'm seeing the identical decoded output in anything I load what you gave me.

Thank you for the files you posted r0lz.

SassBot
3rd July 2012, 12:53
Ok, I found the problem. It had to do with how the palette files were written out. I copied some code straight from the Java that was causing problems. deadbeef had written code to do his own number to hex string which added a 0x to the beginning so he was creating a substring to clip off the 0x. I copied over this behavior without realizing it even though Qt's string class does hex string creation without the 0x. So what was happening was the first 2 bytes of each hex color was trimmed off giving the erroneous result. I now get the proper output for that IFO/SUP when outputting to IDX/SUB. No longer green.

r0lZ
3rd July 2012, 13:08
Good.

Can you have also a look at the problem of the missing outline? The original java version has that bug too, so I guess it will be harder to fix. :(

(BTW, when the SUB/IDX is reloaded in BDSup2Sub, the outline seems correct. But it is not when the movie is played with my LaCie LaCinema HD box. It's not a bug of the LaCie, as the subtitles generated with SubtitleCreator do not have that problem.)

SassBot
3rd July 2012, 13:14
Can you provide both the sub and idx of what you get from SubtitleCreator?

r0lZ
3rd July 2012, 13:21
No problem: http://download.videohelp.com/r0lZ/tmp/SubtitleCreator_subs.7z

SassBot
3rd July 2012, 13:40
Then, I've loaded the IFO file in the GUI, and verified the palette. It was correct. I've exported the SUB, and the palette was again wrong in the IDX. So, IMO, the bug is not when the IFO/SUP/palette are loaded, but when the palette is saved. It saves always the default palette, instead of the imported palette.

This is a bug in the Java version, too, when you use the GUI. I'm chasing down the issue.

Edit to add:
So the issue is that when you choose to export to IDX/SUB it has "create new" selected for the palette mode by default so it will only output the default palette. You have to select "keep existing" to get the palette that you want.

r0lZ
3rd July 2012, 13:59
OK, but IMO it should set "keep existing" by default. I don't see any reason to overwrite the (theoretically) right palette with the default one, almost always wrong. Anyway, it copies the default palette to the existing one if no palette has been provided (in blu-ray mode). If the user provides a palette (either with the IFO or with the palette CLI arg), why should it ignore it by default?

SassBot
3rd July 2012, 14:04
The behavior I described is only when you use the GUI. If you specify a palette file from the CLI it sets the flag to use the imported palette. The GUI on the other hand always defaults to "create new" when you choose IDX/SUB output and I just copied what the Java version did. Why deadbeef chose that I have no clue but I'm fine with changing it.

r0lZ
3rd July 2012, 14:08
... but I'm fine with changing it.
Great! :)

SassBot
3rd July 2012, 14:20
Beta 11 is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++b11.7z) with fixes for the aforementioned issues. Outline issue I still need to look in to.

SassBot
3rd July 2012, 15:32
Good.

Can you have also a look at the problem of the missing outline? The original java version has that bug too, so I guess it will be harder to fix. :(

(BTW, when the SUB/IDX is reloaded in BDSup2Sub, the outline seems correct. But it is not when the movie is played with my LaCie LaCinema HD box. It's not a bug of the LaCie, as the subtitles generated with SubtitleCreator do not have that problem.)

Just as a guess, does this (http://sw-planet.blogspot.com/2011/07/wdtv-live-subtitle-issues.html) sound similar to the issue you see? mjuhasz made a special branch of BDSup2Sub with some fixes for the WDTV Live issues he saw. Can you see if using it fixes the outline issue? If it does I can incorporate them into my version which will be enabled by a checkbox when you save the file or through a CLI option.

r0lZ
3rd July 2012, 15:35
Palette bug fixed and it is now possible to specify CLI arguments and open the source SUP. Good job!

However, in the export dialogue, the default language is always English, even if another language has been specified from the CLI. Can you change that?

Also, I've noticed a new "Subtitle language" dropdown box in the main window, but it is always disabled. What is (or will be) its usage? Will you remove the same option from the export dialogue? (IMO, that will be a good thing.)

SassBot
3rd July 2012, 15:38
Palette bug fixed and it is now possible to specify CLI arguments and open the source SUP. Good job!

Good!

However, in the export dialogue, the default language is always English, even if another language has been specified from the CLI. Can you change that?

Well that's because what you specify from the CLI will get overridden if the GUI is launched. I can add a flag to keep the setting.


Also, I've noticed a new "Subtitle language" dropdown box in the main window, but it is always disabled. What is (or will be) its usage? Will you remove the same option from the export dialogue? (IMO, that will be a good thing.)

It's for IDX/SUB files with multiple languages so you can change between the different tracks like the IDX/SUB from this post (https://forum.doom9.org/showpost.php?p=1572392&postcount=886).

r0lZ
3rd July 2012, 15:54
I can add a flag to keep the setting.
That will be OK, although IMO that flag is not necessary. If some settings are provided via the command line, I suppose that the program can assume that the user wants them by default. You can simply overwrite all defaults that have been specified with the CLI. (I've not verified, but according to the original doc, it's what the original version is supposed to do.)

Thanks for the other info, and for the very informative link. I'm currently doing some tests with colour indexes different than the last one, but I can already confirm that the last colour was used, and was black. But if it's really a bug of the player, I don't understand why SubtitleCreator doesn't have the same issue. Will try to understand...

SassBot
3rd July 2012, 15:58
That will be OK, although IMO that flag is not necessary. If some settings are provided via the command line, I suppose that the program can assume that the user wants them by default. You can simply overwrite all defaults that have been specified with the CLI. (I've not verified, but according to the original doc, it's what the original version is supposed to do.)

I was talking about an internal flag so that the setting doesn't get overridden when the file is loaded via the GUI. When you use the CLI it doesn't set that language settings until right before it saves the file so in that case it isn't overridden by the language id read from the IFO or IDX file. It was just a simple oversight.


Thanks for the other info, and for the very informative link. I'm currently doing some tests with colour indexes different than the last one, but I can already confirm that the last colour was used, and was black. But if it's really a bug of the player, I don't understand why SubtitleCreator doesn't have the same issue. Will try to understand...

Maybe SubtitleCreator does something similar to what mjuhasz did with his WDTV branch of BDSup2Sub? I'd look to see if the output you get from that WDTV version gives you the desired output and then I'll integrate the changes in.

r0lZ
3rd July 2012, 16:03
OK, understood.

For the outline problem, why not incorporate the fix anyway. Even if my problem is not that one, the fix may be useful to others. Just a suggestion.
BTW, sorry, I will need some time. I have to check all tries with my external LaCie, and copy the test MKV files with FTP. It's somewhat long...

r0lZ
3rd July 2012, 16:05
Oh, and I have another (little) suggestion. Could you print the version number of the program to stdout when a conversion is made from the CLI? IMO, it's an important info to add to the log.

r0lZ
3rd July 2012, 16:22
Goal! That was the problem!
Note that I have not used the mod. The original CLUT is almost entirely black, except colour 13 (light grey), assigned to e1. The black colours 12, 14 and 15 were used for b, p and e2. I've just reassigned them to colour 0, with DVDSubEdit. Then I've applied to all, and saved the subs in the original VOB. I did the whole process of demuxing and converting the SUP with your version, and muxed to MKV. Problem gone! :)
So, yes, the fix is needed! (I'm not sure the option to apply it is really necessary. Perhaps you can apply it anyway?)

SassBot
3rd July 2012, 16:26
Goal! That was the problem!
Note that I have not used the mod. The original CLUT is almost entirely black, except colour 13 (light grey), assigned to e1. The black colours 12, 14 and 15 were used for b, p and e2. I've just reassigned them to colour 0, with DVDSubEdit. Then I've applied to all, and saved the subs in the original VOB. I did the whole process of demuxing and converting the SUP with your version, and muxed to MKV. Problem gone! :)

Ok, I'll look into taking in the changes.

So, yes, the fix is needed! (I'm not sure the option to apply it is really necessary. Perhaps you can apply it anyway?)

As long as it has no negative effects on anything that doesn't need the fix it can be the default behavior. At least until we can see that the change is totally benign, I'll just make it a selection option for when creating subs for hardware players.

SassBot
3rd July 2012, 16:40
So that I can push out the 1.0.0 final, I will create a RC with the fix for the subtitle language not carrying over when specified via CLI later tonight. Unless there are any other showstoppers reported, I will push out the 1.0.0, tag that branch and then I will integrate the WDTV fixes in and do the mod 2 cropping change for the first iteration after that.

r0lZ
3rd July 2012, 16:43
IMO, the change should not have any impact if you swap the transparent colour with colour #15. Even if the stream uses all available colours, it should always be safe to put the transparent background in the last "slot", as long as the original colour of that slot is swapped too.

Now, the question is: do you need to swap the colours and transparency individually for each subtitle, or can you assume that all subpics use the same colours? I'm sure it's extremely rare, but it is theoretically possible to use all colours of the clut with a single subpic stream, since the colours can change at each subpic. So, IMO, to be safe, the swap must be made for each subpic individually.

SassBot
3rd July 2012, 20:03
IMO, the change should not have any impact if you swap the transparent colour with colour #15. Even if the stream uses all available colours, it should always be safe to put the transparent background in the last "slot", as long as the original colour of that slot is swapped too.

Okay, then I'll just integrate it.


Now, the question is: do you need to swap the colours and transparency individually for each subtitle, or can you assume that all subpics use the same colours? I'm sure it's extremely rare, but it is theoretically possible to use all colours of the clut with a single subpic stream, since the colours can change at each subpic. So, IMO, to be safe, the swap must be made for each subpic individually.

Yeah, subpic by subpic is the best way and also the way mjuhasz did it.

Also for the 1.1.0 release there's a comestic fix I'll implement for the IDX writing out. BDSup2Sub writes out the IDX in a different way than say VobSub or SubtitleCreator by leaving out some of the comment sections and using slightly different names for sections headers so I'm going to change mine to write out the file more the standard way.

For example from the IDX you sent me:


# VobSub index file, v7 (do not modify this line!)
# Created by SubtitleCreator v2.3rc1
#
# To repair desyncronization, you can insert gaps this way:
# (it usually happens after vob id changes)
#
# delay: [sign]hh:mm:ss:ms
#
# Where:
# [sign]: +, - (optional)
# hh: hours (0 <= hh)
# mm/ss: minutes/seconds (0 <= mm/ss <= 59)
# ms: milliseconds (0 <= ms <= 999)
#
# Note: You can't position a sub before the previous with a negative value.
#
# You can also modify timestamps or delete a few subs you don't like.
# Just make sure they stay in increasing order.


# Settings

# Original frame size
size: 720x576

# Origin, relative to the upper-left corner, can be overloaded by aligment
org: 0, 0

# Image scaling (hor,ver), origin is at the upper-left corner or at the alignment coord (x, y)
scale: 100%, 100%

# Alpha blending
alpha: 100%

# Smoothing for very blocky images (use OLD for no filtering)
smooth: OFF

# In millisecs
fadein/out: 0, 0

# Force subtitle placement relative to (org.x, org.y)
align: OFF at LEFT TOP

# For correcting non-progressive desync. (in millisecs or hh:mm:ss:ms)
# Note: Not effective in DirectVobSub, use "delay: ... " instead.
time offset: 0

# ON: displays only forced subtitles, OFF: shows everything
forced subs: OFF

# The palette of the generated file
palette: 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, CCCCCC, 000000, 000000

# Custom colors (transp idxs and the four colors)
custom colors: OFF, tridx: 1000, colors: cbcbcb, cbcbcb, 000000, cbcbcb

# Language index in use
langidx: 0

# French
id: fr, index: 0
# Decomment next line to activate alternative name in DirectVobSub / Windows Media Player 6.x
# alt: French
# Vob/Cell ID: 1, 1 (PTS: 0)


Whereas BDSup2Sub writes it out like:


# VobSub index file, v7 (do not modify this line!)
# Created by BDSup2Sub++ 1.0.0b11

# Frame size
size: 720x576

# Origin - upper-left corner
org: 0, 0

# Scaling
scale: 100%, 100%

# Alpha blending
alpha: 100%

# Smoothing
smooth: OFF

# Fade in/out in milliseconds
fadein/out: 0, 0

# Force subtitle placement relative to (org.x, org.y)
align: OFF at LEFT TOP

# For correcting non-progressive desync. (in millisecs or hh:mm:ss:ms)
time offset: 0

# ON: displays only forced subtitles, OFF: shows everything
forced subs: OFF

# The palette of the generated file
palette: 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, 000000, cccccc, 000000, 000000

# Custom colors (transp idxs and the four colors)
custom colors: OFF, tridx: 1000, colors: 000000, 444444, 888888, cccccc

# Language index in use
langidx: 0

# English
id: en, index: 0
# Decomment next line to activate alternative name in DirectVobSub / Windows Media Player 6.x
# alt: English
# Vob/Cell ID: 1, 1 (PTS: 0)

Not a major change most anyone will notice but will just make it look more like what other programs write out.

SassBot
3rd July 2012, 21:22
Release candidate for 1.0.0 can be downloaded here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100rc.7z). Now all CLI arguments should be properly override all values when the GUI is launched. It also outputs the program name and version number to the CLI when conversion starts. If no one can find any more showstopper issues I will tag the 1.0.0 branch and move on with the further fixes and enhancements. Also, I will start getting this packaged up for inclusion in Debian Testing.

r0lZ
3rd July 2012, 23:16
I haven't had much time to check all features and possibilities, and I did almost all my tests with the same DVD streams. I should still check the possibility to shift the subpics along the X axis, but that's for 3D BDs and I'm not working on that currently. I have also just downloaded the 1.0.0 RC, and it's already late here.
Anyway, the current version seems stable enough to release it.

Will you start a new thread for the final release? IMO, mixing the comments about the two versions in the same thread is confusing (and I need an URL for the Help menu of my GUIs!)

SassBot
3rd July 2012, 23:18
Yeah, I'll start a new thread.

SquallMX
4th July 2012, 03:23
Release candidate for 1.0.0 can be downloaded here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100rc.7z). Now all CLI arguments should be properly override all values when the GUI is launched. It also outputs the program name and version number to the CLI when conversion starts. If no one can find any more showstopper issues I will tag the 1.0.0 branch and move on with the further fixes and enhancements. Also, I will start getting this packaged up for inclusion in Debian Testing.

:helpful: the program is consuming GBs of RAM after loading Blu-ray SUP files:

http://img502.imageshack.us/img502/3832/bdsup.png

SassBot
4th July 2012, 03:55
Ok... How many subpictures are in the SUP file you loaded? How does that compare to the Java version? I just loaded a BD SUP with 618 subpictures and BDSup2Sub++ uses 30 megs of RAM after loading it whereas the java version is ~220 megs. During writing back out to a BD SUP it peaked at about 130 megs. Can you post the SUP file you were using?

SquallMX
4th July 2012, 07:35
Ok... How many subpictures are in the SUP file you loaded? How does that compare to the Java version? I just loaded a BD SUP with 618 subpictures and BDSup2Sub++ uses 30 megs of RAM after loading it whereas the java version is ~220 megs. During writing back out to a BD SUP it peaked at about 130 megs. Can you post the SUP file you were using?

It happens with any SUP file as long as you move from one subpicture to the next, and to the next... each additional subpicture increases RAM consumption by 20 MBs approx. So, after ~800 subpictures a Windows Warning Message about low RAM pops ups recommending me to close BDSup2Sub.

r0lZ
4th July 2012, 14:46
SassBot, I have an important work for you! (Not to do immediately, of course, but later, if you have some time.)

As you know, I've asked an option to shift the subpics horizontally by a few pixels, as it's necessary to hardcode blu-ray 3D subtitles over the video with Avisynth. You have been very kind to implement it. However, as you can see here (http://forum.doom9.org/showthread.php?p=1581205#post1581205), there is also a need for 3D SUB/IDX files, as this will allow us to add as many 3D subtitles streams as we want, and avoid to have to hardcode only one of them on the video. As far as I know, BDSup2Sub has already almost everything needed to do it.

There are 2 common methods to encode a 3D BD to MKV: side-by-side (SBS) and top/bottom (TB). In SBS mode, the left and right images are scaled horizontally by 0.5, and placed side by side (left first). In TB mode, they are scaled vertically, and the right image is placed under the left one. In the two cases, the subtitle has to be scaled and copied twice, over the corresponding images.

For example, in SBS mode, the subtitle must be scaled by 0.5 horizontally, and placed in the left and right part of the image, taking into account the 3D offset (the displacement in X, already implemented). In SBS format, the scaled subpic of the left eye must therefore be shifted to the left by ((video_X_resolution/*0.25) + offset), and for the right eye, shifted to the right by ((video_X_resolution*0.25) - offset).

In TB mode, the subpic is scaled vertically by 0.5. The left eye subpic must be placed in Y at (original_Y_position / 2) and in X at (original_X_position + offset). The right eye sub must be placed in Y at ((video_Y_resolution / 2) + (original_Y_position / 2)), and in X at (original_X_position - offset).

Do you think it is easy enough to generate the output 3D-SUB by copying the original subpic bitmap twice in the output bitmap as explained above? (The IDX file doesn't need any change, except perhaps a comment with the 3D mode and the offset value.) That would be very great, as currently, as far as I know, there is no app that can do it.

If you can do it, I suggest these CLI options:
--3d-mode mode (sbs, tb or none. Default none)
--3d-depth N (where N is the X offset, in pixels. Default 0, ignored if 3d-mode is none)

Note that, although it's not really useful, it should be possible to specify a negative 3d-depth, to place the subtitle below the surface of the screen, instead of above.

SassBot
4th July 2012, 17:43
It happens with any SUP file as long as you move from one subpicture to the next, and to the next... each additional subpicture increases RAM consumption by 20 MBs approx. So, after ~800 subpictures a Windows Warning Message about low RAM pops ups recommending me to close BDSup2Sub.

So this is where the memory leaks I knew existed are finally manifesting. I'll get them under wraps before pushing 1.0.0. There's lots of heap allocation going on without proper cleanup mostly just because I was copying over the code from the Java and I was just trying to get it up and running.

r0lz, I'll definitely look into that but it won't be until after 1.0.0 release.

r0lZ
4th July 2012, 17:49
r0lz, I'll definitely look into that but it won't be until after 1.0.0 release.
Thanks! :)
Of course, I understand that finishing v1.0 is more urgent.

SassBot
6th July 2012, 23:26
RC2 is now uploaded here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100RC2.7z). This has fixes for the major memory leaks especially when switching between subpictures that SquallMX pointed out. I was switching between sub images in a BD SUP with about 600+ subpictures and it only grew from around 22 megs of RAM after subtitle file was loaded to about 30 megs after having scrolled through about 300 images. Also when writing out the converted SUP the RAM usage only grew by about 10 megs as well. There are probably a few small memory leaks left that I'll squash but the major problems seem plugged. It also has a fix for a bug where hitting cancel on the progress bar didn't actually cancel the writing out of the subtitle file.

MaistroX
7th July 2012, 10:03
Hi SassBot!

Trying to use the latest RC2. (great Work btw.)
Trying to have to set "Y Offset 20 Top" to get all subtiltes to be shown above/top on the movie, Reason, movie is hardoded with German subs, but trying to add a English one, there for I need ALL subs to be placed at the top.
How do I go about to do that, cant find a option in "Move All Captions" ?

Regards MaistroX

SassBot
7th July 2012, 13:37
Just select "move from original Y position" and specify the offset you want so that the subs are positioned where you want.

r0lZ
7th July 2012, 13:47
MaistroX, maybe, after the conversion, you can also edit the org and/or align parameters in the IDX file. But note that some players ignore these values.

MaistroX
7th July 2012, 23:41
Sry, but I dont seem to understand! :/
I want to use "move all" in Move All Captions, but I can only get them below, not at the top and "move all" in any way I tryed so far, please help!
I dont want to move them one by one.

Just select "move from original Y position" and specify the offset you want so that the subs are positioned where you want.

Tryed exactly what u said above with RC2, "move from original Y position", original placement is below, and want them to be at the top in center all subs.
Higherst Offset Y I can set is 341, and it does not get the subs on top , them stay the same.

SassBot
9th July 2012, 18:30
Hmm seems to be that the code limits how far you can move vertically to 1/3 the height of the subpicture within the defined aspect ratio area. I don't know why that limit was chosen, though.

MaistroX
9th July 2012, 18:52
Can u expand it to hole image? :)

SassBot
9th July 2012, 19:16
Can u expand it to hole image? :)

I first need to see if I can figure out why that was chosen. I assume there was a good reason and make sure the change doesn't break something else deeper in the code. But it won't be until probably after the 1.0.0 release.

I still have some memory leaks to iron out, some reorganization and some optimization I want to get in first.

mood
11th July 2012, 14:54
Hi, SassBot...

rc2 crash when import from BDN xml/png and export to idx/sub, if the subtitle is long more than 2000 lines or near.

"Edit DVD Frame Palette" not work, any changes in this return to default.

And for me at the moment this version have the same problem that the java version has.

some lines of subtitle "randomly" appears with black background in my TV.

should be a bug on color palette in java version and continues in this version.

But i don't have programming skills to say if is a bug, I just report my problem use this tool. ;)

SassBot
11th July 2012, 15:18
Hi, SassBot...

rc2 crash when import from BDN xml/png and export to idx/sub, if the subtitle is long more than 2000 lines or near.
"Edit DVD Frame Palette" not work, any changes in this return to default.

The first could be an issue with some of the memory leaks that were still preset in that version. So when I post a new RC check again. I see the palette issue and am looking into it.


And for me at the moment this version have the same problem that the java version has.

some lines of subtitle "randomly" appears with black background in my TV.

should be a bug on color palette in java version and continues in this version.

But i don't have programming skills to say if is a bug, I just report my problem use this tool. ;)

Can you post the subtitle file so I can look at it?

SassBot
11th July 2012, 15:21
So the frame palette editing issue was because I hadn't finished implementing the functionality after you make the changes. :o Somehow I missed it.

mood
11th July 2012, 15:56
Ok...

I have two problems with this 2 subtitles...

This sub restarts my TV: :eek:

http://www.mediafire.com/?ca3xegs8uxtxx1w



And this "randomly" appears with black background in my TV. :(

http://www.mediafire.com/?4r3a3j6zn356j01


Is the same problem with java version.

I take 2 cell phone pictures of my TV, look it.

http://img716.imageshack.us/img716/6051/p1107121538.jpg

http://img713.imageshack.us/img713/9770/p1107121539.jpg

Take a look on pictures...

--------------------------------------------------------------------------------------


I use AVIAddXSub to make idx/sub and i never have a problem.

The only problem is the low resolution of subtitles.

SassBot
11th July 2012, 16:27
Ok, can you post the idx/sub you get from AVIAddXSub as well, then, so I can see what is different?

Also, here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++rctest.7z) is a testing version that you can use to see if the BDN+XML input causes a crash again.

Thanks.

mood
11th July 2012, 16:34
Ok...

here is the AVIAddXSub sub, and with this I don't have any black background or problem in my TV.

http://www.mediafire.com/?f5h6w747xl10fct

SassBot
11th July 2012, 16:42
Did you test if you can reproduce the crash with that test version?

mood
11th July 2012, 16:48
Did you test if you can reproduce the crash with that test version?

I test now and not crash :)

just need the fix on the color palette because the problem wih randomly black background persists.

Thanks for your work :thanks:

SassBot
11th July 2012, 16:50
Ok good. Also that contains a fix for the editing the dvd palette frame, too. I finishing up some more refactoring and then I should hopefully have the final 1.0.0 release early next week. The color palette issue will come also with the outline transparency fix r0lz reported in the next iteration after the 1.0.0 release.

mood
11th July 2012, 16:53
Ok good. Also that contains a fix for the editing the dvd palette frame, too. I finishing up some more refactoring and then I should hopefully have the final 1.0.0 release early next week. The color palette issue will come also with the outline transparency fix r0lz reported in the next iteration after the 1.0.0 release.

Ok...

take your time not worry...

and thanks ;)

SassBot
11th July 2012, 16:56
You're definitely welcome. Just trying to get to a nice stable base before making further fixing and enhancements since this was done as a very quick and dirty port.

SassBot
12th July 2012, 17:27
So what should hopefully be the last RC is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++rc3.7z). Please let me know if you see any issues and if not I'll push out and tag the 1.0.0 branch and start working on the latest enhancements and fixes.

mood
12th July 2012, 18:00
So what should hopefully be the last RC is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++rc3.7z). Please let me know if you see any issues and if not I'll push out and tag the 1.0.0 branch and start working on the latest enhancements and fixes.

Thanks SassBot, but I can't download the link is broken ;)

SassBot
12th July 2012, 18:08
Should work now. I seem to have accidently deleted the file after uploading it. :o

mood
12th July 2012, 18:10
Should work now. I seem to have accidently deleted the file after uploading it. :o

Oki, no problem...

Download now and I will test it.

Thanks...

SassBot
12th July 2012, 18:13
Yeah, let me know if you see any regressions.

There's a few GUI bugs fixed in that too. Also in the conversion dialog I've gotten rid of the accelerators on the store/restore/reset buttons. This way alt-o will work properly for the okay button on that dialog now.

r0lZ
13th July 2012, 13:38
CLI bug: This command doesn't work.

BDSup2Sub++.exe --language fr -o "11 Subtitle (PGS), French.sub" "11 Subtitle (PGS), French.sup"
BDSup2Sub++ 1.0.0 RC3
OPTION: Set language to French (fr)

Converting SUB/IDX

Loading C:/Users/rol/Desktop/BD3D2AVS_projects/My_BD/00485_m2ts/11 Subtitle (PGS), French.sup
Selected language 'French (fr)' by filename
ERROR: Cancelled by user!

I have NOT cancelled the process.
Note that the same bug occurs even without the --language option. But it works if the output file is not specified: the GUI opens and loads the input file.
It seems that the CLI code is broken when -o is specified.
Here is the SUP stream (http://download.videohelp.com/r0lZ/BD3D2AVS/11%20Subtitle%20%28PGS%29%2C%20French.7z) (but IMO, the same bug happens with any stream, although I have not verified).

Also, I wonder why the message "Selected language 'French (fr)' by filename" appears, since the language code has been passed via the CLI. (Not important if you can confirm that the CLI option takes precedence.)

SassBot
13th July 2012, 15:15
Ok, fixed version is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++100rc4.7z).

Also, I wonder why the message "Selected language 'French (fr)' by filename" appears, since the language code has been passed via the CLI. (Not important if you can confirm that the CLI option takes precedence.)


There was no flag to tell it not to try to do this. Now there is and it won't do that anymore. But, yes, it has no real effect since if you do specify the language Idx manually it is set immediately prior to writing out the subtitle file. That message gets printed as it is first reading the subtitle file.

Let me know if you see any other regressions.

SassBot
16th July 2012, 20:24
So I presume the silence means no more regressions found?

r0lZ
16th July 2012, 21:00
Not tested much. In particular, I have still not tested the option to move the subpics horizontally or vertically, but I should have some time to test it tomorrow. Also, I have not tested the GUI. But IMO, you can probably release 1.0 soon, or immediately if you wish.

mood
16th July 2012, 23:03
I have tested only GUI and RC4 work great, the problem with black background it seems that disappeared but i need test a little more.

Also sometimes I have crash with long subtitles, some memory leaks I suppose.

You need a little more optimize memory for BDN xml/png sometimes crash or consumes all my pc memory (4GB) and I can´t do anything on pc while process subtitles, if I do RC4 crash or freeze.

Sorry for my english, I hope you understand it. ;)

SassBot
16th July 2012, 23:14
Also sometimes I have crash with long subtitles, some memory leaks I suppose.

Can you post the subtitles that cause a crash? There should be no more memory leaks for loading or writing out subtitles. The few leaks left have are a few hundred K at best and not related to the subtitle load or writing code.

You need a little more optimize memory for BDN xml/png sometimes crash or consumes all my pc memory (4GB) and I can´t do anything on pc while process subtitles, if I do RC4 crash or freeze.

How many PNG files? I've loaded BDN+PNG with over 1500 subpictures and it doesn't do anything remotely like that. Can you possibly post the BDN+PNG files zipped up so I can see what is happening?

SassBot
16th July 2012, 23:34
Okay, so I just double checked and I loaded a XML+PNG with 1200 PNG files and the RAM usage went up to 18 megs and when rewriting it back out as a BDSUP it peaked at 22megs.

Edit to add: Can you tell me some more specifics of what you did exactly when it ate up all your RAM and crashed? And the exact file you can get it to reliably reproduce with is vital. Because I loaded the XML+PNG, scrolled through about a hundred subpictures than wrote it out as BDSUP and like I said, it barely went up in RAM usage from after being loaded.

mood
17th July 2012, 00:08
Okay, so I just double checked and I loaded a XML+PNG with 1200 PNG files and the RAM usage went up to 18 megs and when rewriting it back out as a BDSUP it peaked at 22megs.

Edit to add: Can you tell me some more specifics of what you did exactly when it ate up all your RAM and crashed? And the exact file you can get it to reliably reproduce with is vital. Because I loaded the XML+PNG, scrolled through about a hundred subpictures than wrote it out as BDSUP and like I said, it barely went up in RAM usage from after being loaded.

Sometimes I move all subtitles sometimes not.

Here is XML+PNG, this have more than 2500 png.

http://www.mediafire.com/?jzjji88404w96ki

Sometimes work without problem, sometimes crash or freeze.

r0lZ
17th July 2012, 14:12
Hum tested this:

bdsup2sub++.exe --move-x origin --move-x-offset 10 -o "11 Subtitle (PGS), French_left.sub" "11 Subtitle (PGS), French.sup"

and the program crashes at the end of the conversion.

Windows error info:

Problem signature:
Problem Event Name: APPCRASH
Application Name: bdsup2sub++.exe
Application Version: 0.0.0.0
Application Timestamp: 50002c55
Fault Module Name: bdsup2sub++.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 50002c55
Exception Code: c0000005
Exception Offset: 006ffc4c
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


If I add the --language fr argument, it doesn't crash.

r0lZ
17th July 2012, 15:05
Another thing. When I load the sup file via the GUI (or with just the input file as CLI argument), the backgrounds of the subtitles are transparent. But when I convert it from the command line, it is black, even without any additional argument (except --language, necessary due to the previous bug). I have deleted the ini file, just to be sure, but the result is identical. It seems to not use the same defaults when it is launched from the CLI. (Or it has a bug with the transparency when it is launched from the CLI, but that's strange.)

SassBot
17th July 2012, 15:12
Can you post the SUP file? There is no difference between when launched via CLI or GUI other than if you override a value with a switch.

SassBot
17th July 2012, 15:22
r0lz, try this (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++rc5.7z) and see if you still see either of your issues. There was a missing check to make sure alpha and langIdx were actually set properly before trying to set the override (though I did have a check for the luma threshold override). Otherwise it'd set an erroneous value which is probably your issue with both the crash and the alpha. It wasn't a problem before because it was setting it immediately when detecting the options, but I forgot to check since I moved the alpha, langIdx and luma threshold overrides to just before the writesub call.

To mood, I still can't reproduce your issue. :o Even with doing a move caption the RAM usage only goes as high as maybe 100 megs. I'll run it again through Valgrind tonight with your XML+PNG to see if I can find other issues with memory leaks that maybe I'm not seeing without it since you are seeing a magnitude more memory usage than I can get it up to.

SassBot
17th July 2012, 15:32
Download the file again if you already had, r0lz. There was one more fix that needed to be in that I forgot.

r0lZ
17th July 2012, 15:35
Not sure I've tried the latest version, but anyway, the two bugs are fixed (in one shot!)
Thanks.
I will retry with the new download, just to be sure...

[EDIT] Confirmed. No problem any more.

SassBot
17th July 2012, 15:37
The new download just has an additional fix for something else I noticed not anything related to what you posted.

SassBot
17th July 2012, 15:42
Okay, good. Well at this point I'm going to tag 1.0.0 branch and I'll recompile the file one more time to mark as the final. Anything else will now be fixed in a subsequent version. I'm also going to start a separate thread now.

r0lZ
17th July 2012, 15:53
OK, green light for me. ;)

mood
17th July 2012, 16:13
Ok SassBot, green light for me too.

Thanks...

r0lZ
17th July 2012, 16:20
Wait! It seems that the --move-x origin --move-x-offset -10 doesn't work. After having converted the same sup file with --move-x-offset -10 and --move-x-offset 10, they are identical. The pos in the GUI has not changed.

SassBot
17th July 2012, 17:01
I tried it with --move-x origin and various offset values and it's moving it correctly (even with the -10 and 10). I reloaded the output of the CLI in the GUI and the position of decoded subtitles from the CLI output matches the position of when doing the move within the GUI. I've even done a binary comparison between the outputs of doing the origin move from both GUI and CLI and they are identical. And doing -10 and 10 from the CLI does not give me the same output as I again did a binary comparison on that.

SassBot
17th July 2012, 17:16
And just to make sure it wasn't just confirmation bias using BDSup2Sub++, I opened up the offset -10 and offset 10 CLI output in SubtitleCreator and the horizontal position was offset as it was supposed to be.

r0lZ
17th July 2012, 17:16
I think I've found why it did not work here. I did my tests with very high offsets (-800 and +800) to verify if the subs are not moved out of the "screen", and with that values, the position is not changed at all. However, with more decent values such as -10 and +10, it works fine. So, IMO, there is a little bug. The subs should be moved as far as possible without going out of the screen when the offset value is too low or high. Instead, it does nothing, and no warning is printed. Not a big problem, but perhaps the bug may happen even with relatively small values such as -100, if the subtitle is very large. Not to worry, but IMO, it's something to fix (later if you wish).

BTW, if you sets a limit, don't forget that there is a little margin (IIRC 2 or 4 pixels) where the subpic cannot de located (for the DVDs). I don't know if the same limitation applies to BDs. Anyway, it doesn't make much sense to stick a subtitle to the border, so IMO, a minimal margin of, say, 10 pixels would be perfect.

SassBot
17th July 2012, 17:20
No, it's already limiting the range if you do a huge value like that. There's some other issue causing what you see that I'm trying to track down.

r0lZ
17th July 2012, 17:27
Can you reproduce it?

SassBot
17th July 2012, 17:28
r0lz I'm refreshing the 1.0.0 now that I know the error. Also, I've created a new thread to discuss BDSup2Sub++ in so we can leave this for the original Java version now.

FulciLives
24th August 2012, 12:50
I am re-encoding a 1080p Blu-Ray to 720p and it has subtitles so I used this (awesome) program to convert them to IDX/SUB format. However I tried leaving the subs at 1080p as well as resizing them to 720p and they seem to look basically the same when using VLC Media Player. So should I just leave them at 1080p (I'm watching on a 1080p monitor) or is it more proper to resize to 720p instead?

Any pitfalls over doing it one way (no resizing) vs the other (resizing)?

LeXXuz
24th August 2012, 14:36
I never resize picture subtitles. In most cases the downsized version just looks poor, even from 1080p to 720p, not to mention downscaling to SD resolutions.

Until now, I never had problems with subs in 1080p and video <1080p. Neither on PC or media players like TViX, WDTV etc. They play just fine.

So my advice: forget about resizing unless you have some exotic hardware for playback. ;)

FulciLives
24th August 2012, 14:38
I never resize picture subtitles. In most cases the downsized version just looks poor, even from 1080p to 720p, not to mention downscaling to SD resolutions.

Until now, I never had problems with subs in 1080p and video <1080p. Neither on PC or media players like TViX, WDTV etc. They play just fine.

So my advice: forget about resizing unless you have some exotic hardware for playback. ;)
Thanks!

Also good to know this will work with the WDTV because while I don't have one I have been thinking of getting one.

DoctorM
24th August 2012, 21:38
I am re-encoding a 1080p Blu-Ray to 720p and it has subtitles so I used this (awesome) program to convert them to IDX/SUB format. However I tried leaving the subs at 1080p as well as resizing them to 720p and they seem to look basically the same when using VLC Media Player. So should I just leave them at 1080p (I'm watching on a 1080p monitor) or is it more proper to resize to 720p instead?

Any pitfalls over doing it one way (no resizing) vs the other (resizing)?

VLC is one of the few players that resize the subtitles on playback to fit the window. (I believe this has something to do with the order in which it renders the subtitles with the video on playback as opposed to overlaying the titles after rendering.) (It's also why VLC can't add black borders and render the subtitles into that area.)

Many other players will play a 720p video with 1080p subtitles in a manner that the titles will be malpositioned or even outside of the player's viewing area (basically at full 1080 resolution). DirectVobSub & MPC-HT have this problem.

I've seen many bdrips (and it seems to be fairly common) with this combination. There'd be nothing wrong with this if the development of subtitle filters kept apace.

@LeXXuz - Maybe you should try a different resize method.

rakuen.now
31st August 2012, 01:09
I've been trying to post this for several days now. Okay, it seems most of you use BDSup2Sub mainly to convert blu-ray subtitles for DVD or MKV. You might remember mjuhasz a few months ago updated this to prevent flashing, or disappearing subs when played back with XBMC. He only fixed it, supposedly (I didn't test), for the DVD options, but not .sup(BD). I only use BDSup2Sub to move my blu-ray subtitles vertically so that they don't go into the black bars, since I have an anamorphic setup.

So I downloaded a Java IDE and a hex editor, and started my reintroduction to Java since college freshman year when I flunked. Luckily, it wasn't that hard to follow, though I'm still not too confident in my coding, so hopefully if someone has the same problem I did, maybe you could test this more extensively with me before whoever commits these changes to the official version -- if they do.

What you do is in the file 'SupBD.java', under the 'createSupFrame()' method, starting at line 606, whenever there is a DTS header as such:
setDWord(packetHeader, 6, dts);

Replace that with this:
setDWord(packetHeader, 6, 0);

And then in the last 'END' packet, on line 745, where it says:
setDWord(packetHeader, 2, dts);

Replace that with this:
setDWord(packetHeader, 2, timeStamp);

And the result should get you very close to what tsMuxer outputs. The timing will still be off by some milliseconds, but you won't notice any difference. I've tested this with a few titles (e.g. House of Flying Daggers, V For Vendetta, etc.) where the source subtitles go into the black bars area, and they seem to work. I tried submitting this to one of the gitHubs, but I have no idea how that works. But anyways, here it is. It doesn't look like 0xdeadbeef or mjuhasz is active, so maybe someone familiar with Java could try compiling it and testing it out. Thank you.

mjuhasz
1st September 2012, 20:42
Thanks!

Also good to know this will work with the WDTV because while I don't have one I have been thinking of getting one.

Just make sure you download the special version for WDTV: https://github.com/downloads/mjuhasz/BDSup2Sub/BDSup2Sub-wdtv.jar

I explained in a blog post (http://sw-planet.blogspot.com/2011/07/wdtv-live-subtitle-issues.html) why.

r0lZ
1st September 2012, 20:52
IIRC, that palette bug is also fixed in the latest ++ version.

mjuhasz
1st September 2012, 20:53
I've been trying to post this for several days now. Okay, it seems most of you use BDSup2Sub mainly to convert blu-ray subtitles for DVD or MKV. You might remember mjuhasz a few months ago updated this to prevent flashing, or disappearing subs when played back with XBMC. He only fixed it, supposedly (I didn't test), for the DVD options, but not .sup(BD). I only use BDSup2Sub to move my blu-ray subtitles vertically so that they don't go into the black bars, since I have an anamorphic setup.

So I downloaded a Java IDE and a hex editor, and started my reintroduction to Java since college freshman year when I flunked. Luckily, it wasn't that hard to follow, though I'm still not too confident in my coding, so hopefully if someone has the same problem I did, maybe you could test this more extensively with me before whoever commits these changes to the official version -- if they do.

What you do is in the file 'SupBD.java', under the 'createSupFrame()' method, starting at line 606, whenever there is a DTS header as such:
setDWord(packetHeader, 6, dts);

Replace that with this:
setDWord(packetHeader, 6, 0);

And then in the last 'END' packet, on line 745, where it says:
setDWord(packetHeader, 2, dts);

Replace that with this:
setDWord(packetHeader, 2, timeStamp);

And the result should get you very close to what tsMuxer outputs. The timing will still be off by some milliseconds, but you won't notice any difference. I've tested this with a few titles (e.g. House of Flying Daggers, V For Vendetta, etc.) where the source subtitles go into the black bars area, and they seem to work. I tried submitting this to one of the gitHubs, but I have no idea how that works. But anyways, here it is. It doesn't look like 0xdeadbeef or mjuhasz is active, so maybe someone familiar with Java could try compiling it and testing it out. Thank you.

Thank you for looking into this. 0xdeadbeef is not maintaining the code anymore but I am. While I may seem to be inactive I am still maintaining the code and planning to release a new version once I'm done with testing. You are always welcome to download the development snapshot version (https://github.com/mjuhasz/BDSup2Sub/downloads) and report issues on GitHub. Check the closed issues (https://github.com/mjuhasz/BDSup2Sub/issues?page=1&state=closed) for changes between the latest stable and the snapshot.

I created an issue for what you described on GitHub. I am on vacation/business trip in the upcoming weeks so some patience will be needed until I get to it (unless someone fixes it and sends me a pull request). Thanks for the pointers!

Chetwood
2nd September 2012, 06:53
So are you and Sassbot pooling your recsources or are we still seeing two different versions with more or less identical features?

SassBot
4th September 2012, 15:40
Well I didn't really create the version to compete with mjuhasz or take users. I just did it to get back into C++ programming and figured someone else might find use in it. If mjuhasz wants to combine resources that's fine with me.

Chetwood
5th September 2012, 06:11
Whatever you guys decided on, if fine by me. I was just wondering if you had implented the WDTV fix as well.

SassBot
5th September 2012, 18:09
I have done so on the local branch I'm working on. It's not pushed to github yet and won't be for a while still. There's a rather large amount of re-architecting I'm finishing up first.

Pawpcorn
19th September 2012, 21:05
Hi; has anyone come up with a program or method to merge TWO idx/sub subtitle files together?
Example: TWO different language idx/sub subtitle files, where I've re-positioned them both, so as not to appear in the same location on screen.
I'd like to merge them into ONE idx/sub file, to be able to turn BOTH on, or BOTH off, with any DVD player / program.
Thanks!!!
P.S. using .srt format files won't work in this case, since I don't have OCR software for THAI language :)

Chetwood
20th September 2012, 06:22
VobSub Shuffle can merge several languages into one VobSub, if that's what you mean.

Pawpcorn
20th September 2012, 06:34
VobSub Shuffle can merge several languages into one VobSub, if that's what you mean.
Thanks, Chetwood! I'll try it out, tonight! At first glance it looks like what I was looking for!
Thanks again,
Pawpcorn

Pawpcorn
20th September 2012, 20:54
Well.... I tried the VobSub Shuffle program tonight, combining an English idx/sub subtitle, and a Thai idx/sub subtitle. Both had been processed by BDSub2sub, with identical sizes and palettes... and it LOOKED like it worked: (Command screen:)
-----------------------------------------------------------
C:\Users\Gerald\Downloads\VobSub.Shuffle.1.0.Win32\VobSub Shuffle>vsshuffle combined eng thai

VobSub Shuffle version 1.0 - (C) 2010 by jeanl

Collecting all streams
eng.idx: 1 stream(s)
thai.idx: 1 stream(s)

Creating output sub file: combined.sub
eng.sub
thai.sub

Creating output idx file: combined.idx

Checking for streams in combined.idx not present in combined.sub
combined.idx: 2 stream(s)
combined.sub: 2 stream(s)

Done!
----------------------------------------------------------------
in that it created a new idx/sub subtitle "combined" that was twice as large as the two originals...
BUT...
When I opened the resultant file "combined" with BDSub2sub, only the English subs showed.

When I opened the resultant file with Subtitle Creator, it asked me "Choose Language Stream" with the choices of English or Thai. Only ONE language subtitle would load; not a combined merged subtitle display, which had been my hope.

When I created a DVD (AVStoDVD) using this combined idx/sub subtitle file... upon viewing the resultant DVD, select to display subtitles menu (in VLC) there was only ONE subtitle choice available to display (good!) but... unfortunately.... only the ENGLISH language subtitles appeared!

Any other ideas? I want to merge the two graphic images of two separate languages subtitles... to display both subtitle languages simultaneously (as ONE subtitle), when requested by the viewer.

I'm happy to supply the source and output data subtitle files, if this is of value to anyone...

Any ideas, anyone?
Thanks,
Pawpcorn

SassBot
20th September 2012, 21:50
That's because the Java BDSup2Sub doesn't handle IDX/SUB with multiple languages properly. It only loads the language specified by langidx in the IDX file and ignores all the others. The ported version I've created can handle streams with multiple streams and lets you switch between them but still contains the limitation of the original code that only one language is exported. It's something I mean to rectify but it's part of an every growing list of enhancements that I want to make.

Pawpcorn
20th September 2012, 22:12
Thanks, Sassbot, for your reply... You have to know that I use your program almost EVERY day, and it's just a Godsend to me! It was the final solution to sooooo many problems I used to have, working with vob subs...
Regarding the issue above, I'm just NOT clear on why these vob muxing programs have been written, if all they do is put two subtitle streams into one file... And in the various programs that input idx/sub subtitles, u have to select which stream to work with in further steps, and you're back to seeing only a single subtitle once you've done that.... Confusing to me.
WHAT program, or what situation can take advantage of multiple subtitle "streams"?
Thanks again for your terrific program!
Pawpcorn

Chetwood
21st September 2012, 06:05
Vobsub Shuffle works for me. Anytime I combine separate languages with it, I can later cycle through them while playing back the file. Subtitle Creator also can combine subs streams: open the second sub stream and save it under the name of the first stream. It first asks you to overwrite it but after selecting yes it asks again if you want to add this stream. In case this also doens't work, upload the files to Mediafire or something so we can have a look.

r0lZ
21st September 2012, 08:32
Pawpcorn, I don't think what you want is possible with a one-click program. Merging the individual images of two different subtitles into single images, to build a single multi-language stream is technically difficult, as that would require that both streams have all subtitles perfectly synchronized. For example, if the first subtitle of your English stream starts at 0:00:01.000 and the corresponding subtitle of the Thai stream starts at 0:00:01.500, the program will have to decide what time code it must keep, or create a sub with English only from 0:00:01.000 to 0:00:01.500, and then add the multilingual subtitle at 0:00:01.500. Also, the program will have to move one subtitle up or down if both are at the same place in the original streams. AFAIK, no program can do that.

Perhaps you can try to convert both subs to BMP files, and merge them yourself with a batch image processing program like ImageMagick, then rebuild the IDX/SUB steam. If there are the same numbers of subtitles in both streams, and if you can assume that the timings of one of them is suitable for the other one, that should work.

Anyway, I don't understand why you want to display two languages at the same time. What's the benefit? Is it for a multi-language audience?

Pawpcorn
21st September 2012, 08:35
Hi, Chetwood, thanks for your message.

I think there's some understandable confusion regarding my terminology about what I'm trying to do...

I tried your method (SubtitleCreator) and this action is appending subtitle files.

What I'm trying to do is an actual merge of two graphic subtitle images... into one, for each and every subtitle image.

I've included a picture of what the result would look like here: http://www.4shared.com/photo/rU-_1xIG/example_of_DUAL_subtitles.html

This is a screen dump of the procedure I've been using, utilizing VirturalDub, to create my desired effect (The Avengers).

Unfortunately, the subs are burnt into the video, using this method, and can't be turned on or off, as such.

Do you know of any software which can merge two graphic images, subtitle by subtitle, into one, to produce this effect?

I can see it as a near-impossible software task, considering that the timecodes for the images wouldn't match, exactly; and it's not always an image for image match.

In the "Catwoman" project I'm working on at the moment, for example, the English subs include 807 images, and the Thai subs include 821 images. And even in the cases of "matching" images... they don't really pop on and off at exactly the same frame...

I've included the subtitle files here, if this can be of some use:

eng.sub http://www.4shared.com/file/c11HlUkg/Eng.html

eng.idx http://www.4shared.com/file/vComAq1P/eng.html

thai.sub http://www.4shared.com/file/sLgI13QG/Thai.html

thai.idx http://www.4shared.com/file/QQM8iCrL/thai.html

Maybe this is just wishful thinking... :confused:
Thanks for your advice and help!:D
Take care,
Pawpcorn

Pawpcorn
21st September 2012, 08:46
Pawpcorn, I don't think what you want is possible with a one-click program. Merging the individual images of two different subtitles into single images, to build a single multi-language stream is technically difficult, as that would require that both streams have all subtitles perfectly synchronized. For example, if the first subtitle of your English stream starts at 0:00:01.000 and the corresponding subtitle of the Thai stream starts at 0:00:01.500, the program will have to decide what time code it must keep, or create a sub with English only from 0:00:01.000 to 0:00:01.500, and then add the multilingual subtitle at 0:00:01.500. Also, the program will have to move one subtitle up or down if both are at the same place in the original streams. AFAIK, no program can do that.

Perhaps you can try to convert both subs to BMP files, and merge them yourself with a batch image processing program like ImageMagick, then rebuild the IDX/SUB steam. If there are the same numbers of subtitles in both streams, and if you can assume that the timings of one of them is suitable for the other one, that should work.

Anyway, I don't understand why you want to display two languages at the same time. What's the benefit? Is it for a multi-language audience?
Hi, ROlz! Thanks for your reply! I saw it just after posting my "additional info" post.
hahahaa.... yes!!! They are my Thai students, in my English class, and this method is seen as somewhat helpful in helping them learn English! (I'm a full-time English teacher, at an in-mall English (business) school, here in Bangkok)

Good query, I'm sure this need and application would seem illogical, if it weren't for my situation here... thanks for the input!

I've thought about what you suggested doing, and... as you can imagine, (I'm sure) it would be a rather labor-intensive task, especially since I'm trying to create one of these DVD movies PER week for my adult students (in my free time, NON-paid hahhahaha) and my plate is fairly full, as is :(

Oh... I could take care of the text placement (shift English down, shift Thai up), ahead of time, using BDSup2Sub, so there wouldn't be any visual conflict if the images were just "mixed" in an additive fashion.

Thanks again for your interest and advice!
Take care,
Pawpcorn

r0lZ
21st September 2012, 09:23
Indeed, with BDSup2Sub, you can "prepare" manually the two original streams so that the subtitles do not overlap. If that problem is solved, it should be possible to write a simple program or script to analyse the IDX files, and build the output IDX and BMPs accordingly with ImageMagick. The program could assume that, if a particular subpic is present in both streams, it must use the time code that comes first for the beginning, and the last one for the end. That should work in most cases. But there is an additional difficulty. For example, a long sentence can be split in two subs in one language, but kept in one single sub in the other stream. Or a new Thai sub can begin before the current English sub pops out. As you can see, that cases are more difficult to solve, but not impossible. Anyway, writing that program requires some programming skills. If I have some time, I may try to do it, but don't count on that!

Pawpcorn
21st September 2012, 13:33
Dear rOIZ, indeed, would be a challenging programming task!
At 63 now... my programming days seem behind me at this point in life; trying to teach English to Thais, whose native language provides a distinct disadvantage to learning English, is pretty challenging, in it's own right.

I USED to write programs, in the past, and if I were going to approach this, I'd just use brute force; create a table that duplicated reality of what got shown, and separate graphic images for every unique moment. Thus... this could result in 2 frames of Thai-only sub graphic, then 60 frames of mixed English and Thai, and maybe 3 more frames of English only sub graphic. I'd make NO effort in trying to "clean up" any of this, allow that there could be an abundance of sub images, and a large resultant file, but really, see no practical problem in huge idx/sub files, since we're really looking at a specialized situation here, and just being able to provide a working solution is success itself; it wouldn't need to be clever nor pretty :)

Hey, question for you, SassBot and rOIZ, I have a frequent task where I need to locate every subtitle that has been shifted to screen TOP (to avoid picture content at bottom) and manually shift it to screen BOTTOM (where I've provided a nice black area for my subtitles)

Currently, using BDSup2Sub, I have to click through EVERY SINGLE subtitle in the movie, to spot which subtitles are at screen TOP, and move them to screen BOTTOM, manually. For "The Avengers" I had to click the [>] button over 1600 times to look at every single subtitle, and... you know... how this really tests my patience and carpal tunnels...

Is there anyway to ask, and be told, which frames are at screen TOP, to avoid this manual process?

Thanks! Take care,
Pawpcorn

r0lZ
21st September 2012, 15:54
I don't think there is a way to automatically locate the top subtitles. But I have had to do a similar job. I've used "Move all captions". You should set the Crop Offset Y and enable the Crop Bars, then move all captions by a large Y value, for example 3000. All captions will be moved to the bottom of the screen (including the top ones), but not below the bottom crop bar. Then, accept the dialog, and use Edit -> Reset Crop Offset to freeze the subtitles at their current positions. Save.
That works fine, but with some limitations. It's not the baseline of the text that is taken into account when the caption is moved down and constrained by the crop bar, but the bottom-most non-transparent pixel. That means that the lines of the different captions are not perfectly aligned any more, but it's not visually important. Also, a caption with a single line of text is moved to the bottom, exactly like a caption with two lines. I would have preferred to move the captions with a single line less, so that it is aligned with the first line of the double-line captions. That should be possible by moving first all captions up, then down by a specific offset, but unfortunately, due to the bug I've reported above, you cannot move the captions up, and therefore it's currently impossible.
So, currently, it is possible to do more or less what you want, but not in a precise way.

Chetwood
21st September 2012, 17:00
Now I'm getting it too! If it wasn't for the Thai characters I'd said another way would be to convert both subs to ASS, change the vertical position of one sub and merge them manuelly. Or something...

Pawpcorn
21st September 2012, 17:03
Thanks, r0IZ, I'll give that method a try!
This always bugs me, because I could SWEAR, a couple years ago... using some forgotten piece of software on my laptop... I remember seeing statistics for how many (or which?) subtitles were TOP subtitles... Damned if I can remember what program that was...
Thanks again for the advice!
Take care,
Pawpcorn

Pawpcorn
21st September 2012, 18:06
Now I'm getting it too! If it wasn't for the Thai characters I'd said another way would be to convert both subs to ASS, change the vertical position of one sub and merge them manuelly. Or something...
Yes! The Thai font makes things rather compicated, especially since I can't OCR the darned thing down to raw text...
We have so many tools to manipulate subtitles... But no way to truely mix 2 idx/sub subtitle images together, keeping the original timecodes of both...

jd213
22nd September 2012, 05:37
Would it be possible to separately convert each idx/sub file to xml/png format with BDSup2Sub, put all of the png files into one directory, and then edit the xml file to include all of the png files/timecodes? I've done this a couple times when merging multiple subtitle tracks from anime DVDs into one subtitle track (for reauthoring the same title on Blu-ray). It seemed to work fine, although it only contained English subs and I didn't try converting back to idx/sub.

Chetwood
22nd September 2012, 06:01
Yes! The Thai font makes things rather compicated, especially since I can't OCR the darned thing down to raw text...
I wanted to give SubExtractor (http://subextractor.codeplex.com/) a try, however, I'm not signing up on 4shared for this. Also, why not compress all files into one rar, it should be small enough.

I've done this a couple times when merging multiple subtitle tracks from anime DVDs
Yeah, I was a going to suggest checking anime fansubber forums who might know some tricks.

Pawpcorn
22nd September 2012, 15:21
I wanted to give SubExtractor (http://subextractor.codeplex.com/) a try, however, I'm not signing up on 4shared for this. Also, why not compress all files into one rar, it should be small enough.


Yeah, I was a going to suggest checking anime fansubber forums who might know some tricks.

I appreciate the idea about anime fansubber forums...

Oh, I tried to upload (attachments) the subs files as an .rar, but it was over 2MB, (the Thai sub alone was 1.2MB), and I'm limited to 200 kb here...:(

I looked at subextractor, but I'm pretty certain it doesn't include OCR software for the Thai Language.

The 4shared site is free and without a catch, AFAIK...

I could email them to you, if you PM your email address...

Take care,
Pawpcorn

Pawpcorn
22nd September 2012, 15:24
Would it be possible to separately convert each idx/sub file to xml/png format with BDSup2Sub, put all of the png files into one directory, and then edit the xml file to include all of the png files/timecodes? I've done this a couple times when merging multiple subtitle tracks from anime DVDs into one subtitle track (for reauthoring the same title on Blu-ray). It seemed to work fine, although it only contained English subs and I didn't try converting back to idx/sub.
Thanks for the advice, jd213! This method would learning a number of new (for me):o procedures... I may give it a try, as time permits;
Thanks for the advice!
Take care,
Pawpcorn

Tappen
25th September 2012, 22:55
I'm the author of SubExtractor, and I did add support for Thai OCR in the most recent release (1028). I worked for several months with a Thai speaker to get the diacriticals and other combo characters OCR'd and ordered correctly.

Chetwood
26th September 2012, 10:13
Mh, so since I don't have any Thai font installed on my system, Subextractor does not show these chars to enter below the current OCR'ed char? Pawpcorn's Thai sub is hard to OCR, apparently whoever created it, messed with the palette.

Tappen
26th September 2012, 23:44
The character selector block is fixed - I've been trying alternatives to allow editing of this part of the UI but haven't released any yet.

So you have to type in the Thai characters by hand. My testers had Thai keyboards of course so it was easy for them, and I used the wikipedia page with the character set on it to cut and paste characters into the manual entry box. Slow but got the job done.

eTiMaGo
27th September 2012, 10:22
I'm the author of SubExtractor, and I did add support for Thai OCR in the most recent release (1028). I worked for several months with a Thai speaker to get the diacriticals and other combo characters OCR'd and ordered correctly.

I could kiss you! ahhaha

I'm in Thailand too, and in a similar situation to pawpcorn, I like to watch movies and series in HD, but my GF needs Thai subtitles which are suually only available on the DVDs... While MultiAVCHD and BDSup2Sub have been excellent for this, in many titles the timing of the subtitles is quite a bit different and hard to get right, having them in text format will definitely help!

Pawpcorn, as I understand it you'd want to show both English and Thai subtitles at the same time, right? I think some PC DVD/BD player software like PowerDVD can display 2 subtitle languages? If not the next easiest solution, I think, would be to hard-burn the english subs on the video, and have Thai subtitles as selectable ones? Just an idea!

Chetwood
28th September 2012, 07:02
Isn't up to four lines of subs covering too much of the picture anyway?

rakuen.now
8th October 2012, 09:15
Well, I'm not really a programmer, but I took a look at those files and don't see that this would be too hard for a programmer who's interested. You could probably do it by combining free code online. What I would do is, after converting the thai and eng sub to XML/PNG in BDSub2Sup, write a program that:

1. Create a list for each language.
2. Traverse through them both sorted by timecode.
3. Create a 3rd output list.
4. If a frame for one language does not have a corresponding frame within a second of its start time in the second language, output that frame and the PNG directly.
5. If the start time for a frame for one language is within a second of a frame of the second language:
5a. Sync the timecodes
5b. Combine the PNGs into 1 PNG (example (http://www.switchonthecode.com/tutorials/combining-images-with-csharp))
5c. Figure out the vertical pixel change, and output this into the output list.
6. If the start time for a frame of one language is not within a second of a frame from the second language, but there is overlap, create 3 frames where the 2nd one is the overlap (not the ideal solution, but easiest).
7. Write the output list back into XML format.
8. Load the XML and combined PNGs into BDSup2Sub and turn it back into sub/idx.

bernd_b
9th October 2012, 21:11
Hello,

I ripped one of my DVDs using DVDFab. The resulting idx/sub files causes BDSUP2SUB to crash:

java.lang.NullPointerException
at bdsup2sub.supstream.dvd.SubDvd.readSubFrame(SubDvd.java:479)
at bdsup2sub.supstream.dvd.SubDvd.<init>(SubDvd.java:135)
at bdsup2sub.core.Core.readDVDSubstream(Core.java:567)
at bdsup2sub.core.Core.readVobSub(Core.java:526)
at bdsup2sub.core.Core.run(Core.java:161)
at java.lang.Thread.run(Thread.java:722)

What does this error message indicate? I can, e.g. work with these subtitles using avidemux ocr-function, so they shouldn't be pure crap?!?

If it is of help, I can upload an example somewhere (the attachment would be about 0.5-1MB and there to big to attach it to the post here in the forum.

SassBot
9th October 2012, 23:48
Post the sub/idx and I can tell you.

bernd_b
10th October 2012, 19:34
O.K,

I tried to upload an example of an idx/sub pair which works in avidemux2 ocr tool but made BDSUP2SUB crash:

http://dl.dropbox.com/u/963354/working_not_working.zip


May one of the links work. Here again the error message:

java -jar /extern08/BDSup2Sub-5.0-SNAPSHOT.jar
java.lang.NullPointerException
at bdsup2sub.supstream.dvd.SubDvd.readSubFrame(SubDvd.java:479)
at bdsup2sub.supstream.dvd.SubDvd.<init>(SubDvd.java:135)
at bdsup2sub.core.Core.readDVDSubstream(Core.java:567)
at bdsup2sub.core.Core.readVobSub(Core.java:526)
at bdsup2sub.core.Core.run(Core.java:161)
at java.lang.Thread.run(Thread.java:722)


BDSup2Sub - Version 5.0 snapshot Built on 2012-09-15

mjuhasz
12th October 2012, 19:55
Unfortunately all the links are dead.

bernd_b
13th October 2012, 10:08
First try first crap.

Maybe this one is of help:

http://dl.dropbox.com/u/963354/working_not_working.zip

r0lZ
13th October 2012, 10:19
There is an additional coma at the end of the palette in the IDX file. If you remove it manually, you can open the file.
Obviously, it's a little bug, easy to fix.

bernd_b
13th October 2012, 15:34
The coma trick didn't work here.

DVDFabs produces some idx/sub files which can be loaded into BDSUP2Sub without problems and some which cannot. All have the coma at the end of the palette line - I understood it is this line:

palette: 101010, 646464, e2e2e2, eaeaea, 0feb0e, ea10ea, ebeb10, 107b7a, 7b7b7b, d1d1d1, 7a110f, b9303b, 101010, 646464, e2e2e2, 7b107a,

I uploaded a working and not working example produced by DVDFab (and corrected the links accordingly of my previous posts). Both pair of subtitle files can be processed with avidemux ocr-function, but the one called not working leads to a crash of BDSUP2Sub:

http://dl.dropbox.com/u/963354/working_not_working.zip

Before crashing with the above shown error message, I can additionally see the following message in the window message window on the bottom left side:


...

#157
#158
#159
WARNING: Control buffer size inconsistent.
WARNING: RLE buffer size inconsistent.
WARNING: Invalid end sequence offset -> no end time
WARNING: Invisilble caption due to zero alpha - unsed alpha info of last caption.
#160
WARNING: Invalid fragment skipped at ofs 0x000bf800

r0lZ
13th October 2012, 16:10
Your previous example worked without the tailing coma with BDSup2Sub++.exe. I have not tried the java version.

Ghitulescu
13th October 2012, 16:26
Anyway, I don't understand why you want to display two languages at the same time. What's the benefit? Is it for a multi-language audience?

I cannot possible believe :) I met another one that is not contaminated by the anime-mania. :)

Multiple language subtitles are extremely wanted in these circles, to display both Japanese and the secondary language in the same time.

bernd_b
13th October 2012, 17:53
Your previous example worked without the tailing coma with BDSup2Sub++.exe. I have not tried the java version.

O.K:, didn't see the windows version. Works with the grace of wine here too under linux after deleting the coma, but exporting the subtitle fails with:
...

Decoding frame 159/329 at offset 000bf000
ERROR: Corrup buffer offset information

So same issue, but at export instead of at loading the sub?

r0lZ
13th October 2012, 18:16
Sorry, I haven't tried to export it. I've assumed that your problem was limited to the error when loading.
IMO, you should try to extract the original subs with another tool. DVDFab has a lot of bugs.

cyberbeing
14th October 2012, 01:24
The idx file which doesn't load has an invalid line.
timestamp: 00:11:21:480, filepos: 0000bf000
timestamp: 06:24:34:465, filepos: 0000bf800
timestamp: 00:11:24:000, filepos: 0000c0000

mjuhasz
14th October 2012, 07:37
That's correct. You can remove that line and both the stable and the snapshot BDSup2Sub will read/export it then.

This may be a bug in DVDFab but I'll check how BDSup2Sub can be more graceful and skip this automatically (write a warning and move on, instead of crashing).

The idx file which doesn't load has an invalid line.
timestamp: 00:11:21:480, filepos: 0000bf000
timestamp: 06:24:34:465, filepos: 0000bf800
timestamp: 00:11:24:000, filepos: 0000c0000

MaistroX
22nd October 2012, 08:33
Downloaded latest, get the same stop and error, please help! :/
See attached text here -> http://www.mediafire.com/file/41cubs0s716rwlf/BD3D2MK3D_-_Wold_Of_War_II_3D.txt

r0lZ
22nd October 2012, 10:20
Wrong thread, MaistroX. Please port in the right thread (http://forum.doom9.org/showthread.php?t=155246).

cyberbeing
8th November 2012, 00:19
Any chance of adding the ability to change the colors/palette of SUP(BD) subtitles in a future version?

If not, is there any other program which can modify and export SUP(BD) with custom colors?

mjuhasz
9th November 2012, 08:12
Not in the near future.

The subtitle data on a Blu-Ray consists of images with a color/alpha palette of up to 256 entries. To make things worse, each subpicture frame can have a separate palette, i.e. you'd have to edit potentially hundreds of thousands of palettes with 256 entry each.

Most blu-rays I came across did not use all 256 palette entries and had the same palette for all images but this is not true in general.

This is not the first time this feature has been requested so I created an issue (https://github.com/mjuhasz/BDSup2Sub/issues/23) for it on github and time permitting I'll investigate whether I could come up with a simple editor.

Any chance of adding the ability to change the colors/palette of SUP(BD) subtitles in a future version?

If not, is there any other program which can modify and export SUP(BD) with custom colors?

cyberbeing
9th November 2012, 23:23
Could you throw together some code more quickly which only changes the palette of the first subpicture to 100% Red or 100% Green or 100% Blue. In my case, I just need I way to create colored PGS samples for renderer testing purposes. I unfortunately don't own any Blu-rays with PGS subtitles other than light-gray, so it's a bit of a problem. I assume the PGS file actually needs to be parsed, and it wouldn't be trivial to identify and hack at the palette in a hex editor?

Alternatively, if anybody would send me small samples (only a single PGS subpicture is fine) of colored PGS subtitles from their Blu-rays, I would be grateful.

sneaker_ger
9th November 2012, 23:25
I don't have samples at hand but you could easily create those yourself with avs2bdnxml (http://forum.doom9.org/showthread.php?t=146493), I guess.

cyberbeing
10th November 2012, 02:47
Thanks sneaker_ger, avs2bdnxml seems to work well for doing what I needed.

mjuhasz
10th November 2012, 13:09
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).


In my case, I just need I way to create colored PGS samples for renderer testing purposes.

theonlyone
15th November 2012, 17:43
I`m getting this error when I open an SUP file. It does not happen with a SUB file.

I downloaded the latest version of BDSup2Sub and also re-installed the JVM with no luck.

Any help would be greatly appreciated.

Thanks.

theonlyone
17th November 2012, 15:09
I found a workaround.

The problem only happened with SUPs from a specific BD (U2: Rattle and Hum). Those SUPs crash all versions of BDSup2Sub, including the latest beta (https://github.com/mjuhasz/BDSup2Sub/wiki/Download) and even the C++ port (http://forum.doom9.org/showthread.php?t=165416). Nasty!

I used SUPRead (http://forum.doom9.org/showthread.php?t=121535) to read the SUP file and export it to another BD-SUP file and then used BDSup2Sub to do its thing.

sneaker_ger
17th November 2012, 20:26
Please upload those subtitles, so the devs can fix the crash.

frencher
18th November 2012, 03:50
Last updates is here (https://github.com/mjuhasz/BDSup2Sub/downloads) BDSup2Sub-5.1-SNAPSHOT.jar

DivX220
2nd December 2012, 20:59
Hello,

I get this error ''Offset 66847570 out of bounds for file <path to file>" each time I try to open a SUP file extracted with Project-X from an European DVB .m2ts file.

The first time I thought it was because of a crop of the beginning of the .m2ts file, but I tried two more times with no crop, and I get the same error.

Any help would be greatly appreciated.

Thanks.

mjuhasz
3rd December 2012, 07:38
It's hard to tell what the problem is without seeing the actual sup file. Please share it with me so that I can have a look.

Some explanation about why these kind of error happen (extracted from the wiki (https://github.com/mjuhasz/BDSup2Sub/wiki/Known-Issues)):

Reading/writing data from/to transport streams is quite a hassle since the formats are usually not well documented and you will always stumble over a stream that either contains authoring errors or uses features so uncommon that they are not documented anywhere. Indeed, most of the time it is impossible to tell if some weird stream is only on the edge of what is allowed or simply faulty. So often enough, programs that read or write transport streams will only support a certain amount of commonly used (and known) sub-features. Therefore it is likely that BDSup2Sub will stumble over the streams created by other programs or other programs will have problems reading the streams created by BDSup2Sub and it's generally hard to tell whose fault it is.

Hello,

I get this error ''Offset 66847570 out of bounds for file <path to file>" each time I try to open a SUP file extracted with Project-X from an European DVB .m2ts file.

The first time I thought it was because of a crop of the beginning of the .m2ts file, but I tried two more times with no crop, and I get the same error.

Any help would be greatly appreciated.

Thanks.

Selur
5th December 2012, 16:53
a SUP file extracted with Project-X from an European DVB .m2ts file.
afaik only BD-SUP = SUP streams like they are on a Blu-ray and not DVB-SUPs are supported by BDSup2Sub

mood
9th January 2013, 22:51
What is the last update? 5.1.1 or 5.2 SNAPSHOT out before 5.1.1??

Superb
10th January 2013, 00:39
Looks like a nice release. Thanks. The only reason I keep using BDSup2Sub++ is its support for multi-language IDX/SUB files.
I can easily switch the language w/ the combo-box they added. Very useful.

mjuhasz
10th January 2013, 10:14
What is the last update? 5.1.1 or 5.2 SNAPSHOT out before 5.1.1??

As you can see on the Download page (https://github.com/mjuhasz/BDSup2Sub/wiki/Download) the latest version is 5.1.1

The SNAPSHOT version is a build made from the latest source code. It may not be stable at certain times since it's a work in progress. Those running it can provide me with valuable feedback by creating issues on GitHub. Those who don't want to test but need a stable version should run the latest stable version instead.

5.1.0 had the convert resolution feature broken and it was well worth making a bugfix release for it, that is 5.1.1. There was not enough change to bump the version to 5.2.0 since it only fixes a couple of bugs. Of course 5.2.0 will have the fixes as well.
To recap, 5.1.0 was followed by 5.1.1 and we can have more 5.1.x releases and eventually we'll have 5.2.0. I hope this answers your question.

mood
10th January 2013, 15:26
As you can see on the Download page (https://github.com/mjuhasz/BDSup2Sub/wiki/Download) the latest version is 5.1.1

The SNAPSHOT version is a build made from the latest source code. It may not be stable at certain times since it's a work in progress. Those running it can provide me with valuable feedback by creating issues on GitHub. Those who don't want to test but need a stable version should run the latest stable version instead.

5.1.0 had the convert resolution feature broken and it was well worth making a bugfix release for it, that is 5.1.1. There was not enough change to bump the version to 5.2.0 since it only fixes a couple of bugs. Of course 5.2.0 will have the fixes as well.
To recap, 5.1.0 was followed by 5.1.1 and we can have more 5.1.x releases and eventually we'll have 5.2.0. I hope this answers your question.

Thanks for answers ;)

QUEENFAN
7th February 2013, 09:17
Hello,

I get the following error using BDSup2Sub (5.1.1) with multiAVCHD:

!!! Error converting subtitles! (java?)

My system is a Windows 8 Pro x64.

Same installed software on a XP system (Virtualbox) runs without any error.

Java is installed on both systems.

Any clue?


Thanks a lot in advance for your help.

paradoxical
7th February 2013, 16:32
With such vague information I doubt you can be helped. What was the file being processed by BDSup2Sub? Is there a log with more info?

QUEENFAN
8th February 2013, 07:36
@paradoxical

Thanks a lot for your quick answer.

How can I provide you with the requested detailed information?

BDSup2Sub runs in multiAVCHD so I haven't detailed logs regarding BDSup2Sub.

The part of the log concerning BDSup2Sub is:

[07:29:04] Processing 3 titles...
[07:29:04] Processing (DVD (01) D:\Deadwood TEST_\VIDEO_TS\)...
[07:29:04] Pre-processing DVD input (D:\Deadwood TEST_\VIDEO_TS\)...
[07:29:04] *** Detected duration: 00:10:30
[07:29:04] *** Subtitles: 720x576 25.000 ID#1 (deu)...
[07:29:04] *** Extracting subtitles ID#1 (mencoder)...
[07:29:19] *** Converting DVD subtitles to Blu-ray format (java:BDSup2Sub)...
[07:29:19] !!! Error converting subtitles! (java?)
[07:29:19] *** Extracting audio (mplayer)...
[07:29:19] *** Extracting ac3 track #128 (deu)...
[07:29:20] *** Extracting ac3 track #129 (eng)...
[07:29:21] *** Extracting video (mplayer)...
[07:29:32] Pre-processing completed!

QUEENFAN
8th February 2013, 10:12
@paradoxical

I did some research and mencoder (the process before encoding the subtiltes) has a problem with Windows 8 Pro x64.

I don't know if this is a general problem or only affects me but I'll try to find this out.

ScottJ
1st March 2013, 05:01
The docs mention that cropping is not performed on SUP format subs. The Blu-ray disc "Mesrine: Killer Instinct" has all subs as 1920x1080 which makes it unable to move the subs inside the 2.40 picture.

Is there a way I could get BDSup2Sub to crop this format, or is there another format I could convert to (preferably without losing anything) and then import?

paradoxical
1st March 2013, 16:23
No, but bdsup2sub++ will automatically crop out the sub area if it detects such a case. This would then allow you to move them. Grab this test binary (https://www.dropbox.com/s/t955gighbz5dc0f/bdsup2sub%2B%2B102a_win32.7z) (assuming you're using Windows) if you want that capability.

mood
3rd March 2013, 06:54
it is possible save language export settings?

when export to idx/sub the language is always "english"

I have to change over and over again to spanish or portuguese because is always english.

paradoxical
4th March 2013, 19:04
No, that isn't a thing that is saved in the INI settings.

ScottJ
3rd April 2013, 00:34
Twilight: Breaking Dawn Part 2 has two forced subs at 0:52:59 that cause trouble for BDSup2Sub. (And BDSup2Sub++.)

With the original disc, when I turn on all subs, the first of the 2 forced subs is displayed simultaneously with another non-forced sub.

When BDSup2Sub loads the sup track, it gives a few warnings. When it extracts the forced subtitles, the first one comes on way too briefly.

paradoxical
3rd April 2013, 02:49
Can you post the sub file?

Guest
3rd April 2013, 14:21
Can you post the sub file? It's OK to post a fair-use fragment but not the whole thing.

Vospi
28th April 2013, 08:52
This tool saved me, it fixed corrupt idx/sub files for whole anime series so AviSynth filters now open them fine.
Thanks a lot!

urthling
5th June 2013, 21:45
Hello -

Was wondering if I could get some assistance with using the command line interface? I used to be able to specify wildcards like this:

java -jar c:\BDSup2Sub\BDSup2Sub.jar "*.sup" "output\*.sup" /res:1080 /fps:keep /movin:2.40,24

But I can't figure out how to do that with the new CLI. I can get single files to process if I specify the name manually by doing this:

java -jar c:\BDSup2Sub\BDSup2Sub.jar -r 1080 -T keep 2.40,24 -o c:\tmp\output.sup c:\tmp\input.sup

Any input would be appreciated. Thanks!

r0lZ
6th June 2013, 08:59
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.

urthling
6th June 2013, 19:55
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
7th June 2013, 08:00
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
7th June 2013, 10:04
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
7th June 2013, 20:20
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
13th June 2013, 04:45
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
18th June 2013, 16:47
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
18th June 2013, 19:27
Can you post both a flickering SUP and the corrected output of BDSupEdit? That would definitely help pinpoint what the issue might be.

CatBus
20th June 2013, 00:51
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
24th June 2013, 05:25
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
24th June 2013, 15:36
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
28th June 2013, 16:55
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
30th June 2013, 13:16
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
30th June 2013, 13:47
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
30th June 2013, 13:52
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
30th June 2013, 18:31
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
9th August 2013, 12:47
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
10th August 2013, 18:09
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
19th August 2013, 17:35
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
7th September 2013, 20:27
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
4th November 2013, 19:42
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
4th November 2013, 20:38
problem is solved

DoctorM
8th December 2013, 20:41
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
8th December 2013, 21:32
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
9th December 2013, 07:17
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
9th December 2013, 19:28
Thanks, I'll take a look.

mood
22nd December 2013, 08:18
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
25th December 2013, 15:35
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
25th December 2013, 17:20
I'm also only slightly confused on who's doing all the versions...

I am more than slightly confused! :p

mjuhasz
26th December 2013, 09:12
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
26th December 2013, 14:30
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
8th January 2014, 02:46
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
8th January 2014, 10:13
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
8th January 2014, 13:40
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
8th January 2014, 14:01
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
9th January 2014, 12:27
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
10th January 2014, 13:40
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
2nd February 2014, 19:06
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
17th February 2014, 23:52
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
18th March 2014, 16:55
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
20th March 2014, 16:53
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
25th April 2014, 12:45
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
5th May 2014, 03:12
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
27th May 2014, 09:35
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
27th May 2014, 10:04
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
27th May 2014, 12:08
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
16th July 2014, 19:37
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
20th July 2014, 05:09
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
13th November 2014, 14:02
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
7th December 2014, 00:53
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
7th December 2014, 01:24
On top of the main window, change the Output Format to XML/PNG, then export your subtitles (in an empty directory!)

newnews
12th February 2015, 14:42
Hello, I extracted the subtitle stream(BD PGS) from mkv file. Then I open the this .sup file with BDSup2Sub and save it to idx/sub. I can only see 20 lines. If I open this .sup file, I am able to see all 1300+ lines, but that software does not give option to save as idx/sub, so I still want to use BDSup2Sub. The error log while opening the sup file is:

Loading E:\Edge.of.Tomorrow\Edge.of.Tomorrow.2014.3D.BluRay.x264.DTS.track3_eng.sup
#> 1 (00:00:15.599)
#> 2 (00:00:37.621)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 2 (00:00:39.039)
#> 3 (00:00:40.791)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 3 (00:00:42.918)
#> 4 (00:00:45.003)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 4 (00:00:45.921)
#> 5 (00:00:48.006)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 5 (00:00:49.717)
WARNING: Invalid image size - ignored
WARNING: Missing PDS/ODS: last epoch is discarded
#> 5 (00:00:51.760)
#> 6 (00:00:53.053)
WARNING: Missing PDS/ODS: last epoch is discarded
#> 6 (00:00:54.847)
WARNING: <unknown> 0x50 ofs:0x0006a035
ERROR: PG missing at index 0x0006e742


Detected 0 forced captions.
WARNING: missing end time of frame 6 -> fixed
Decoding frame 1/6 at offset 0x00000108

Please advice.

igboo
24th February 2015, 04:48
Is there a way to directly edit a blu-ray pgs stream? I specifically would like to be able to add subtitles to an existing .sup.

Cheers

jpsdr
24th February 2015, 13:05
You can't "Edit" in a text way a pgs stream, because it's made of pictures, it's not text dialog lines.

DoctorM
24th February 2015, 19:20
@igboo:

1) Okay, first create an SRT file with just the new subtitles you wish to add. Make sure the timing and everything are right.
2) Use a program like goSUP to turn your new SRT file into a BD SUP file. Try to match the colors, font and positions of your old subtitles because you can't change this later.
3) In BDSup2Sub load your old SUP file and then select output as XML/PNG to a folder. Call the output something like 'Original'.
4) In BDSup2Sub load your add-on SUP file and again output and save as XML/PNG. Save them to the same folder you put the output from step 3 in and name the files something like 'ADDON'.
5) Open the OLD and ADDON .XML files in Wordpad. Copy the relevant sections of code from your addon subs into the old subs and save it under a new name keeping an .XML extension.

The pieces you are copying in the .XML should be ONLY between EVENT tags. There will be one entry for each new line you are adding. (Similarly you can delete a line between these tags.)
Don't copy anything else. So a section should look like this:
<Event InTC="00:03:09:11" OutTC="00:03:11:06" Forced="False">
<Graphic Width="575" Height="130" X="673" Y="888">ADDON_0005.png</Graphic>
</Event>

It appears each line of <EVENT> needs to be in time code order, so make sure you copy them in that way to the XML file.

6) Load the new .XML in BDSup2Sub and save it as a BD SUP file. Done.

igboo
25th February 2015, 00:34
@igboo:

Done.

:thanks:

Thanks for the detailed method DoctorM. I've been looking for a way to do this for quite a while.

I'll give it a try when I get a chance over the next several nights.

Cheers

an3k
22nd June 2015, 23:46
So I have this BD subtitle file taken directly from a Blu-ray I own. It's the german Avatar BD which contains all three editions (original cinema, extended cinema, collector's cut). https://www.dropbox.com/s/wjhkwtyzngjcjyy/00802.track_4612.sup?dl=0 This one is for the collector's cut.

When I open it with the Java version 5.1.2 it finds 1487 frames but many of them have errors like missing end time. Frame 710 has a 1920x1080 sized subpicture and its content is shown in the little preview windows in the bottom right corner (and also in both top and bottom preview windows but you have to scroll). Frame 712 also has a 1920x1080 sized subpicture but its content is NOT shown anywhere.
It is shown with these informations:screen size: 1920x1080 image size: 1920x1080 pos: (0,0) - (1920,1080) start: 01:10:01.130 end: 01:10:03.757 forced: yes

screen size: 1920x1080 image size: 1920x1080 pos: (0,0) - (1920,1080) start: 01:10:01.120 end: 01:10:03.760 forced: yes

Now I export to PNG/XML and I get 1.487 png files - one for each frame. The file for frame 710 is 1920x1080 and has actual text. The one for frame 712 is completely empty (size is the same as for frame 710 but no subtitle, just an empty picture).
If I open the XML in eg. Chrome or Notepad and jump to frame 710 I see <Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">original_0710.png</Graphic>
</Event>

Why is BDSup2Sub modifying the timings? Why differ the timings in BDSup2Sub so much from those in the XML file (which is created by BDSup2Sub)? Roughly 5 seconds! Why is the content of frame 710 shown a little bit awkward and the content of frame 712 not at all?


If I open the same file in the Qt version 1.0.2 it finds 1492 frames (because some frames are just split - frame XYZ with a duration of 1000 gets split into two frames with a duration of 500 each) but no errors at all. Frame 710 (now frame 711) is shown in the both top and bottom preview windows but not in the small in the bottom right corner. Same for Frame 712 (713).
When I export to PNG/XML I get 1.971 png files. Some frames have only one png file, some have two png files and some have 3 or more. Frame 710 (711) has two. One is 1920x1080 with the subtitle in the top left corner and one is 827x126 and contains the subtitle beautifully centered. Frame 712 (713) has also two png files in the same format and style as for 710 (711).


If I open the same file in Subtitle Edit it finds 1.487 frames, no errors at all but slightly different timings than in BDSup2Sub or the XML file. Frame 710 has 01:10:01,130 - 01:10:03,758 (duration 2,628).


If I finally open the XML file I created with BDSup2Sub Java in BDSup2Sub I again get different behavior and timings. Frame 710 is now correctly shown in all three preview windows with the following informations:screen size: 1920x1080 image size: 800x92 pos: (563,806) - (1363,898) start: 01:10:01.114 end: 01:10:03.742 forced: yes

screen size: 1920x1080 image size: 800x92 pos: (563,806) - (1363,898) start: 01:10:01.120 end: 01:10:03.760 forced: yesHowever, frame 712 cannot be shown at all.


Actually I need three tools to fix a "broken" BDsup. BDSup2Sub Java, BDSup2Sub Qt and Subtitle Edit. I use Java to create a valid XML and most png files. Qt to get the png files Java wasn't able to read/create correctly. Subtitle Edit to get the correct timings.

r0lZ
23rd June 2015, 12:24
I can perhaps explain why you have timing differences. The first reason is that BDSup2Sub re-arranges the timings to be in sync with the frames of the video stream. For example, the end time in your first example (01:10:03.757) is probably not exactly the time code of a specific video frame at 23.976fps. Therefore, it rounds it to the nearest frame, and that gives 01:10:03.760.

The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). Note the terrible syntax: 24p doesn't mean 24fps, but 23.976! You have already the example of 2 bugs: the necessity to add the options to convert the frame rate to NOT convert it, and the discrepancy in the syntax of the frame rate. But if you use BDSup2Sub.jar from the CLI, it is possible to obtain correct results. (The rounding of the time codes will occur anyway, but it's not really a bug.) I suppose that you can play with the frame rate option in the first window of the GUI to obtain the same result, but I have never tried.

I don't know why subtitle #712 is not visible. Indeed, it's a big problem. I know that some BD subtitles have special effects like fades that can confuse BDSup2Sub, and it's probably why BDSup2Sub++ generates several images instead of only one. The Java version is supposed to drop the invisible images and retain only the "best" one. Maybe there is another bug here and it keeps the fully transparent image?

I don't use Subtitle Edit with BD3D2MK3D, simply because it cannot do what I need, and anyway, most conversions cannot be done from the CLI. But I like it when I need to convert manually a text based subtitle stream to BD SUP. As far as I know, it has no bugs.

I wonder if it is justified to accuse BDSup2Sub of all problems you have had. As explained above, the timing problem is certainly a bug, but it can be solved. However, the other problems (such as the invisible subtitle or the multiple PNGs produced by the ++ version) are probably due mainly to your stream. According to the numerous error messages, that stream is seriously damaged. And that reminds me something I have discovered when I have converted Avatar 3D for the first time. At that time, BD3D2AVS (as it was called then) was using eac3to to demux the 3D MPLS. That worked well for the video and audio streams, but in some cases, it was impossible to demux the subtitles correctly. It's because in some 3DBDs (notably Avatar), the same subtitles are present with the same stream ID in the M2TS of the AVC view and in the M2TS of the MVC view. Most of the times, the subtitles are present in the AVC M2TS only, but for a reason I have never understood, there are exceptions. Since eac3to tries to demux the SSIF file (containing the AVC and MVC M2TS files joined together), it finds two different streams with the same ID, and it tries to demux them as one single stream. Of course, that cause numerous conflicts. Luckily, tsMuxeR 3D has not the same problem, and it can demux the subtitle streams correctly even in that precise case. Therefore, I suspect that perhaps the demuxer you have used may be the culprit. Anyway, if you have used eac3to, try tsMuxeR. (This apply only to the 3DBDs, but perhaps there are other problems when demuxing the 2D BDs too.)

an3k
23rd June 2015, 14:38
First of all thank you very much for feedback!I can perhaps explain why you have timing differences. The first reason is that BDSup2Sub re-arranges the timings to be in sync with the frames of the video stream. For example, the end time in your first example (01:10:03.757) is probably not exactly the time code of a specific video frame at 23.976fps. Therefore, it rounds it to the nearest frame, and that gives 01:10:03.760.Can this be turned off somehow?

The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). Note the terrible syntax: 24p doesn't mean 24fps, but 23.976! You have already the example of 2 bugs: the necessity to add the options to convert the frame rate to NOT convert it, and the discrepancy in the syntax of the frame rate. But if you use BDSup2Sub.jar from the CLI, it is possible to obtain correct results. (The rounding of the time codes will occur anyway, but it's not really a bug.) I suppose that you can play with the frame rate option in the first window of the GUI to obtain the same result, but I have never tried.I never used the CLI before but now I tried by following your advise. I ran C:\Program Files x86)\BDsup2sub>java -jar BDSup2Sub.jar --convert-fps 24p,24p --output C:\temp\temp.xml C:\00802.track_4612.sup and it created a new xml and plenty of png files. I compared the xml with the one I created with the GUI and the timings are exactly the same.
Whenever I used the GUI to load a BDsup I manually set "FPS Target" to 23.976 since it defaults to 25. BDSup2Sub.jar doesn't convert FPS when you export to BDsup but when exporting to eg. PNG/XML (I never tried the other formats) even when the "Change frame rate" checkbox is NOT checked.

I don't know why subtitle #712 is not visible. Indeed, it's a big problem. I know that some BD subtitles have special effects like fades that can confuse BDSup2Sub, and it's probably why BDSup2Sub++ generates several images instead of only one. The Java version is supposed to drop the invisible images and retain only the "best" one. Maybe there is another bug here and it keeps the fully transparent image?Even the Qt version is having problems with the BDsup and eg. frame 712. It says its position is something like -2235234,-3425634 and when I open the "Edit Frame" window a memory leak happens. It constantly uses 25% CPU and eats up RAM up to 2 GB before it finally gets closed by Windows because it doesn't "respond". However, exporting is working fine.

I don't use Subtitle Edit with BD3D2MK3D, simply because it cannot do what I need, and anyway, most conversions cannot be done from the CLI. But I like it when I need to convert manually a text based subtitle stream to BD SUP. As far as I know, it has no bugs.

I wonder if it is justified to accuse BDSup2Sub of all problems you have had. As explained above, the timing problem is certainly a bug, but it can be solved. However, the other problems (such as the invisible subtitle or the multiple PNGs produced by the ++ version) are probably due mainly to your stream. According to the numerous error messages, that stream is seriously damaged. And that reminds me something I have discovered when I have converted Avatar 3D for the first time.Well, neither BDSup2Sub++ nor Subtitle Edit is showing any errors. It's just the Java version. And I do not use the Avatar 3D, I use the 2D Blu-ray!
At that time, BD3D2AVS (as it was called then) was using eac3to to demux the 3D MPLS. That worked well for the video and audio streams, but in some cases, it was impossible to demux the subtitles correctly. It's because in some 3DBDs (notably Avatar), the same subtitles are present with the same stream ID in the M2TS of the AVC view and in the M2TS of the MVC view. Most of the times, the subtitles are present in the AVC M2TS only, but for a reason I have never understood, there are exceptions. Since eac3to tries to demux the SSIF file (containing the AVC and MVC M2TS files joined together), it finds two different streams with the same ID, and it tries to demux them as one single stream. Of course, that cause numerous conflicts. Luckily, tsMuxeR 3D has not the same problem, and it can demux the subtitle streams correctly even in that precise case. Therefore, I suspect that perhaps the demuxer you have used may be the culprit. Anyway, if you have used eac3to, try tsMuxeR. (This apply only to the 3DBDs, but perhaps there are other problems when demuxing the 2D BDs too.)I used the latest tsMuxer to extract the BDsup from the MPLS/M2TS.

I also experienced another bug. I open the original BDsup in the java version and export it as PNG/XML. The entry for the first frame is <Event InTC="00:00:39:18" OutTC="00:00:42:01" Forced="False">
<Graphic Width="1079" Height="62" X="416" Y="825">orig_0001.png</Graphic>
</Event>
Now I open that XML in BDSup2Sub.jar and export it as PNG/XML again. The entry for the first frame is now <Event InTC="00:00:39:18" OutTC="00:00:42:01" Forced="False">
<Graphic Width="1077" Height="60" X="417" Y="826">new_0001.png</Graphic>
</Event>
I also have to restart BDSup2Sub.jar (or "Close" the loaded BDsup) after exporting because otherwise it doesn't actually use the XML data but the BDsup data.

Is the Java or Qt version still maintained or if not is there any other tool which I can use to modify BDsup files?

r0lZ
23rd June 2015, 15:03
As far as I know, the development of the two versions has stopped. However, the source files are available, and it should be possible to continue to develop at least one of them, if someone is interested. It's not my case, sorry.

Thanks anyway for your comments.

I don't think that it is possible to turn off the rounding of the time codes.

The fact that the command line with the --convert-fps option gives the same result than the GUI is strange. Honestly, I don't understand. Have you verified if the frame rate in the XML is correct?

The absurd X/Y positions you've seen in BDSup2Sub++ is also a known bug of that version. And I remember I have had many problems to capture the error messages of BDSup2Sub++ (when using the CLI). It uses a strange method that redirects the messages to a window. I have reported that problem to the author, but he has assured me that it's a QT "feature", and that there is no way to use the stderr stream "normally". Anyway, it's perhaps why you can't see the error messages in the GUI. And Subtitle Edit may be much more tolerant than BDSup2Sub. I don't know.

For the difference of 1 pixel of the width and height of the bitmaps, it's probably because the subtitles are not cropped exactly the same way with the two versions. Have you verified if the width and height of the XML corresponds to the real size of the PNG?

an3k
23rd June 2015, 17:49
As far as I know, the development of the two versions has stopped. However, the source files are available, and it should be possible to continue to develop at least one of them, if someone is interested. It's not my case, sorry.Ok, maybe I'll take a look once I've finished my current project. Depends on how well the code is written. However, I'll only be able to develop the Java version since I have no clue how to do the Qt C++ stuff.

Thanks anyway for your comments.

I don't think that it is possible to turn off the rounding of the time codes.

The fact that the command line with the --convert-fps option gives the same result than the GUI is strange. Honestly, I don't understand. Have you verified if the frame rate in the XML is correct?Yes, framerate is correct in the XML. Maybe the XML/PNG specification doesn't support the time format used by BSsups (hh:mm:ss.sss) but only its own (hh:mm:ss.ss) so BDSup2Sub has to convert and thus round the times. BUT if you compare the timings of a BDsub and those of an previously extracted XML opened in another BDSup2Sub instace, the timings are identical. So either the XML spec doesn't support the more exact timings (down to 1 ms) and BDSup2Sub is aware of that and converts the timings accordingly when exporting to XML and as well when loading an XML OR this timings convertion is BDSup2Sub specific. The later would be really annoying.

The absurd X/Y positions you've seen in BDSup2Sub++ is also a known bug of that version. And I remember I have had many problems to capture the error messages of BDSup2Sub++ (when using the CLI). It uses a strange method that redirects the messages to a window. I have reported that problem to the author, but he has assured me that it's a QT "feature", and that there is no way to use the stderr stream "normally". Anyway, it's perhaps why you can't see the error messages in the GUI. And Subtitle Edit may be much more tolerant than BDSup2Sub. I don't know.[QUOTE]At least BDSup2Sub++ can export the pictures. With the help of both versions and Notepad I was able to fix my BDsup completely.

[QUOTE=r0lZ;1727459]For the difference of 1 pixel of the width and height of the bitmaps, it's probably because the subtitles are not cropped exactly the same way with the two versions. Have you verified if the width and height of the XML corresponds to the real size of the PNG?I didn't compared the two versions. I opened the BDsup in BDSup2Sub.jar and exported as XML/PNG. Then I closed the program, reopened it, loaded the previously extracted XML and exported it again. I compared these two XML versions both made by BDSup2Sub.jar. However I identified why there is a difference.
When opening a picture based subtitle file BDS2S.jar scans the pictures for non-alpha content and places that green border around it. Based on that the picture size is calculated. But BDS2S.jar leaves a 1 pixel space around the actual non-alpha content, identifying a picure as eg. 200x100. If you now export and open that exported version BDS2S.jar scans again but this time it doesn't (or maybe can't) leave a 1 pixel space around, thus identifying the same picture as 198x98. However, it correctly adjusts the position of the picture so a 200x100 picture located at 800x800 will result in a picture of 198x98 located at 801x801. The subtitle is actually at the same position.

How I repaired my broken BDsup file:

Opened the original BDsup in BDSup2Sub.jar GUI and made sure "FPS Target" is set to the correct FPS of the subtitle file.
Exported as XML/PNG to eg. C:\movie_orig\orig.xml
Opened the original BDsup in BDSup2Sub++ GUI and made sure "FPS Target" is set to the correct FPS of the subtitle file.
Exported as XML/PNG to eg. C:\movie_qt\qt.xml
Moved everything in C:\movie_qt\ into C:\movie_orig\
Opened C:\movie_orig\orig.xml in Notepad and C:\movie_qt\qt.xml in another Notepad instance.
In orig.xml I searched for each appearance of "1920" to find the malformed subtitle pictures and copied the correspoding line from qt.xml, overwriting the one in orig.xml
orig.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0165.png</Graphic>qt.xml
<Graphic Width="757" Height="125" X="587" Y="788">qt_0165_0.png</Graphic>
If qt.xml had more than one png file for a frame I had to manually check with Windows Explorer to find the correct png file.
However I also had these three entries
orig.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0710.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0712.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_1085.png</Graphic>
</Event>qt.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_0711_0.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_0713_0.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="1920" Height="1080" X="-2147483648" Y="-2147483648">qt_1089_0.png</Graphic>
</Event>
so I had to fix these too but differently than before.
Opened orig_0710.png, orig_0712.png and orig_1085.png in a simple image viewer to see if these pictures contain actual non-alpha content (subtitle text) or are 100% empty. If a picture is empty I replaced just the filename in orig.xml with the one from qt.xml. In my case only orig_0712.png is empty, thus I replaced
orig.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">orig_0712.png</Graphic>withqt.xml
<Graphic Width="1920" Height="1080" X="0" Y="0">qt_0713_1.png</Graphic>
I also checked qt_0713_0.png and qt_0713_1.png for its content. qt_0713_0.png is 567x102 but in the XML 1920x1080 is specified, thus I used qt_0713_1.png which is 1920x1080.
Saved the orig.xml and closed everything
Opened orig.xml with BDS2S.jar GUI
Checked for the three malformed frames 710, 712 and 1085 and all are correctly read by BDS2S.jar GUI but only frame 712 is not correctly placed (because neither BDS2S.jar nor BDS2S++ were able to a) write the correct position into the XML or b) write a 1920x1080 png file with the non-alpha content at its correct position).
Manually edited the frame 712 to match the position of frame 710.
Exported as XML/PNG to eg. C:\movie_final\final.xml
Opened C:\movie_final\final.xml in Notepad and checked the three malformed frames
final.xml
<Event InTC="01:09:56:22" OutTC="01:09:59:13" Forced="True">
<Graphic Width="800" Height="92" X="563" Y="806">final_0710.png</Graphic>
</Event>
<Event InTC="01:10:00:16" OutTC="01:10:02:12" Forced="True">
<Graphic Width="553" Height="69" X="686" Y="806">final_0712.png</Graphic>
</Event>
<Event InTC="01:52:34:04" OutTC="01:52:37:20" Forced="True">
<Graphic Width="561" Height="92" X="686" Y="806">final_1085.png</Graphic>
</Event>
Everything is fine now!

r0lZ
23rd June 2015, 18:45
I see. Not easy to do that manually! Maybe if you have to do that several times, you should fix the source code instead. That will tale less time! ;-)
Seriously, if you decide to work on the source, please let me know. I know also a couple of bugs related to the palette generated for the VobSub format, and I have some suggestions.
Thanks in advance!

cool_snoopy
6th July 2015, 16:52
The revolution of a dvb ts is 1920x1080.
I rip sup and idx/sub from ts with projectx, but BDSup2Sub cannot load the sup file directly, the error message is "Offset xxxx out of bound..."
After I rename the corresponding IFO file as the sup file, BDSup2Sub can load the sup file with many warnings, and the revolution is 720x576.
How to load the ripped sup file with BDSup2Sub? Or How to rip sup from dvb ts at original revolution?
Thank you very much.

Ghitulescu
8th July 2015, 08:42
The IFO is not related to the HD subtitles if this is what you wanna know. The IFO is a convenience file put there to help the future processing of the SD (standard definition) subtitles, in particular the colours.

These being said I do not go into the nasty job of asking you if you know how to extract the HD subtitles with ProjectX. I assume you know it :)

cool_snoopy
9th July 2015, 03:47
The language of TS is Traditional Chinese
Sup is ripped by PorjectX
BDSup2Sub cannot load the sup file, the error message is "Offset xxxx out of bound..."
Not only BDSup2Sub, but also BDSubEdit and SupRip cannot load the sup file
I tried several TS files, only got the same errors

Ghitulescu
9th July 2015, 12:32
I then suggest you to learn first how to extract the subtitles with ProjectX. I did and still do this and there are no problems at all.

But this is off-topic.

cool_snoopy
12th July 2015, 14:38
Allow me to describe more clear.
The subtitle is shown in traditional Chinese. It's DVB subtitle, not DVB teletext

General
ID : 1 (0x1)
Complete name : H:\v\HDJ.Last.Paradise.S5.EP01.2011.HDTV.1080i.H.264.AC3.5.1.ts
Format : MPEG-TS
File size : 2.19 GiB
Duration : 24mn 42s
Overall bit rate mode : Variable
Overall bit rate : 12.7 Mbps

Video
ID : 851 (0x353)
Menu ID : 85 (0x55)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=12
Codec ID : 27
Duration : 24mn 42s
Bit rate : 11.5 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.221
Stream size : 1.98 GiB (90%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Limited

Audio #1
ID : 852 (0x354)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 24mn 42s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1s 128ms
Stream size : 33.9 MiB (2%)

Audio #2
ID : 853 (0x355)
Menu ID : 85 (0x55)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 24mn 42s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1s 150ms
Stream size : 67.9 MiB (3%)

Text #1
ID : 855 (0x357)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : Chinese

Text #2
ID : 856 (0x358)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : English

Text #3
ID : 857 (0x359)
Menu ID : 85 (0x55)
Format : DVB Subtitle
Codec ID : 6
Language : chs


No matter which export format I select on Subtitle Setting tab, ProjectX only create sup file. If I check "additional export as VobSub", ProjectX will also create standard VobSub. I use BDSup2Sub to load the sub file, the shape looks much different with the subtitle shown during playing. I upsize it to 1280x720 and export, the exported sub is very ugly and unacceptable, this maybe because the shape looks different.
BDSup2Sub, BDSubEdit and SupRip cannot load the sup file ripped by ProjectX. SupViewer, Subtitle Edit and BDSup2Sub++ can load the entire sup file, SupRead can only load first frame, they all assume the revolution to be 720x576. Even though I check "enable HD subtitle", those softwares still assume the same revolution.
If I use BDSup2Sub to load the ripped sub, upsize it to 1280x720 and export it to sup, all the softwares above can load the entire exported sup, except SupViewer, it showes error message.

All I want to do are the following things
1. Rip sup from ts at original revolution and shape
2. Load the sup file with BDSup2Sub, downsize it to 1280x720 and export it to sub

So all I want to know is how to rip standart sup from ts at original revolution, that's why I post another thread first

foxyshadis
15th July 2015, 05:17
You already have the Sup files in original resolution, that's what it imports. BDSup2Sub converts Blu-ray subtitles to DVD subtitles, what other behavior would you expect? DVD SUB files are always DVD resolution. Only saving to Sony BDN XML will retain full resolution, after which you can batch process all the png files down to 1280x720 and convert them back to SUP.

Are you sure you wouldn't rather just convert them to text subtitles and forget the resolution problems?

DoctorM
22nd July 2015, 07:16
I was taking a look at Avatar (the 2D Collector's Edition with the 3 versions).
I found that v5.1.2 shows blank frames with "WARNING: Problems during RLE decoding of picture OBJ at offset 0x003e1c0e" for anything in the Navi font.

v5.0 and ++1.0.2 work just fine. Something has definitely gone wrong with the newer versions of BDSup2Sub.
I know this has been discussed, but is anyone looking into it?

an3k
22nd July 2015, 18:47
I was taking a look at Avatar (the 2D Collector's Edition with the 3 versions).
I found that v5.1.2 shows blank frames with "WARNING: Problems during RLE decoding of picture OBJ at offset 0x003e1c0e" for anything in the Navi font.

v5.0 and ++1.0.2 work just fine. Something has definitely gone wrong with the newer versions of BDSup2Sub.
I know this has been discussed, but is anyone looking into it?I hadn't the time yet, sorry. I'll post any news into this thread so you should subscribe to get an email ;)

DoctorM
23rd July 2015, 06:35
I hadn't the time yet, sorry. I'll post any news into this thread so you should subscribe to get an email ;)

Already am. Thanks.

Rudde
9th December 2015, 21:05
Any way to get higher resolution timestamp on the xml output?

ScottJ
9th December 2015, 23:44
Any way to get higher resolution timestamp on the xml output?

It already includes the exact frame number (the last number in the timestamp). Can't get any higher resolution than that.

r0lZ
10th December 2015, 10:04
Yes, the timecodes in the XML are in the form HH:MM:SS:FF, where FF is a number of frames, not a fraction of a second. There is no way to be more precise than that.

However, the timecodes displayed in the GUI, are in the form HH:MM:SS.sss, where SS.sss is a floating point. And IMO it is extremely difficult to understand what BDSup2Sub does when it converts the input frame rate to the frame rate displayed in the GUI. Usually, they do not match at all. And it's not simply a precision problem. There is obviously a bug here, but increasing the precision will not fix it.

For example, if the XML timecode is 01:27:38:11 at 23.976fps, the frame number is 5258 seconds * (24/1.001) + 11 = 126077. Converted back to a timecode, still at 23.976fps, that gives 126077 / (24/1.001) = 5258.4617 seconds = approximately 01:27:38.462. But in the GUI, the time code displayed is 01:27:43.716 !!! It is obviously completely wrong ! It seems that BDSup2Sub does ALWAYS a framerate conversion, even when that option is not enabled.

Anyway, we have to live with that terrible bug, since BDSup2Sub is not developed any more.

Rudde
10th December 2015, 16:49
I didn't know the last FF was frame, and it seems to be difficult to convert to srt compatible format since it also does not extract fps correctly.

I did really try to parse the BDsup myself but I'm quite stuck on it because there is literally no complete documentation on it and it's so frustrating. I'm trying to make an online recourse for OCR and QA of BD (and hopefully DVD and HDDVD too some day) and make it crowdsourced.

Also; will FF = 01 be the first frame as the defined second?

r0lZ
10th December 2015, 17:00
No, I think that the first frame is 00. In other word, at 25 fps (PAL), FF is between 00 and 24.

Not sure what you mean with "it also does not extract fps correctly". IMO, the fps is correct in the XML. It's when it loads the XML that the frame rate is wrong. I think it assumes always 25 fps, instead of the fps in the header of the XML, although it displays correctly the source FPS in its first window. I suppose that this bug should be easy to fix. What you want to do is much more complicated.

Good luck anyway.

Rudde
11th December 2015, 12:24
So I ran 3 BD sups trough it now, one 24/1.001 fps, 24 and 25 fps and the xml reports the correct playback time played back at original framerate but it always report 25 fps i XML, that will be significantly off by last caption on 24/1.001 fps but yet insignificant if you only use the FF data as frame accurate.

r0lZ
11th December 2015, 12:32
Sorry, I don't understand. What do you mean with "but it always report 25 fps i XML" ?

Rudde
11th December 2015, 12:37
Sorry, I don't understand. What do you mean with "but it always report 25 fps i XML" ?

In the XML you have this line

<Format VideoFormat="1080p" FrameRate="25" DropFrame="False"/>

It will be FrameRate="25" regardless of the actual frame rate.

r0lZ
11th December 2015, 12:49
Ah, OK. I didn't know that. In BD3D2MK3D, when an XML is created from a SUP at 23.976 fps, the real output frame rate is specified in the command line, and it is correctly written in the XML. But it seems that BDSup2Sub considers it still as 25 fps.

Anyway, your finding confirms that there is a very big bug here. Not sure if the same bug exists with other formats (BD SUP or DVD VobSub).

Kez
17th March 2016, 18:51
<snip>The big differences in timings you have noticed when converting to XML/PNG is probably due to a bug in the GUI and/or command line. I don't use the GUI often and therefore I can't be sure, but I know that you have to specify the input and output frame rate when you use the command line, as otherwise BDSup2Sub does a conversion (probably to 25 fps) anyway! The correct option for the java version and for a BD@23.976fps is --convert-fps 24p,24p (or --fps-source 24p --fps-target 24p for the ++ version). <snip>

I can confirm the bug also exists in the GUI where you have to set the target frame rate to avoid a conversion to 25fps which it defaults to on every start up. The input frame rate seems ok though and always matches source in my experience. YMMV

As for a command line option to work around the bug, you are better off using --fps-target keep on either the CLI or on the shortcut icon command line. This ensures that the target frame rate matches the source, just in case you load a non 23.976 fps sup...

-kez

r0lZ
17th March 2016, 20:19
Welcome to the Doom9 forums, Kez.
Thanks for the confirmation ant the --fps-target keep hint.

Kez
18th March 2016, 21:10
Thanks for the welcome r0lZ.

One question:
Does anyone know if BDSUP2SUB and the ++ version are in sync in terms of bugfixes and features?
Obviously I'd like to use whichever one is more up-to-date in that regard, but it wasn't exactly clear to me from the info on GitHub.

Thanks!

r0lZ
18th March 2016, 21:27
Some bugs are present in both versions (the frame rate of the XML/PNG and the badly built palette when converting to DVD SUB for example). But IMO, the java version is better. The ++ version has at least one additional bug. When a BD SUP is converted to XML/PNG, some subtitles are converted as several pictures instead of only one, and some of them are totally black. The converted XML stream cannot be reloaded in BDSup2Sub++ itself ! Also, the development of the ++ version has been very rapid and promising, but has stopped abruptly after only a few months. Therefore, it has not been tested as extensively as the java version. However, when the ++ version works fine, I prefer it. It is much more rapid, and it doesn't require the overhead of java. But personally, I use almost always the java version, for security purpose.

Note also that the syntax of the command line is somewhat different for the two versions.

LigH
19th December 2016, 11:03
Documentation
The complete documentation is available from the help menu inside the application. You can also read it online (http://bdsup2sub.javaforge.com/help.htm).

Unfortunately, this link is forwarded to https://codebeamer.com/cb/wiki/938267help.htm now, and anonymous reading is not allowed here, you need to create an account before even reading.

Is this tool able to batch-edit palette entries of subtitles in a Blu-ray SUP stream (e.g. set the opacity of the background of all subtitles in this stream to 0) and save the result in the same format?

r0lZ
19th December 2016, 13:29
I don't think so. Personally, for this kind of job, I convert the SUP to XML/PNG with BDSup2Sub (java version), then I batch-edit the PNG files with Image Magick or a good image editor (with batch support of course), and finally I recreate a new SUP from the edited XML/PNG, again with BDSup2Sub.

Take care! BDSup2Sub assumes ALWAYS 25 fps by default when it reads a XML/PNG stream, so be sure to specify that you want to convert the FPS from 23.976 to 23.976 fps in the little window that appears when you load the XML. That seems stupid, but it's the only workaround for that nasty frame rate bug.

Ghitulescu
19th December 2016, 14:45
The question above was intended on my behalf, as not receiving any answer here for a long time, I also asked it in the German forum. Apparently proper handling of subtitles never was a hot issue here.

This is actually what I did, demuxing into elementary bitmaps, editing them, then recomposing them back. The author suggested to go by DVD subs, where such editing tools exist, then converting them back to BD subs.

But thanks for the tip concerning BDSupToSub and 25fps, I never noticed it, maybe because I muxed directly the XML+PNG in tsmuxer.

r0lZ
19th December 2016, 14:57
Yes, editing the colors or transparency of DVD subs is easy, but it is a pity to have to reduce the colors to 4 and the transparency to 16 levels and lose the quality of the original BD SUP just to edit it!

For the frame rate bug, afaik it happens only when BDSup2Sub (java or ++) loads the XML/PNG stream, regardless of the frame rate included in the XML file. But I use the FPS conversion trick anyway, even when I load another format, just to be sure. With that trick, I have never experienced any sync problem.

Bandits
25th December 2016, 05:18
Yes, the timecodes in the XML are in the form HH:MM:SS:FF, where FF is a number of frames, not a fraction of a second. There is no way to be more precise than that.

However, the timecodes displayed in the GUI, are in the form HH:MM:SS.sss, where SS.sss is a floating point. And IMO it is extremely difficult to understand what BDSup2Sub does when it converts the input frame rate to the frame rate displayed in the GUI. Usually, they do not match at all. And it's not simply a precision problem. There is obviously a bug here, but increasing the precision will not fix it.

For example, if the XML timecode is 01:27:38:11 at 23.976fps, the frame number is 5258 seconds * (24/1001) + 11 = 126077. Converted back to a timecode, still at 23.976fps, that gives 126077 / (24/1001) = 5258.4617 seconds = approximately 01:27:38.462. But in the GUI, the time code displayed is 01:27:43.716 !!! It is obviously completely wrong ! It seems that BDSup2Sub does ALWAYS a framerate conversion, even when that option is not enabled.

Anyway, we have to live with that terrible bug, since BDSup2Sub is not developed any more.

I thought the time codes were:

FF - milliseconds
0 - 000
1 - 040
2 - 080
3 - 120
4 - 160
5 - 200
6 - 240
7 - 280
8 - 320
9 - 360
10 - 400
11 - 440
12 - 480
13 - 520
14 - 560
15 - 600
16 - 640
17 - 680
18 - 720
19 - 760
20 - 800
21 - 840
22 - 880
23 - 920
24 - 960

I could be wrong but its always worked for me. I seem to remember testing by exporting and importing using the above conversion and the times remained correct.

Edited typo on numbering.

I always use --fps-target keep and the above numbers work for all FPS.

r0lZ
25th December 2016, 11:50
@Bandits: There is a bug in your list of time codes. Frame 15 is missing, For 25fps, if the first frame is frame 0, frame 24 is the last frame in the same second, not frame 25.

And anyway, your timings are correct only for PAL at 25fps. BDSup2Sub is always correct when it deals only with streams at 25fps, since it's the frame rate that it assumes (wrongly) always. The bug happens only when it loads streams at other frame rates (film at 24fps, NTSC at 23.976 or 29.97fps or other exotic frame rates), if you don't specify explicitly to convert the frame rate to itself.

DMD
22nd February 2017, 08:58
Good morning
I ask if you can include the subtitle management 4K resolutions.

Thank you

hubblec4
25th April 2017, 11:19
When I use the cli (BDSup2Sub 5.1.2) to convert a DVD-sup to IDX/Sub and I use the "--language de" switch or any other language code, always "English en" is set in the idx for the language.
Is this a known bug?

r0lZ
25th April 2017, 11:47
It works fine for me, and I use the same version.

My command is:

java -Xmx256m -jar D:\work\BD3D2MK3D\toolset\BDSup2Sub.jar test.sup -o test\test.xml --language de


There are some bugs in BDSup2Sub, especially with the XML+PNG format. For example, the frame rate is systematically 25 fps when converting from XML+PNG to another format (with the CLI or the GUI), unless you specify explicitly another frame rate. But as far as I know, the language code is correctly handled.

Note also that BDSup2Sub supports only the ISO 639-1 codes (2 lower case letters). It doesn't support more recent ISO codes (with 3 or 4 letters). But since you have used "de", that should work. Are you sure that the --language argument is after the input and output file names?

hubblec4
25th April 2017, 15:19
My command is:

java -Xmx256m -jar D:\work\BD3D2MK3D\toolset\BDSup2Sub.jar test.sup -o test\test.xml --language de

Are you sure that the --language argument is after the input and output file names?

In the usage-description there are "options" before the in-out files.
I try it with --language at last position and it does not work.
With the Windows version it works but not with the java-version.

"C:\java.exe" -jar "D:\BDSup2Sub.jar" "F:\Subpictures_23.ifo" -o "F:\Sub Pic23.sub" --language aa


here a sample (http://forum.gleitz.info/attachment.php?attachmentid=99341&d=1493129925)

r0lZ
25th April 2017, 15:36
Oh, yes, with your sample, I can reproduce the bug. The difference is that in my previous tests, I've used a BD SUP file. You convert a DVD SUP file (+IFO).

I did not know that problem, but anyway, we have to live with it. Luckily, if you convert to XML+PNG, it is easy to edit the XML file to change the language code. I don't think there is another solution.

And take care with BDSup2Sub++.exe. It has a lot of bugs, even if it doesn't have this one! And it is abandoned too.

hubblec4
25th April 2017, 18:36
Oh, yes, with your sample, I can reproduce the bug. The difference is that in my previous tests, I've used a BD SUP file. You convert a DVD SUP file (+IFO). Yes DVD-sup!


I did not know that problem, but anyway, we have to live with it. Luckily, if you convert to XML+PNG, it is easy to edit the XML file to change the language code. I don't think there is another solution.
In my old DVD2mkv-editor I have created a workaround for this bug, but for german langauge only. Now I see every language fails and I will extend my work-around. It is a very simple procedure which change the "id: entry"(and "alt: entry") in the idx-file.

I hope this is enough to solve this issue.



And take care with BDSup2Sub++.exe. It has a lot of bugs, even if it doesn't have this one! And it is abandoned too.

Is there a list of this known bugs?
Like in your PGC2mkv-plugin I would have the choice between this two versions.

r0lZ
25th April 2017, 19:33
I don't think there is a complete list, but I know that in many cases, when it converts a BD SUP to XML+PNG, it creates several images for the same subtitle, and some are totally black. It cannot reload the XML it has produced itself! (I think that that bug occurs when there are fades in the subtitle stream. Something very rare, if not impossible, for the DVD SUP, so don't worry too much.)

It has also the bugs of the java version, including the problem of the wrong time codes when it loads an XML/PNG stream. It forces 25 fps anyway.

hubblec4
25th April 2017, 19:50
Why convert you to XML/PNG? This step I have never used.

I have no problems with converting dircet to idx/sub.

r0lZ
25th April 2017, 22:47
For most users, the main advantage of XML/PNG is that it is easy to edit, for example to darken too bright subtitles. Personally, I need that format for BD3D2MK3D, to convert the subtitles to 3D (SBS or T&B). It's also a format needed to import the subtitles in some authoring programs.

Bandits
28th April 2017, 20:54
Is there a list of this known bugs?

I know I have had issues with 5.1.2 with detecting all subtitle events (Avatar). I have reverted back to 4.0.0 and it seems to be the best for my needs.

If I could understand the subtitle events a little better inside the extracted stream I would write my own editor. I tried to follow the information in this thread and SUPread but it seems to be incomplete. I can get the event information but extracting the png does not make sense to me.

Scorpius666
16th July 2017, 00:13
Thanks to this wonderful thread I have found that versions of BDSup2Sup higher than 5.0.0 will lose 15% of the subtitles (totally unusable), but versions 5.0.0 and lower will only lose 1% if any.

Since it still loses a couple of subtitles, I have decided to implement one of the two things missing in BDSub2Sup that makes it lose subtitles.

Basically BDSup2Sub didn't implement two things:

Complex compositions. This is when two or more subtitles are shown at the same time. A warning is shown that multiple ODS are defined and only one subtitle will be recognized.
Cropping. BluRay subtitles support showing a piece of the image each time, so a line like "Ok! Let's do it" can be shown like "Ok!" first and then "Ok! Let's do it".


The second item is not that terrible. You will only lose the "animation" of the subtitle being shown few words at a time.

But the first item is a big problem. This usually happens when a subtitle is being shown and then another one has to appear, for example a foreign sign have appeared in the screen and the person hasn't finished talking. Since compositions are very common they must be implemented.

So that's what I did here: https://github.com/naikel/BDSup2Sub/tree/enhanced

Also I tried to give a better explanation how PGS works here: http://blog.thescorpius.com/index.php/2017/07/15/presentation-graphic-stream-sup-files-bluray-subtitle-format/

Bandits
16th July 2017, 00:48
Thanks for working on this. Do you have any examples besides Avatar I can test your version on? I use BDSup2Sub heavily when dealing with forced subtitles and would like to know I can trust your version to be as good as 4.0.0. I got burned using 5.1.2 and had to re-rip many movies.

Thanks also for providing some more information to make my head hurt trying to understand the segments in the stream.

Scorpius666
16th July 2017, 03:39
Do you want a SUP file that will give you problems in 4.0.0 and work with this version?

Any anime BluRay will cause that since it has to compose several subtitles at the same time trying to translate everything that is on screen.

But anyway here's a 20 kB SUP file with a simple composition: two subtitles, one is shown first, then both, then only the second. This is from a real BluRay. Load this with my version first and double click the little screen or use Edit -> Edit Frame and take a look at the three frames so you can see how they are supposed to look in the movie.

Then load it in 4.0.0 and do the same.

If the attachment is not approved download it from here: https://www.dropbox.com/s/meensn9ow4vbsu8/Sample.sup?dl=0

r0lZ
16th July 2017, 08:45
Thanks Scorpius666, and welcome to the D9 forums! I'm glad to see that BDSup2Sub is not dead.

Can you also have a look at a bug? When BDSup2Sub converts a DVD or BD subtitle stream to XML/PNG format, it writes 25 fps anyway in the XML file, regardless of the frame rate of the original stream, and when an XML is read, the frame rate is ignored, and BDSup2Sub assumes always 25 fps (unless you force manually another input frame rate with the dialog that is shown when the XML file is opened). In other words, by default, BDSup2Sub assumes that an XML/PNG file is always at 25fps. It's obviously a bug, as by default, it should never change the frame rate when loading or converting a stream. (I don't remember if loading other formats has the same problem, but that should be verified too.)

There are probably other small bugs, but I don't remember right now.

Thanks in advance!

LeXXuz
16th July 2017, 10:36
Thanks to this wonderful thread I have found that versions of BDSup2Sup higher than 5.0.0 will lose 15% of the subtitles (totally unusable), but versions 5.0.0 and lower will only lose 1% if any.


Thank you very much for your efforts. :thanks:

I have used 5.1.2 for quite a long time and always had the feeling something is off. Now I know I have a lot of faulty backups. Should have read through this thread earlier... :(

Anyhow I will test your version with quite a few files I know for sure version 5.x and 4.x handled wrong. Thx again. :)

Scorpius666
16th July 2017, 17:19
Thanks Scorpius666, and welcome to the D9 forums! I'm glad to see that BDSup2Sub is not dead.

Can you also have a look at a bug? When BDSup2Sub converts a DVD or BD subtitle stream to XML/PNG format, it writes 25 fps anyway in the XML file, regardless of the frame rate of the original stream, and when an XML is read, the frame rate is ignored, and BDSup2Sub assumes always 25 fps (unless you force manually another input frame rate with the dialog that is shown when the XML file is opened). In other words, by default, BDSup2Sub assumes that an XML/PNG file is always at 25fps. It's obviously a bug, as by default, it should never change the frame rate when loading or converting a stream. (I don't remember if loading other formats has the same problem, but that should be verified too.)

There are probably other small bugs, but I don't remember right now.

Thanks in advance!

That is not a bug. Sadly, there is no frame rate information in a SUP file, and the user always have to introduce that information manually before exporting.

sneaker_ger
16th July 2017, 17:44
Are subtitle timings on DVD or Blu-ray always bound to frame timings? Then - since DVD and Blu-ray only allow certain constant frame rates - we could deduct fps by looking if the subtitle timings would fit into a matching pattern.

Scorpius666
16th July 2017, 18:15
Are subtitle timings on DVD or Blu-ray always bound to frame timings? Then - since DVD and Blu-ray only allow certain constant frame rates - we could deduct fps by looking if the subtitle timings would fit into a matching pattern.

There are two ways to time a subtitle:

1.- Absolute time: Like the SUP files have, or text SRT files have. That is from 00:00:51.128 to 00:00:55.762. That's absolute. You don't need a frame rate for that since you know exactly when to show the subtitle.

2.- Relative time: A frame rate + frame number. For example from frame #2510 to frame #2650. If your frame rate is wrong, then your subtitle will show at the wrong time.

Since SUP files have absolute time, they don't need a frame rate, and this value is simply not included since it's not necessary. Also, normal text SRT files don't include this value either: it's not needed. Now the weird thing here is that those XML files also have absolute time, and they have a frame rate value I don't know why. I would assume the players would ignore the frame rate value in the XML file. I haven't tested that (I don't use that format).

Now since SUP files from BDs and DVDs don't have a frame rate value, BDSup2Sub takes the default value you have for frame rate. If you haven't changed it, it's 25. But you can change it and press the "Store" button to set a new default. But BDSup2Sub can't possibly know the frame rate of the movie since that information is not inside the SUP file.

r0lZ
16th July 2017, 18:20
I've just tried again, and there is obviously a problem, but it's not exactly what I have described above. Currently, if I load a BD Sup in BDSup2Sub v5.1.2, it shows (correctly) 23.976fps in the first dialog as the FPS Source. The "Change frame rate" option is NOT ticked, and the user can therefore assume that it will use 23.976 when exporting the stream to another format, but it's NOT the case! It will use 25fps. In fact, it uses the Target FPS specified in that dialog anyway, even if the Change Frame Rate option is not ticked. So, to keep the original (good) fps, you MUST change the FPS Target option. The "Change Frame Rate" option is only used to force a different FPS Source, not to maintain the original frame rate during the conversion. If it's not a bug, it's totally misleading.

I suggest therefore to set by default the FPS Target to the same value as the FPS Source. If the user wants to change the frame rate, he should do it, but it's not the role of the program to assume that he want to convert to 25fps. (And why 25fps BTW?) Imo, it's really something to fix.

If the source frame rate cannot be determined, then I suggest to print a red warning in this first dialog to ask the user to change the FPS Source and target as necessary. And the text of the "Change frame rate" option should be replaced with "Change FPS Source", to be more clear.

sneaker_ger
16th July 2017, 18:32
There are two ways to time a subtitle:

1.- Absolute time: Like the SUP files have, or text SRT files have. That is from 00:00:51.128 to 00:00:55.762. That's absolute. You don't need a frame rate for that since you know exactly when to show the subtitle.

2.- Relative time: A frame rate + frame number. For example from frame #2510 to frame #2650. If your frame rate is wrong, then your subtitle will show at the wrong time.

Since SUP files have absolute time, they don't need a frame rate, and this value is simply not included since it's not necessary. Also, normal text SRT files don't include this value either: it's not needed. Now the weird thing here is that those XML files also have absolute time, and they have a frame rate value I don't know why. I would assume the players would ignore the frame rate value in the XML file. I haven't tested that (I don't use that format).

Now since SUP files from BDs and DVDs don't have a frame rate value, BDSup2Sub takes the default value you have for frame rate. If you haven't changed it, it's 25. But you can change it and press the "Store" button to set a new default. But BDSup2Sub can't possibly know the frame rate of the movie since that information is not inside the SUP file.
What I meant by "bound to frame timings" is: will subtitles only start/end if a video frame starts? That could be true even with absolute subtitle times (in e.g. seconds). If you have an absolute time of 00:00:00.040 you know it must be from 25 fps video:
1000ms/25 = 40ms
1000ms/23.976 = 42ms
1000ms/29.97 = 33ms
(may have to gather statistics over whole file to safely differ between 24 and 23.976 or 25 and 50 but you get the idea)

About why XML has both: I'm too lazy to look now but could it be because of "drop" and "non-drop" timings?
https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=D%26section=6%26tasks=true

Scorpius666
16th July 2017, 18:42
I've just tried again, and there is obviously a problem, but it's not exactly what I have described above. Currently, if I load a BD Sup in BDSup2Sub v5.1.2, it shows (correctly) 23.976fps in the first dialog as the FPS Source. The "Change frame rate" option is NOT ticked, and the user can therefore assume that it will use 23.976 when exporting the stream to another format, but it's NOT the case! It will use 25fps. In fact, it uses the Target FPS specified in that dialog anyway, even if the Change Frame Rate option is not ticked. So, to keep the original (good) fps, you MUST change the FPS Target option. The "Change Frame Rate" option is only used to force a different FPS Source, not to maintain the original frame rate during the conversion. If it's not a bug, it's totally misleading.

I suggest therefore to set by default the FPS Target to the same value as the FPS Source. If the user wants to change the frame rate, he should do it, but it's not the role of the program to assume that he want to convert to 25fps. (And why 25fps BTW?) Imo, it's really something to fix.

If the source frame rate cannot be determined, then I suggest to print a red warning in this first dialog to ask the user to change the FPS Source and target as necessary. And the text of the "Change frame rate" option should be replaced with "Change FPS Source", to be more clear.

It is exactly that.

If you select the "Change Frame" option then you will need to enter a source frame rate and the program will translate the times for you. If you don't, the Target FPS is still used only for the formats that will use it.

But if you export to IDX/SUB for example that is totally ignored since it is not needed.

The question remains: Why is there a frame rate setting in the first place for formats that have absolute time? I'm pretty sure if you delete the frame rate line from the XML file it will always work. I would test it, but that format is so messy creating thousands of files that I really want to stay away from it.

Also, the ONLY format that BDSup2Sub that needs a frame rate is XML/PNG. What I would do is test an XML file without the frame rate option, and if it works, then delete the output of that line in BDSup2Sub. I'm sure it will work!!

What I meant by "bound to frame timings" is: will subtitles only start/end if a video frame starts? That could be true even with absolute subtitle times (in e.g. seconds). If you have an absolute time of 00:00:00.040 you know it must be from 25 fps video:
1000ms/25 = 40ms
1000ms/23.976 = 42ms
1000ms/29.97 = 33ms
(may have to gather statistics over whole file to safely differ between 24 and 23.976 or 25 and 50 but you get the idea)

About why XML has both: I'm too lazy to look now but could it be because of "drop" and "non-drop" timings?
https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=D%26section=6%26tasks=true

It depends on the format. SUP files are not bound by frames, they will show when the time is right. I don't remember which formats use the frame number instead of an absolute time right now but they are long gone. Popular bitmap formats like PGS (SUP), VobSub(IDX/SUB) and text formats like SRT, SSA, ASS, etc they all use absolute time values. None of them use a frame rate value in their files at all.

EDIT: Reading the wiki at https://github.com/mjuhasz/BDSup2Sub/wiki/Supported-Formats seems like not only the frame rate value is needed, but the values are not absolute values but things that are really weird, like the time codes are related an integer frame rate (24 instead of 23.976). I would really stay away from this format.

r0lZ
17th July 2017, 10:32
It is exactly that.

If you select the "Change Frame" option then you will need to enter a source frame rate and the program will translate the times for you. If you don't, the Target FPS is still used only for the formats that will use it.
It's almost true. The Target FPS is used anyway, regardless of the format of the input or output stream, but the stream is not stretched or shrunk. The only change is that the output timings are rounded so that they will coincide exactly with the frames of a movie at the specified target FPS. In other words, if you save the stream, it will still be more or less compatible with the original movie, but with imprecise time codes. And it will NOT be equal to the original. The difference might be negligible, but it exists. For example, a subtitle at 01:37:20.418 will be (slightly) moved to 01:37:20.400. A difference of 18ms is not much, but it exists. (You can see the rounded timecodes in the lower pane of BDSup2Sub.) It's why I suggest, when the stream is loaded, to set by default the same Target FPS than the source FPS (detected usually correctly, even when a format without FPS is loaded). That way, by default, the timings will never be changed. Plus, for the formats using the FPS (like XML/PNG), the correct value will be included. Currently, you have to pay attention to the Target FPS, without any good reason. Why keep this obligation if it can be avoided simply?

But if you export to IDX/SUB for example that is totally ignored since it is not needed.No, it's important to have the correct frame rate stored in the XML, because if you save it with, say, 25fps, when you will reload it, the program will wrongly assume that the FPS Source is 25. So, the current behaviour is misleading, unless you fix manually the little discrepancy of the wrong FPS Target in the first window.

The question remains: Why is there a frame rate setting in the first place for formats that have absolute time? I'm pretty sure if you delete the frame rate line from the XML file it will always work. I would test it, but that format is so messy creating thousands of files that I really want to stay away from it.
IMO, it's an excellent thing to tag the stream with the frame rate. I agree that that should not influence the absolute times (except for the rounding to exact frame starts), but don't forget that a subtitle stream has no interest at all without a movie, and the movie has a specific frame rate. The timings for a PAL movie are totally different than for the same movie in NTSC, and again different for a film at 24fps. When the frame rate is included in the stream, you know for what target frame rate the stream has been designed. It's an extremely important information. Most sync problems peoples are experiencing with downloaded subtitles come from the absence of the frame rate in the SRT format. At least, with XML/PNG, that problem is avoided... if the frame rate stored in the XML is correct, of course.

Also, the ONLY format that BDSup2Sub that needs a frame rate is XML/PNG. What I would do is test an XML file without the frame rate option, and if it works, then delete the output of that line in BDSup2Sub. I'm sure it will work!!
Yes, it will probably work, but please don't do that. Despite what you think about the XML/PNG format, it's certainly the more professional format supported by BDSup2Sub. It is extremely interesting to modify some things that you can't do with the GUI. I use it in BD3D2MK3D, for example, to convert the subtitles to 3D Half-SBS or Half-T&B. The presence of the frame rate tag in the XML is really useful to verify that the stream is compatible with the movie. Note also that XML/PNG is the format necessary for many authoring programs, like Sonic or Scenarist. You cannot simply say that it is useless because you don't like it.

However, I agree that it saves a lot of PNG files. And currently, it doesn't force the user to create a new directory to keep all these files together. Perhaps you could add (as an option?) the automatic creation of a sub-directory when the XML is saved? That way, you won't need to pay attention to where you save it. It's just a suggestion...

EDIT: Reading the wiki at https://github.com/mjuhasz/BDSup2Sub/wiki/Supported-Formats seems like not only the frame rate value is needed, but the values are not absolute values but things that are really weird, like the time codes are related an integer frame rate (24 instead of 23.976). I would really stay away from this format.
Oh, yes, I hate also the problem of the drop or non-drop frames with all NTSC frame rates, but it's an inheritance of the crappy NTSC Video format, and we have to live with that. (And, BTW, I don't understand at all why the US has forced the rest of the world to use the infamous 23.976 frame rate for HD and 3D movies, instead of the film standard of 24 fps, much more simple and without the drop frame nightmare! After all, we are in the 21st century, and keeping obscure limitations inherited from the frequency of the US AC at 110v is completely hallucinating!)

Also, if currently, most (if not all, I don't know) timings internal to video, audio and subtitles streams are expressed in absolute and precise times (for their real frame rate), it's not at all the same thing in production, where precise time codes are not handy. They HAVE to be rounded at 24 fps, because we are human beings, and not machines. The fact that XML/PNG permits to use drop or non-drop times is complex, but that means only that that format has been correctly designed with video production and human beings in mind. It's one of its obvious advantages over the other formats. I haven't tried to change the DropFrame="False" option in the XML, but I suppose that it is there to support both drop and non-drop frames timecodes. If it's the case, it should be possible to use exactly the same time codes in the XML than with the other formats.

Of course, when an XML/PNG file is saved at 24 or 25 fps (or any integer FPS), the drop frames problem is totally absent, and XML/PNG can be used very simply.

r0lZ
17th July 2017, 10:57
Now since SUP files from BDs and DVDs don't have a frame rate value, BDSup2Sub takes the default value you have for frame rate. If you haven't changed it, it's 25. But you can change it and press the "Store" button to set a new default.
The Store button doesn't work for me. The default FPS Target is always 25.

Thanks to this wonderful thread I have found that versions of BDSup2Sup higher than 5.0.0 will lose 15% of the subtitles (totally unusable), but versions 5.0.0 and lower will only lose 1% if any.
So, if I understand correctly, your version is based on the code of v5.0.0. Right?

Are there other changes in later versions (except the problem of the missing subtitles) that have not been ported to your version, or is your version totally compatible with v5.1.2? I use v5.1.2 with BD3D2MK3D, and I would like to replace it with your version, but I don't want to risk some incompatibilities. Can you breifly summarize the changes that your version has not implemented, or direct me to the history of the changes of the old BDSup2Sub?

Scorpius666
17th July 2017, 16:32
I based my version from 5.0.0. There are a lot of changes in later versions I guess, but those versions don't really work well. You would have to go to github and read each commit one by one after 5.0.0 to see what was implemented/fixed. They are a lot: https://github.com/mjuhasz/BDSup2Sub/commits/master

I tried to fix 5.1.2. I really tried. But it was so messy with so many errors that I picked the last version that worked (5.0.0) and started from there.

Also I'm wondering what's the use you guys have for this software. Nowadays you can mux a SUP file into an MKV container, so you don't really need to convert SUP to anything else. In my specific use case, I want my MKVs untouched for several reasons and the subtitles external. SUP files can't be external files, they only work when they are inside of a container like MKV. But if I wouldn't mind to modify my MKVs, I would just put the SUPs inside of them, and there wouldn't be a need for BDSup2Sub.

r0lZ
17th July 2017, 18:43
Thanks for the link. I'll have a look...

I agree that untouched BD SUP muxed in MKV is the best solution... if your standalone player or TV supports that format.
Personally, as I wrote above, I distribute BDSup2Sub with BD3D2MK3D (a GUI to convert 3D BDs to SBS or T&B MKVs). It is necessary to convert the 2D subtitles to 3D. The resize and combinations of the 2 views with the correct offset can only be done on XML/PNG streams, hence my interest for that format. But XML/PNG is used only to compose the images of the final 3D stream, that is finally re-converted to BD or DVD SUP format.
BDSup2Sub is also used to extract the forced subtitles from the full stream. It's necessary for MKV, because most players are unable to dynamically display only the forced subs of a stream.

QBhd
17th July 2017, 18:47
My use for this software is pretty simple... when I remux BDs to MKV I only keep the subs for foreign/alien dialogue. And as we all know, many BD authors do different things to achieve this. I use this software to see what each sub track contains and see what is forced.

QB

Scorpius666
17th July 2017, 19:25
My use for this software is pretty simple... when I remux BDs to MKV I only keep the subs for foreign/alien dialogue. And as we all know, many BD authors do different things to achieve this. I use this software to see what each sub track contains and see what is forced.

You could use Subtitle Editor for that, but it has the same problem than the original BDSub2Sup: It misses several subtitles when importing from a SUP file.

Thanks for the link. I'll have a look...

I agree that untouched BD SUP muxed in MKV is the best solution... if your standalone player or TV supports that format.
Personally, as I wrote above, I distribute BDSup2Sub with BD3D2MK3D (a GUI to convert 3D BDs to SBS or T&B MKVs). It is necessary to convert the 2D subtitles to 3D. The resize and combinations of the 2 views with the correct offset can only be done on XML/PNG streams, hence my interest for that format. But XML/PNG is used only to compose the images of the final 3D stream, that is finally re-converted to BD or DVD SUP format.
BDSup2Sub is also used to extract the forced subtitles from the full stream. It's necessary for MKV, because most players are unable to dynamically display only the forced subs of a stream.

Haven't you thought about writing your own SUP parser inside BD3D2MK3D? It's very simple, and I posted a link some posts ago with the format specifications.

r0lZ
18th July 2017, 07:59
Haven't you thought about writing your own SUP parser inside BD3D2MK3D? It's very simple, and I posted a link some posts ago with the format specifications.
Oh, well, perhaps I'll do it, but I don't want to re-invent the wheel. BD3D2MK3D is essentially a GUI, and it uses already a lot of free tools, including BDSup2Sub. Why should I replace it with my own code and not, say, tsMuxeR, Mkvmerge, FRIMSource or x264, also necessary?
But I agree that currently, the conversion to 3D is slow and may be faster if I write the parsing combined with the conversion to 3D myself. However, I'm not sure it is worth doing it. The 3D is slowly dying, BD3D2MK3D is mature and stable, and I don't have the intention to modify it deeply any more.

But perhaps YOU are interested in adding the conversion to 3D inside BDSup2Sub ? If it's the case, I can help you. I know how the images must be combined, how to retrieve the 3D offsets from the so called 3D-Planes (or from the SEI messages of the MVC video stream), and the resize of the bitmaps is already present in BDSup2Sub. IMO, that could be a valuable addition to BDSup2Sub, as currently, as far as I know, there is no subtitle editor or converter that is able to convert the subtitles to 3D, at least with the correct 3D offsets from the original BD. If you're interested, just let me know...

Bandits
29th July 2017, 17:02
Also I'm wondering what's the use you guys have for this software. Nowadays you can mux a SUP file into an MKV container, so you don't really need to convert SUP to anything else. In my specific use case, I want my MKVs untouched for several reasons and the subtitles external. SUP files can't be external files, they only work when they are inside of a container like MKV. But if I wouldn't mind to modify my MKVs, I would just put the SUPs inside of them, and there wouldn't be a need for BDSup2Sub.

I still use BDSup2Sub 4.0.0 with my Blu-Ray Ripper program to merge forced subtitles into the main movie subtitle track if needed.

This does require to export to XML\PNG > merge forced events > export back to SUP.

I have my own editor GUI but it uses BDSup2Sub 4.0.0 from the command line.

Bandits
20th September 2017, 18:12
Thanks to this wonderful thread I have found that versions of BDSup2Sup higher than 5.0.0 will lose 15% of the subtitles (totally unusable), but versions 5.0.0 and lower will only lose 1% if any.

Since it still loses a couple of subtitles, I have decided to implement one of the two things missing in BDSub2Sup that makes it lose subtitles.

Basically BDSup2Sub didn't implement two things:

Complex compositions. This is when two or more subtitles are shown at the same time. A warning is shown that multiple ODS are defined and only one subtitle will be recognized.
Cropping. BluRay subtitles support showing a piece of the image each time, so a line like "Ok! Let's do it" can be shown like "Ok!" first and then "Ok! Let's do it".


The second item is not that terrible. You will only lose the "animation" of the subtitle being shown few words at a time.

But the first item is a big problem. This usually happens when a subtitle is being shown and then another one has to appear, for example a foreign sign have appeared in the screen and the person hasn't finished talking. Since compositions are very common they must be implemented.

So that's what I did here: https://github.com/naikel/BDSup2Sub/tree/enhanced

Also I tried to give a better explanation how PGS works here: http://blog.thescorpius.com/index.php/2017/07/15/presentation-graphic-stream-sup-files-bluray-subtitle-format/

With your new version, tracks 7 and 8 on Close Encounters of the Third Kind (1977) crash.

java.lang.NullPointerException
bdsup2sub.supstream.bd.Sup.BD.(Sup.BD.java:301)
bdsup2sub.core.Core.readSup(Core.java:301)
bdsup2sub.core.Core.run(Core.java:158)
java.lang.Thread.run(Unknown Source)

With 4.0.0, you will receive error:

WARNING: missing PDS/ODS: last epoch is discarded

r0lZ
2nd October 2017, 14:44
That is not a bug.As an additional evidence that there is really a bug with the way BDSup2Sub handles the frame rates and subtitle timings, have a look at this recent post (https://forum.doom9.org/showthread.php?p=1820432#post1820432) in the BD3D2MK3D thread.

Users should NEVER have to wonder why their subtitles are not in sync any more after having processed them with BDSup2Sub (including with your version). The fact that they are not in sync except if the user does something obscure that he should NEVER be obliged to do is obviously the signature of a big bug. Please try to understand and fix that bug. It should be extremely easy to fix it, as it is sufficient to simply use the same output frame rate than the input. It's probably simply a single line of code to fix or add, and the nightmare of the out of sync streams produced by BDSup2Sub will be definitively a thing of the past.

(Note that I don't need the fix to use BDSup2Sub with BD3D2MK3D. I have added the "convert from 23.976 fps to 23.976 fps" arguments to the command line used by BD3D2MK3D, and it's sufficient to obtain the correct output. But is it really normal to have to do it? And do you really want to have to explain to all users that have encountered the bug that they have to force a theoretically useless frame rate conversion to obtain the correct output?)

Bandits
7th October 2017, 17:46
(Note that I don't need the fix to use BDSup2Sub with BD3D2MK3D. I have added the "convert from 23.976 fps to 23.976 fps" arguments to the command line used by BD3D2MK3D, and it's sufficient to obtain the correct output. But is it really normal to have to do it? And do you really want to have to explain to all users that have encountered the bug that they have to force a theoretically useless frame rate conversion to obtain the correct output?)

I use the same line. This has been known for quite sometime and its not to bad when using it from command line. It just gets confusing to users when they open the GUI and expect it to work when FPS is deselected.

dngnt
11th November 2017, 14:27
Hello everybody! I have recently discovered BDSup2Sub512.jar , but my main usage is oddly for conversion from SUP and IDX/SUB to SRT for Asian languages (Korean, Japanese and Chinese)... Thanks to its support for XML/PNG , I am able to extract all the images from the subtitles in a decent form in order to process before OCR by ONeNote and Acrobat.

The image extraction is far better than Vobsub, XilisoftDVD Subtitle Ripper ... because each image focusses on the subtitles , not the whole screen.

I do not use its XML. I further enhance the resulting images with Irfanview in order to OCR with One Note and Acrobat. Subtitle Edit is also used on the Sub/Sup to get a draft of the SRT with the timings ( and its rich conversion skills to other subtitle formats are very helpful), but its OCR capabilities are very limited .

All that combined allows me to get a correct Srt , with some processing and a little proof-reading. But its great fun because of all the scripting involved.

The essential part is the extraction of the png from the sub.sup to convert to text (thanks to the developpers!:thanks:)...Quite the reverse of the initial philosophy of BDsuptosub I presume .

r0lZ
28th December 2017, 13:03
I've just encountered a palette problem with bdsup2sub. There are warning messages telling "fade detected. Patching palette." After the patch, sometimes the palette is totally wrong. For example, the white text appears correctly, but the transparent background is opaque black, and the outline is fully transparent. Or everything seems almost correct, but the background is not fully transparent.

The bug happens in the two java versions (the original and the enhanced), but the C++ version doesn't have that bug. (And, BTW, the C++ version doesn't have the sync bug discussed above either. Unfortunately, it has other bugs, so it's not really a good candidate to replace the java versions.)

If someone wants to fix the bug, he can download original.sup here (https://takeafile.com/?f=resuhitufo).

Thanks in advance.

LeXXuz
28th December 2017, 23:56
I'm confused. What is the recommended version of BDSup2Sub actually?

Bandits
29th December 2017, 01:03
I guess it would depend on your needs.

I use 4.0.0 because all the other versions can't reliably give me the results I am looking for. I believe I gave reasons why in an earlier post.

LeXXuz
29th December 2017, 06:40
Okay. I will go back to the old 4.0.0 I guess.

Scorpius' version is no alternative to me:
-It does not remember settings like output format, palette or filter. It always goes back to SUB/IDX, create new, bilinear upon start.
-It has no keyboard shortcuts for the commands anymore.
-It does not use the input file names folder by default for export.
-It does not add an _exp to the filename like any other version does.

r0lZ
29th December 2017, 11:49
Where can I download v4.0.0 ? The link in the first post of this thread is dead, and I would like to compare it with the 3 current versions.
[EDIT] Never mind. I've found it with your Blu-Ray Ripper (https://www.dropbox.com/sh/25w69pxf0upmmur/AAAISyvF4vqRSQDe4l27pcrka?dl=0) files, Bandit. Thanks.

r0lZ
29th December 2017, 14:49
OK, I did some tests with various versions of BDSup2Sub. I have tested BDSup2Sub v4.0.0 (https://forum.doom9.org/showthread.php?p=1254788#post1254788) (as far as I know, it's the latest version written by 0xDEADBEEF, still available in the files.zip here (https://www.dropbox.com/sh/25w69pxf0upmmur/AAAISyvF4vqRSQDe4l27pcrka?dl=0)), v5.1.2 (https://www.videohelp.com/software/BDSup2Sub) (the current "official" version), BDSup2SubEnhanced (https://forum.doom9.org/showthread.php?p=1812398#post1812398) v0.0.9 (originally based on v5.0.0) and BDSup2Sub++ (https://forum.doom9.org/showthread.php?t=165416) v1.0.2 (the only version that doesn't require Java). Unfortunately, none is bug free.

Here is the detail of the tests I did.

Let's begin with the little bugs or discrepancies, not really harmful if you know what you are doing.

1. The irritating problem of the frame rate assumed wrongly is present in all Java versions, but the ++ version doesn't have that problem. Note that it's not really a bug, only a discrepancy. When you load a stream, the program detects correctly the source frame rate, but it sets 25 fps as the default output frame rate, for totally obscure reasons. That means that the time codes are rounded with the wrong output frame rate, and they are therefore not strictly identical than in the input stream, even if the user doesn't explicitly require a conversion. Furthermore, the wrong frame rate is written in the XML file if you convert to XML/PNG, and that can lead to completely wrong time codes and grave sync problems. Luckily, it is easy to avoid that bug simply by specifying that you WANT a conversion, and specifying the output frame rate equal to the input frame rate. It's a pity, but if you know that you have to do it, the workaround is easy. (That works with the GUI and the command line.)

2. Related to point 1 is the bug that prevents the user to store a different output frame rate by default. The output frame rate is always 25 fps in all Java versions, regardless of what you have used the last time and/or the usage of the "Store" button. That means that even if you use only, say, BD sources at 23.976, you have to pay attention to the output frame rate each time you load a stream. Pity, but again, it's an annoyance and not really a bug. Again, the ++ version does a better job. It doesn't store the output frame rate, but it uses by default the same frame rate than the input. Perfect.

3. Related to point 2 is the way the program store its settings. All versions store them in .ini files, but v4.0.0 and the Enhanced versions store them in the folder containing the executable. It's against the Microsoft rules, but you may accept that little problem. V5.1.2 and ++ store their ini respectively in the user's home and in APPDATA\Roaming, as they should.

Now, the real bugs.

4. When a subtitle is included in a larger bitmap (therefore with more or less large transparent borders around them), all Java versions have problems with the colours or the transparency values of the different parts of the subtitles. For example, the background can be opaque instead of fully transparent, or the outline can be missing. This is the case of v4.0.0 and Enhanced. V5.1.2 outputs completely transparent frames ! Only the ++ version does the job perfectly. I guess that bug is caused by the method used to discover the colours and transparency levels of the different parts of the pictures. They check probably only some pixels near the border of the subtitle, and fail when there is no subtitle at that place. It's a very important bug, that occurs relatively frequently (especially with Asian BDs). It explains why some peoples have reported that some subtitles are missing when using a recent version. v4.0.0 and Enhanced give totally wrong results, but at least, they are visible.

5. The Enhanced version has been written to fix the bug of missing subtitles when several subtitles are displayed AT THE SAME TIME (technically: Multiple ODS). It's often the case with Japanimation (mangas) but that can happen with other movies as well, although it's relatively rare. Indeed, v4.0.0 and v5.1.2 have that problem, as well as the entire "official" branch of BDSup2Sub. And of course, the Enhanced version does it well. Strangely, the ++ version works also perfectly well ! It's an important bug, but unless you are a fan of mangas, you may not have noticed it.

6. When an XML/PNG stream is loaded in any version of BDSup2Sub, the fully transparent borders are cropped so that the picture occupies the smaller possible areas. (Of course, nothing changes when the subtitle touches the 4 borders.) Since the border is removed, the X, Y, width and height coordinates of the bitmap must be adjusted. All Java versions do that job correctly. The ++ version has its first bug here. The X coordinate is always wrong after a crop. For example, the subtitle is not centered on screen any more, and may appear slightly to the left, or completely near the left border of the video frame. Of course, it's a big bug, that happens only when loading XML/PNG streams containing subtitles in large canvas. It's a pity, as otherwise AFAIK ++ is the only bug free version. Unfortunately, the development of the ++ version has stopped, so the crop bug will probably remain for a long time.

7. The ++ version tries to detect when several subtitles are displayed at the same time in a BD SUP stream (Multiple ODS), just like the Enhanced Java version, and usually it does it well. When it converts the SUP stream to XML/PNG, it creates several PNG images for the same subtitle (instead of a single image combining all subtitles together). It is not clear if doing so is legal, but it is able to load the XML/PNG and convert it back to another format without problem. However, it has a big bug occurring only with some specific SUP streams (like the subtitles of Avatar 3D). It detects wrongly some additional subtitles that are in fact not present. When it encounters such false positives, it creates bizarre empty PNG images, and it references them in the XML badly. The result is that the XML/PNG stream cannot be reloaded in any version of BDSup2Sub. See this post (https://forum.doom9.org/showthread.php?p=1828709#post1828709) for more info.

8. It's probably not a bug, but I notice that there are many warning messages displayed by all java versions, like for example:
WARNING: multiple PDS/ODS definitions: result may be erratic
WARNING: end time of frame 39 < start time -> fixed
WARNING: fade out detected -> patched palette
Strangely, the ++ version does NOT display these warnings. Is it because it deals with the potential problems correctly ? It's certainly the case of the multiple PDS/ODS definitions, but for the other warnings, I don't know.

9. With some BDs, it appears that BDSup2Sub++ is unable to merge the identical subtitles together. So, in that BDs, a single subtitle can be repeated several times, with no gap (or only a few ms) between the time codes. The resulting subtitle stream is therefore larger than the original one. The java version doesn't have that bug. Both versions have the CLI option -x <time> or --merge-time <time> to "Set maximum time difference for merging subtitles in ms", with the default value of 200 ms, but it seems that that option doesn't work well with ++ and some subtitle streams.

10. When BDSup2Sub++ loads and re-saves (without modification) a BD SUP file, it creates a new file larger than the original file. The overhead is usually around 10%. Even the new version, re-saved again, has again a small size increase. The origin of the problem is not known, but it seems that the stream is still correct and compatible with the decoders. The Java version doesn't have that problem.

There might of course be other bugs that I'm not aware of, or very small bugs that are not really important like the little GUI bugs of v4.0.0. Note also that the ++ version doesn't have exactly the same command line parameters than the Java versions. And, about the command line, the 3 Java versions may require to launch Java with the obscure -Xmx256m command line parameter, as otherwise it may crash when processing a big subtitle file due to lack of memory.

Anyway, with the 4 "problematic" streams I've tested so far, there is no version that works constantly as expected. I suggest therefore to use the ++ version if you don't need to convert from or to XML/PNG, and the Enhanced version otherwise. Anyway, don't forget to pay attention to the output frame rate (bug 1) with all Java versions.

P.S. The bugs 4 and 6 can be reproduced with this sample (https://takeafile.com/?f=resuhitufo). Bug 7 is clearly demonstrated with the subtitles of the Avatar 3DBD (not sure for the 2D version). If someone wants to check a specific stream or bug, send me a PM and I'll give you the demo stream.

Ghitulescu
29th December 2017, 17:52
OK, I did some tests with various versions of BDSup2Sub. I have tested BDSup2Sub v4.0.0 (as far as I know, it's the latest version written by 0xDEADBEEF), v5.1.2 (the current "official" version), BDSup2SubEnhanced v0.0.9 (originally based on v5.0.0) and BDSup2Sub++ v1.0.2 (the only version that doesn't require Java). Unfortunately, none is bug free. But a winner stands out clearly: BDSup2Sub++. It is also much more faster than the Java versions.

Thank you for the testing, really appreciate this.
http://www.tapeheads.net/images/smilies/thumbs-up.gif

Bandits
29th December 2017, 18:12
Thanks for your testing r0lZ.

I use BDSup2Sub to extract .sup to .xml, merge 2 .xml files together, then create a new .sup, all from command line (I never use GUI). After your testing it would seem best to use ++ to extract and 4.0.0 to create new .sup? Everything is automated so using 2 versions would not be an issue. I just want the best possible results without missing subtitle events.

If I could figure out how to extract the data myself I would write some code myself removing the need for BDSup2Sub but getting the png's out of a .sup does not make any sense to me.

r0lZ
29th December 2017, 18:23
Thanks for the thanks!
I use BDSup2Sub to extract .sup to .xml, merge 2 .xml files together, then create a new .sup, all from command line (I never use GUI). After your testing it would seem best to use ++ to extract and 4.0.0 to create new .sup? Everything is automated so using 2 versions would not be an issue. I just want the best possible results without missing subtitle events.
I plan to do something similar for BD3D2MK3D. Currently, the user has the choice of the version to use, but I think that the result will be consistently better if I can use always the ++ version to create the XML/PNG, and any java version for the conversion of XML/PNG to the output format (BD Sup or DVD Sub). Of course, BD3D2MK3D uses also the command line only. I'll let you know if I encounter a problem...

BTW, I forgot to specify that the ++ version doesn't have the same command line parameters than the Java versions. That may be a bad point for your automation tool.

Bandits
29th December 2017, 19:30
Are you using ++1.0.2 or ++1.0.2a?

I'm familiar with the differences in the commands. I have used most versions at some point. I probably can find a version of Blu-Ray Ripper that had used the different commands and just cut paste.

Once again thanks for taking the time to check the different versions.

r0lZ
29th December 2017, 19:57
I use ++ 1.0.2. I did not know the existence of 1.0.2a. Do you know where it is coming from, and what is its difference with the previous version ?

Bandits
29th December 2017, 22:51
https://www.videohelp.com/download/bdsup2subplusplus1.0.2_Win32.7z Says its from 2016 but file date is 2013. Has 102a in title. Also there is an 102a from Jan 2013 that hashes the same.

https://www.videohelp.com/download/bdsup2subplusplus1.0.2_Win32.7z From Apr 2013

All old versions (https://www.videohelp.com/software/BDSup2Sub/old-versions#downloadold)

BDSup2Sub++ 1.0.2
Bugs

Fixed issue in BD SUP parser that could trigger palette not being updated with subtitles that used fades.
Fixed issue where "move from original y position" did not work properly with positive values.

Enhancements

Settings are now stored in AppData folder on Windows and $HOME on *nix platforms.


BDSup2Sub++ 1.0.2RC
Bugs

Fixed issue where scaling filter specified by CLI didn't recognize the option.
Fixed issue that caused empty SUP files to crash the application
Fixed issue importing an invalid palette INI file would cause all colors to be set to black
Fixed issue where processing via CLI did not result in bit-exact output as through the GUI

Enhancements

Properly handles BD SUP that contain subpictures that use multiple composition objects
XML/PNG input/export properly handles events with multiple graphics


BDSup2Sub++ 1.0.2
Performance optimization, memory leak, and crash fixes.

Also under old versions there is another 102a from 2013. I can tell you the 102a keeps the .ini in its same folder. Other than that I haven't done any testing but to launch them to see version number. I can find no change log for 102a.

r0lZ
29th December 2017, 23:46
Sorry, I can't find the ++1.0.2a that doesn't save its ini in the same dir. Your two first references link to the same file, so I don't know to which file you refer. It seems that there are several archives containing the same 1.0.2a at VideoHelp, but not the "good" version.

Anyway, I suppose that that version is not due to the same developer, as otherwise he should have released 1.0.3. And since the development has stopped, I think I'll keep the last version of the official author of the ++ branch, the one that I have tested.

Bandits
30th December 2017, 00:30
I don't know why my links went to the same place.

I see a bdsup2sub++1.0.2_Win32.7z (supposable 2016) that is the same as bdsup2subplusplus102a_win32.7z (1/30/2013) that are both 3.6megs and hash as the same file. I also see bdsup2subplusplus1.0.2_Win32.7z that is 3.8megs and shows no "a" on the title bar. The non "a" version appears to be the latest file date at 4/17/2013. Is that the version you are using?

r0lZ
30th December 2017, 11:14
Yes. The only "a" version that I have is dated 30/1/2013 21:49 as seen in Properties -> Details tab. (I don't trust the date of the archive or the release date shown at the VideoHelp site.) It stores the ini in the program's dir. Also, it cannot handle the multiple subtitles at the same time (bug 5). I haven't tested it fully, but obviously, it's an old and useless version.

I have never seen an "a" version that doesn't store the ini in its dir.

I will definitively keep the latest version without the "a". It is 4.059.136 bytes (3.87 MB) and is dated 17/4/2013 18:39 (again in Properties). It's the version I have used to do the tests.

r0lZ
30th December 2017, 14:19
Damn! I did some additional tests, and I've found that ++1.0.2 fails miserably when it converts some subtitles streams to XML/PNG. It creates often several PNGs for the same subtitle (probably when the Java versions issue the Fade out detected warning). When it's the case, the entry for that subtitle is wrong in the XML. Furthermore, it references sometimes non-existing PNGs. For example, I've converted the French subtitles of Avatar to XML/PNG, and I see this in the XML:

<Event InTC="00:08:48:21" OutTC="00:08:50:15" Forced="False">
<Graphic Width="0" Height="0" X="0" Y="0">Avatar_fr_exp_0101_0.png</Graphic>
<Graphic Width="0" Height="0" X="0" Y="0">Avatar_fr_exp_0101_0.png</Graphic>
<Graphic Width="0" Height="0" X="0" Y="0">Avatar_fr_exp_0101_0.png</Graphic>
<Graphic Width="0" Height="0" X="0" Y="0">Avatar_fr_exp_0101_0.png</Graphic>
<Graphic Width="0" Height="0" X="0" Y="0">Avatar_fr_exp_0101_0.png</Graphic>
<Graphic Width="474" Height="126" X="557" Y="794">Avatar_fr_exp_0101_5.png</Graphic>
</Event>

Only the 0 and 1 PNGs exist, and of course it is impossible to import that XML/PNG stream back in any version of BDSup2Sub.

With this subtitle stream, it seems that the first picture (with the _0 extension) is always good, so it should be possible to write a little script to patch the XML to remove the bad entries and change the file name of the entry with the correct dimensions, like this:

<Event InTC="00:08:48:21" OutTC="00:08:50:15" Forced="False">
<Graphic Width="0" Height="0" X="0" Y="794">Avatar_fr_exp_0101_0.png</Graphic>
</Event>

Bot of course, I cannot be sure that the first PNG is always the one to keep.

I'm still investigating that bug, and I will try to find a workaround. I'll report here when I will have a solution. In the meantime, do not assume that the ++ version works correctly to convert from PGS to XML/PNG.

[EDIT] It seems that ++1.0.2a and ++1.0.0 do not have that bug. It's a pity that they have the multiple subtitles bug. :-(
I can't find ++1.0.1. Does it exist?

r0lZ
30th December 2017, 15:32
I have understood why BDSup2Sub++ does that strange thing with the _1, _2... extensions. It's to deal with the problem of the multiple subtitles appearing at the same time. The sample provided by Scorpius666 here (https://forum.doom9.org/showthread.php?p=1812409#post1812409) to demonstrate the problem of the double subtitles is a good example.

That stream contains two subtitles. The first subtitle with the word "INCOMPETENT" is shown near the top of the screen from 00:17:10:19 to 00:17:14:08. The second subtitle "Isn't it more like this?" is shown in the bottom of the screen only from 00:17:12:02 to 00:17:13:09. It is therefore displayed when the first subtitle is visible. That subtitle disappears with all Java versions except Enhanced, and ++ prior to v1.0.2 as well as 1.0.2a.

BDSup2Sub++ translates that two subtitles to XML/PNG as 3 subtitles, like this:

<Events>
<Event InTC="00:17:10:19" OutTC="00:17:12:02" Forced="False">
<Graphic Width="379" Height="45" X="773" Y="108">Multiple Subs Sample_exp_exp_0001_0.png</Graphic>
</Event>
<Event InTC="00:17:12:02" OutTC="00:17:13:09" Forced="False">
<Graphic Width="377" Height="43" X="773" Y="108">Multiple Subs Sample_exp_exp_0002_0.png</Graphic>
<Graphic Width="473" Height="43" X="739" Y="928">Multiple Subs Sample_exp_exp_0002_1.png</Graphic>
</Event>
<Event InTC="00:17:13:09" OutTC="00:17:14:08" Forced="False">
<Graphic Width="379" Height="45" X="773" Y="108">Multiple Subs Sample_exp_exp_0003_0.png</Graphic>
</Event>
</Events>

There are indeed two subtitles shown at the same time between 00:17:12:02 and 00:17:13:09.
I don't know if specifying two BMPs for the same subtitle is legal, but it's a way to handle the difficult problem of the two subtitles.

BTW, BDSup2SubEnhanced use probably a similar trick, since it creates also 3 subtitles out of the two original subtitles, and it uses the same time codes than the ++ version. I don't know if it is smart enough to merge the two bitmaps together for the new combined subtitle. Anyway, it is unable to save the stream correctly as XML/PNG. Pity.

I will try to find a method that works with all kind of source subtitle streams. It will probably be necessary to save the original stream to temp files to avoid some bugs. Anyway, I'll do that later. I'm tired of the numerous problems encountered with all versions, and I have to prepare the new year eve...

@Scorpius666: If you have some time, can you have a look at the palette/transparency problems of your versions ? I can give you some examples. It's the only major bug of your version, and if you can fix it, we will have a good solution. Thanks in advance!

Bandits
30th December 2017, 19:35
I will start testing a few files. I am currently extracting the Avatar subtitles which I know have issues in different version. I also know Close Encounters of the Third Kind gives different results. Test Subtitle (https://www.dropbox.com/s/xenubv7skfztc2p/Subtitle_7_English_Normal_Forced.sup?dl=0). 4.0.0 reports 1071 events as well as 5.1.2, ++ reports 1077 events, and enhanced crashes.

I will do some extractions to see differences.

I can't find ++1.0.1. Does it exist?

Can find all ++ versions from the link in my signature. As well as the test subtitle. Be aware the version numbering is strange for ++ versions. I included file dates in the fine names to see correct release order.

r0lZ
30th December 2017, 19:41
If there are sometimes several subtitles at the same time, it is normal that ++ reports some additional events, as I've explained above.
How can I dl your tour test subtitle? If I follow the link, I end up in my DropBox space.

r0lZ
31st December 2017, 12:20
I have modified the list of bugs here (https://forum.doom9.org/showthread.php?p=1828627#post1828627) to include the ++ bug discussed above (as bug #7).
I am currently trying to find how to detect the bugs when running the different versions of BDSup2Sub from the command line, and if it's possible, I will try to find a workarounds for each of them, but that will take some time...

Bandits
1st January 2018, 18:11
You mentioned using 4 different streams you are testing. Can I ask which ones? I have Avatar and I downloaded the other you posted but are there 2 others?

r0lZ
1st January 2018, 19:51
I use the subtitles from the Avatar 3DBD because BDSup2Sub++ detects wrongly multiple ODS, and it creates blank and/or missing PNG files when it tries to convert it to XML/PNG. Note that loading that stream in ++ and saving it as a new BD SUP solves that problem. The copy is bug free, and doesn't contain false multiple ODS any more.

I use also the little sample file provided by Scorpius666 in this post (https://forum.doom9.org/showthread.php?p=1812409#post1812409), because it demonstrates clearly the problem of the multiple ODS, and here, it's not a false positive.

I use also the subtitles from the musical 3DBD Scorpions Live in 3D, Get Your Sting & Blackout (2012). It cumules two problems. The Java versions produce the subtitles with bad palette or transparency values (or both). Also, many subtitles are embedded in larger transparent areas, and that makes BDSup2Sub++ fail when it loads the XML/PMG. The X positions are almost always wrong.

The fourth stream is not really necessary. I kept it because it's an example of multiple ODS I've found a long time ago, but Scorpius666's sample is better.

BTW. I have now a method that works to convert from BD SUP to XML/PNG and again to BD SUP (or DVD SUB) with all problematic streams I have tested so far. I have has to write a little script to combine the PNGs of the multiple ODS events to form a single PNG and therefore a single ODS. That works already well, but I still have to finish it. I'll release it here when it will be ready. The method is this:

1. Load the original BD SUP in BDSup2Sub++ v1.0.2 (not v1.0.2a!) and export it as a new BD SUP. That's sufficient to solve the problem of the Avatar subtitles. Do NOT use a Java version, as otherwise you will experiment the bad palette problem.

2. Load the new BD SUP in ++ and export it to XML/PNG. The XML/PNG should be correct, without blank PNGs or bugs in the XML.

3. Process that XML/PNG with CombineMultipleODS (my script). It will combine the PNGs of the subtitles with multiple ODS as single PNG and produce a new XML file with the references to that new PNGs. Therefore, the stream is now "pure", without multiple ODS any more.

4. Do whatever you need to do with the fixed XML/PNG. (In my case, I need to convert it ti 3D SBS or T&B.)

5. Load the final XML with a Java version of BDSub2Sub. Any version should be OK, since the XML/PNG is clean and without multiple ODS. Do NOT use ++, as if there are subtitles in larger canvas, it will crop them and fail when computing the new X coordinates.

6. Export in the final format you need. You should obtain a perfect result, without missing subtitles, bad palettes or wrong X coordinates.

I will probably release CombineMultipleODS tomorrow...

Bandits
2nd January 2018, 03:13
So use ++1.0.2 as a filter by converting SUP to SUP. (Fix bad palette)
Use ++1.0.2 to export to XML. (Proper detection of multiple ODS)
Combine PNG's for Java version to properly detect in XML.
Use any Java version to create new SUP from XML. (++1.0.2 fails on some X/Y offsets)

Seems simple enough and easy to implement for my use.

How are you squashing the PNG's together? GDI?

r0lZ
2nd January 2018, 10:04
Yes, it's exactly that, except that the first conversion (from SUP to SUP) fixes only the false positives of the multiple ODS (the "Avatar bug"). ++1.0.2 doesn't have the palette/transparency bug.

The script I've made uses ImageMagick's convert.exe. It's somewhat slow, but since there are usually only a few multiple ODS, it's fast enough.
The command line looks like this:

convert.exe -size "474x864" xc:none "test/test_exp_exp_0002_0.png" -geometry +34+0 -composite "test/test_exp_exp_0002_1.png" -geometry +0+820 -composite "test/test_exp_exp_0002_combined.png"

Where the size is the size of the transparent bitmap receiving the two (or more) subtitles and the -geometry parameters are the X/Y coordinates of the PNGs within that bitmap. Both are easy to compute from the values in the XML. You can add more -geometry +x+y -composite "sub.png" chains if there are more than 2 subtitles to compose, but I have never encountered that.

The script checks also if there are bad entries in the XML, with <Graphic Width="0" Height="0" X="0" Y="0"> or missing PNG files, as they are the sign that a stream causing the "Avatar bug" has been converted directly to XML/PNG. Anyway, that buggy XML/PNG streams cannot be loaded in any version of BDSup2Sub, due to the missing PNGs.

r0lZ
2nd January 2018, 12:33
Here is the little dirty script I wrote to fix the problem of the multiple ODS bug. It is written in Tcl, but I have compiled it as an exe, so that you don't have to install Tcl/Tk to run it.
It works from CLI only, but you can also drop an XML file on the exe to convert it automatically (but the DOS window will be closed automatically at the end of the operation, so you will not see the error messages).

The script works on XML/PNG streams only. When there are multiple ODS (several subtitles appearing at the same time on screen), BDSup2Sub++ v1.0.2 saves them as several PNGs for the same event. BDSup2Sub++ is the only program able to reload that streams correctly. Unfortunately, since BDSup2Sub++ has a big bug when it crops the PNGs, it is not safe to use it to load an XML/PNG stream. For that reason, it is necessary to merge the PNGs of those multiple subtitles as one single subtitle. It's what CombineMultipleODS does. (Note that it does NOTHING if there are no multiple ODS in the stream.) You should finally load the fixed XML in any Java version of BDSup2Sub to export it to the final format. As an additional bonus, all multiple ODS will be removed (since they have been replaced by the combined subtitles), and you can be sure that any player supporting the BD SUP format will display all subtitles. You can also convert to DVD SUB (that doesn't support multiple ODS) if you want.

In the archive, there are also 3 sample SUP files to demonstrate the 4 big bugs of the various incarnations of BDSup2Sub, and convert.exe (from the ImageMagick package) used to combine the PNG files together. The source tcl script is also included.

Download: CombineMultipleODS.7z (http://download.videohelp.com/r0lZ/BDSup2Sub/CombineMultipleODS.7z)

amichaelt
1st May 2018, 00:40
So I've finally been able to have time to work on BDSup2Sub++ again after having to abandon it years ago. I unfortunately lost access to my original Github account so I've had to fork my original repo which is now located here (https://github.com/amichaeltm/BDSup2SubPlusPlus). I plan to try to work out all the remaining bugs in the tool from either when I stopped working on it or I handed it off. Other than the multiple ODS issues which r0lz has provided good examples to reproduce the issue with, please do post any other bug reports to my new repo and I will try to get to them as I have time.

For anyone interested, I have some sample builds that aren't functionally different from the last available builds, but have been compiled using an updated build environment of VS 2017 and Qt 5.10. They can be grabbed here (https://www.dropbox.com/s/i4y5db251ka1pz0/bdsup2sub%2B%2B.7z?dl=1). There is also now both an 32-bit and 64-bit version.

Since my builds are built on top of Qt 5.10 this means that the minimum supported platform is Windows 7, but that doesn't mean that someone probably can't still build the tool against a previous version of Qt that still has XP support.

I will eventually start a new thread since I don't want to hijack this one, but I wanted to at least let anyone who might still be using this tool that I will try to resurrect it from the dead as best I can. :o

Selur
1st May 2018, 08:38
Thanks for the info! :)
Made a quick compile for Win64 of the current source code and uploaded it to:
https://ufile.io/nvfhi (should be available for the next 30 days)

r0lZ
1st May 2018, 09:23
So I've finally been able to have time to work on BDSup2Sub++ again after having to abandon it years ago.
Great news! Welcome back!

BTW, are you SassBot or paradoxical?

Just another thing I would like. Can you accept larger resolutions, up to 4K (3840x2160)? That format might be illegal for standard subtitles, even for 4K BD, but it is necessary for 3D Full-SBS (3840x1080) and Full-TAB (1920x2160). I desperately need that possibility for my 3D converter, BD3D2MK3D.

It will be also very nice if you could integrate the 3D conversion, based on external offset sequences (OFS files). I can help you, but first things first. The bugs are more important.

amichaelt
1st May 2018, 16:46
Thanks for the info! :)
Made a quick compile for Win64 of the current source code and uploaded it to:
https://ufile.io/nvfhi (should be available for the next 30 days)

There's also a Win64 version in the zip I linked, but thanks for posting another build too.

Great news! Welcome back!

BTW, are you SassBot or paradoxical?

SassBot or amichaelt was the github account name I used.

Just another thing I would like. Can you accept larger resolutions, up to 4K (3840x2160)? That format might be illegal for standard subtitles, even for 4K BD, but it is necessary for 3D Full-SBS (3840x1080) and Full-TAB (1920x2160). I desperately need that possibility for my 3D converter, BD3D2MK3D.

Yeah I can look into that. Do you have an example file? Please post a feature request issue to Github so I don't lose it. https://github.com/amichaeltm/BDSup2SubPlusPlus/issues

It will be also very nice if you could integrate the 3D conversion, based on external offset sequences (OFS files). I can help you, but first things first.

Ok, yeah, if you can help me with that I would definitely be interested in looking into it. As above, please post a feature request issue.

The bugs are more important.

Yep. Having to remember how most of this code works after having not looked at it for nearly 6 years. Slowly but surely working my way through that. Probably need to write some good tests before I start fixing these bugs so I don't break more things. :devil: Once I tag a 1.0.3 branch with the last little bits of minor fixes related to making a new build and cosmetic maintenance items, I'll start digging into bugs for a 1.1 release.

Selur
1st May 2018, 16:55
There's also a Win64 version in the zip I linked, but thanks for posting another build too.
missed that :)

amichaelt
1st May 2018, 16:58
missed that :)

Not a prob. :)

Also, since libqxt was deprecated and they don't develop it anymore I've just simply integrated the code I used directly into the project. Luckily it was only 2 source files and headers so this should simplify things for anyone doing their own builds.

I may at some point convert over to the built-in Qt commandline classes, but they don't easily map over to libqxt's classes so I've held off on that.

r0lZ
1st May 2018, 17:04
Yeah I can look into that. Do you have an example file?
Unfortunately, no, simply because AFAIK there is no program able to create BD SUP files in that resolutions. But that files should be exactly identical to the old HD files (1920x1080), only with bigger bitmaps. And perhaps, for the XML+PNG format, a different resolution string in the header.

Ok, yeah, if you can help me with that I would definitely be interested in looking into it. As above, please post a feature request issue.I'll do it.
Please let me know when you will have some free time...

amichaelt
1st May 2018, 17:07
Unfortunately, no, simply because AFAIK there is no program able to create BD SUP files in that resolutions. But that files should be exactly identical to the old HD files (1920x1080), only with bigger bitmaps. And perhaps, for the XML+PNG format, a different resolution string in the header.

I guess I can try it out first doing a XML+PNG with 4k files and then work from there.

I'll do it.
Please let me know when you will have some free time...

Will do. Once I finish up and tag this early 1.0.3 release, I'll then create a new thread to track new development work and we can work through it in there.

jpsdr
2nd May 2018, 10:59
Stupid question : What's the diffence between your BDSup2Sub++ and the "standard" BDSup2sub 5.1.2 version ?

r0lZ
2nd May 2018, 11:14
BDSup2Sub is the original version, written in Java (and therefore requiring the Java Runtime environment). There is a relatively recent evolution called BDSup2Sub Enhanced, that adds partial multiple ODS support. Both versions have a couple of bugs.

BDSup2Sub++ is a version rewritten in C++ (and therefore that doesn't require an additional runtime environment). The latest version supports multiple ODS, but it has some bugs and it creates sometimes black subtitles when it converts from BD SUP to XML/PNG when it thinks (wrongly) that there are multiple ODS.

Currently, no version is perfect (except perhaps when using it for DVD SUB only). I have explained elsewhere (https://forum.doom9.org/showthread.php?p=1828627#post1828627) what version to use to convert from a specific format to another. With some luck, we will soon have a bug free version, thanks to amichaelt. :-)

amichaelt
2nd May 2018, 15:44
Stupid question : What's the diffence between your BDSup2Sub++ and the "standard" BDSup2sub 5.1.2 version ?

Like r0lz said, BDSup2Sub++ was my porting of BDSup2Sub from Java to C++ and Qt. Functionally they are nearly identical, but there are some bugs in it that I've got on my task list to fix. BDSup2Sub++ is also faster even though I never actually did much in the way of optimizations.

von Suppé
3rd May 2018, 10:11
AFAIK there is no program able to create BD SUP files in that resolutions

SubtitleEdit can export 4K sized SUP

r0lZ
3rd May 2018, 11:09
Good to know. Thanks!

amichaelt
3rd May 2018, 19:20
SubtitleEdit can export 4K sized SUP

Interesting. Then I will use its output as an example to follow. Do you happen to have any such examples off hand? If not, when I get to the point of exploring that I can make my own.

r0lZ
3rd May 2018, 21:33
It seems that SubtitleEdit saves regular HD subtitles, with the text size identical to the Full-HD resolution, but with the screen resolution set to 3840x2160. I think it's the normal way to store subtitles for UHD BDs. The players are supposed to upscale them at display time. BDSup2Sub++ is already able to load them, and it displays correctly the screen resolution, but the subtitles are too small in a big screen, because they are not resized. So, the current display of that subtitles is incorrect, and do not reflect the way they are displayed with a real UHD BD player, but I suppose that it will be relatively easy to adapt the display to show them correctly in the GUI.

I did also a test with UHD subtitles in XML/PNG format and I have compared it with the same stream in HD format. The PNG images are strictly identical in both streams. Only the XML changes. It has "3840x2160" VideoFormat instead of "1080p" in the description, and the X and Y positions of the subtitles are adapted for the larger resolution. BDSup2Sub (both versions) is unable to display that subtitles correctly, as the subtitles are too big and forced in the bottom right corner. So, it seems that the UHD resolution is a mix of HD subtitles with UHD positions. Not really smart. Also, it's not what I need for 3D Full-SBS or Full-TAB, as I think that I need larger subtitles, but I don't know if it's allowed.

I suppose that the best thing to do is to clone the behaviour of SubtitleEdit for real UHD subtitles, and implement something slightly different for 3D Full-SBS and Full-TAB. I will try to do some tests with UHD SUBs. Maybe they are compatible with Full-SBS/TAB...

jpsdr
4th May 2018, 09:27
From what i've read, 4k Blu-Ray spec stays 1080p for subtitles. The player has to upscale them to fit video.

hubblec4
4th May 2018, 12:11
Hi amichaelt

Nice to read that you continue your work. I have also some improvement wishes and some issues.
Is it ok to make an issue post on github?

von Suppé
4th May 2018, 18:14
From what i've read, 4k Blu-Ray spec stays 1080p for subtitles. The player has to upscale them to fit video.
Yes I read that somewhere and found it strange, TBH. I can imagine that upscaled 1080p SUPs will produce a less quality picture than 4K.

von Suppé
4th May 2018, 18:24
Do you happen to have any such examples off hand?
I don't know what you mean exactly. I'd be delighted to upload a home-brewed 4K SUP sample (which I create with SubtitleEdit from .srt or .ass file) for you, if that's your question?
If you want a full sized movie-sup (which is strongly edited, btw), I don't know if I'm allowed here...

amichaelt
4th May 2018, 19:15
Yes I read that somewhere and found it strange, TBH. I can imagine that upscaled 1080p SUPs will produce a less quality picture than 4K.

I've watched some 4k Blurays with subtitles. They look perfectly fine from a normal watching distance on a 65" TV.

I don't know what you mean exactly. I'd be delighted to upload a home-brewed 4K SUP sample (which I create with SubtitleEdit from .srt or .ass file) for you, if that's your question?
If you want a full sized movie-sup (which is strongly edited, btw), I don't know if I'm allowed here...

Yeah, one you've just created yourself is fine. :thanks:

von Suppé
5th May 2018, 13:14
I created one for you and zipped it, but the file is too large for upload as attachment here (strange, it's only 900 KB).
Can I send it to you in another way?


Edit: Got it:

http://s000.tinyupload.com/index.php?file_id=59384561607863519893

amichaelt
7th May 2018, 17:15
I created one for you and zipped it, but the file is too large for upload as attachment here (strange, it's only 900 KB).
Can I send it to you in another way?


Edit: Got it:

http://s000.tinyupload.com/index.php?file_id=59384561607863519893

Awesome! Appreciate it.

amichaelt
7th May 2018, 18:34
Hi amichaelt

Nice to read that you continue your work. I have also some improvement wishes and some issues.
Is it ok to make an issue post on github?

Missed this post and my answer is YES! Please do! :thanks:

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

I'll hopefully finish up the last bit of cleanup I need to do today before digging into bugs.

hubblec4
7th May 2018, 20:29
Ok fine, I thought you ignore me :-)

amichaelt
7th May 2018, 22:29
Ok fine, I thought you ignore me :-)

Nope. Also one of your issues was not an issue (running on Linux as it already can) and the other was one I had already been fixed and committed and will be in the future build (embedding the version info in the exe itself rather than relying on the file name). The other two I have put on my backlog of stuff to do.

BizkitBoy
9th May 2018, 13:36
Sorry if this has been posted/reported before, but I have searched the forum and didn't manage to find an answer.

I have an issue with BDSup2Sub++ 1.0.2
The Global Forced Flags setting isn't working properly when importing an XML file and then trying to export it as SUP.
Although the XML file does contain for each PNG the Forced flag which is set to either Forced="False" or Forced="True", when selecting in BDSup2Sub++ 1.0.2 the Force All flag to "keep" and exporting to SUP, it just marks as forced all the PNGs. Actually, this happens no matter what value you set in the Force All flag.

I noticed this happens only when importing XML files.

Has anyone found a fix or workaround?

r0lZ
9th May 2018, 15:58
Indeed, the ++ version has a bug. Just tried to convert an XML with the first subtitle forced and all others normal. In the GUI, the forced: yes or no information is correct, but when the stream is saved as a BD SUP, all subtitles are marked as forced. The Export Only Forced option works correctly.
The Java version of BDSup2Sub (v5.1.2) has not that bug.

von Suppé
9th May 2018, 16:36
I can confirm BDSup2Sub++'s behaviour as BizkitBoy told.
It even doesn't recognize the forced lines in it's own created XML-PNG (with forced flags).

Indeed the Java version works for this.
BTW, I always check the "Change frame rate" window and set both "FPS Source" - and "FPS Target" rates, even when no framerate change is needed.

amichaelt will be busy... :thanks:

amichaelt
9th May 2018, 16:54
Sorry if this has been posted/reported before, but I have searched the forum and didn't manage to find an answer.

I have an issue with BDSup2Sub++ 1.0.2
The Global Forced Flags setting isn't working properly when importing an XML file and then trying to export it as SUP.
Although the XML file does contain for each PNG the Forced flag which is set to either Forced="False" or Forced="True", when selecting in BDSup2Sub++ 1.0.2 the Force All flag to "keep" and exporting to SUP, it just marks as forced all the PNGs. Actually, this happens no matter what value you set in the Force All flag.

I noticed this happens only when importing XML files.

Has anyone found a fix or workaround?

The fix will be me debugging the code. Don't be sorry, I appreciate all these reports. Please keep them coming.

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

I finished up all the current cleanup stuff I want to do and I'll tag a 1.3 release later today and then start working on the next version in the coming days.

hubblec4
9th May 2018, 17:06
BTW, I always check the "Change frame rate" window and set both "FPS Source" - and "FPS Target" rates, even when no framerate change is needed.

Yes I can confirm this and this little workaround is used in my cE.

hubblec4
9th May 2018, 21:10
Thanks for the new version. Why is the exe(x64 over 15mb) so big? Version 1.02 is smaller then 4mb.

amichaelt
9th May 2018, 21:47
Thanks for the new version. Why is the exe(x64 over 15mb) so big? Version 1.02 is smaller then 4mb.

Forgot to run UPX on it. Will fix that and reupload.

Also, despite what I said earlier about Linux binaries since I got Travis-CI working I'm now working on getting it to output appimages for Linux. Will need other people to test though since I don't run Linux anymore and I'm not gonna make a bunch of distro-specific packages. ;)

Edit to add: The uploaded files are now fixed.

hubblec4
9th May 2018, 22:20
...
Also, despite what I said earlier about Linux binaries since I got Travis-CI working I'm now working on getting it to output appimages for Linux. Will need other people to test though since I don't run Linux anymore and I'm not gonna make a bunch of distro-specific packages. ;)
...

Thats sounds great, I will use it for my cE on Linux. I can/will test some feaures. I use LinuxMint (and I will try the new Ubuntu).

amichaelt
9th May 2018, 22:22
Thats sounds great, I will use it for my cE on Linux. I can/will test some feaures.

Thanks. I'll let you know when it's ready if you can be my first tester. :thanks:

amichaelt
10th May 2018, 02:39
AppImage build finally worked and deployed. It can be grabbed here (https://github.com/amichaeltm/BDSup2SubPlusPlus/releases/download/1.0.3/BDSup2Sub.-x86_64.AppImage). Please let me know if it works or has any issues.

von Suppé
10th May 2018, 08:35
amichaelt, call me stupid, but where the heck can I find the latest for Windows?
I don't know what file I must download?

r0lZ
10th May 2018, 08:52
BTW, I always check the "Change frame rate" window and set both "FPS Source" - and "FPS Target" rates, even when no framerate change is needed.
As far as I know, only the Java versions are affected by that bug. The ++ version sets correctly the FPS Target to the same frame rate as the FPS Source, and therefore there is no need to force the conversion of the frame rate to avoid the small timecode changes due to the alignment of the timecodes to the video frames.
IMO, there is nothing to fix here.

von Suppé
10th May 2018, 08:59
As far as I know, only the Java versions are affected by that bug. The ++ version sets correctly the FPS Target to the same frame rate as the FPS Source, and therefore there is no need to force the conversion of the frame rate to avoid the small timecode changes due to the alignment of the timecodes to the video frames.
IMO, there is nothing to fix here.
I agree.
But as I am using both versions I sometimes forget or get confused what version has what bugs to take into account. So, to avoid problems I got myself used to always do this framerate setting. Thanks for the reminder r0lZ.

r0lZ
10th May 2018, 09:35
amichaelt, call me stupid, but where the heck can I find the latest for Windows?
I don't know what file I must download?
Click the "4 releases" link just above the red line. You will be redirected here (https://github.com/amichaeltm/BDSup2SubPlusPlus/releases).

jpsdr
10th May 2018, 10:59
@amichaelt
Didn't you say you wanted to create a specific thread specific for the ++ version, discussion bugs, etc...

hubblec4
10th May 2018, 14:26
AppImage build finally worked and deployed. It can be grabbed here (https://github.com/amichaeltm/BDSup2SubPlusPlus/releases/download/1.0.3/BDSup2Sub.-x86_64.AppImage). Please let me know if it works or has any issues.

My first quick tests works perfect. Many thanks.

EDIT:
Could you also the linux binary(exe) named BDSup2Sub++ only?

amichaelt
14th May 2018, 14:29
Yeah, I’ll fix the naming on the appimage when I push the next next version.

Also, I’ve been able to fix two of the more egregious bugs from r0lz fairly easily. The one where subtitle positions would get messed up was a lack of an absolute value being applied to the X and Y offsets after transparency cropping. The one with the borked up XML+PNG with empty PNGs was do to the coden iterating over a map of the composition objects incorrectly. I’m moving on now to the forced flags issues from hubble. Once I get those figured out I’ll push out a test build for people to beat on and start a new thread then.

r0lZ
14th May 2018, 19:25
Thanks. Very good news! I can't wait for the new version...

VfBFan
20th May 2018, 19:15
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

amichaelt
20th May 2018, 19:58
Thanks I’ll look into it.

amichaelt
22nd May 2018, 22:31
Thanks for reporting that. I've got a fix in testing that I aped from SubtitleEdit that had to fix the exact same issue.

Also any other samples that cause problematic behavior, please report them here: https://github.com/amichaeltm/BDSup2SubPlusPlus/issues

mood
27th June 2018, 14:39
@amichaelt

it is possible add to the "bdsup2sub++.ini" to save the configuration of the exported language.

I have to change the language for each export subtitle. it would be nice if I could choose the default export language.

amichaelt
27th June 2018, 17:02
@amichaelt

it is possible add to the "bdsup2sub++.ini" to save the configuration of the exported language.

I have to change the language for each export subtitle. it would be nice if I could choose the default export language.

Yeah, should be no problem. I'll add it to the list.

Sorry for the delays all on getting this finished up, but I am still working on it I promise. Just been busy a lot when I get home. :(

hubblec4
27th June 2018, 19:37
No worry amichaelt, we can wait. You work on it and that is what counts.

Edit: I opened this issue (https://github.com/amichaeltm/BDSup2SubPlusPlus/issues/12) on github

haggis999
2nd July 2018, 14:53
I rip all my Blu-rays using MakeMKV, but my Oppo 105 player doesn't support PGS subtitles in MKV files. My wife is hard of hearing, so subtitles are important. For several years, my solution has been to extract the PGS subtitles using MKVExtract. The resulting SUP files are then converted to SUB and IDX files, using BDSup2Sub 5.1.2. The final stage is to use MKVToolNix to merge these new subtitle files into the original MKV. The resulting VOB subtitles are then readable by my Oppo.

For the first time, I have hit a problem with the BDSup2Sub part of this process. I have just bought a Blu-ray version of the classic film 'Some Like it Hot' and when I try to export the SUB & IDX files from BDSup2Sub, it eventually fails with the following error.


ERROR: Offset 36700161 out of bounds for file \\BONZONAS\Videos\Movies\Some Like It Hot (BD)\Some Like It Hot BD_track5_eng.sup

Is there anything in BDSup2Sub's conversion options that might fix this error?


UPDATE: I've just found a more recent beta version of BSSup2Sub (BDSup2Sub++1.0.2). Running that version has fixed my problem!

amichaelt
9th July 2018, 18:47
@amichaelt

it is possible add to the "bdsup2sub++.ini" to save the configuration of the exported language.

I have to change the language for each export subtitle. it would be nice if I could choose the default export language.

So the way I'm implementing this is as follows:

1) If the subtitle file has a language defined the exported language will be set to that.
2) If the subtitle file does not have a language defined the ini file will be queried to determine the language to use as the export language.

Sound acceptable?

Edit to add:
Just as a tip, if you add the language name to a SUP file, the program will use that to set the language upon export. For example if the file name:

False_positives_of_multiple_ODS.sup was changed to False_positives_of_multiple_ODS.french.sup then if you were to export this as a SUB/IDX then french would be auto-selected for you.

r0lZ
9th July 2018, 19:39
Edit to add:
Just as a tip, if you add the language name to a SUP file, the program will use that to set the language upon export. For example if the file name:

False_positives_of_multiple_ODS.sup was changed to False_positives_of_multiple_ODS.french.sup then if you were to export this as a SUB/IDX then french would be auto-selected for you.
IIRC, that worked well, including with a 2 or 3-letter language code, like False_positives_of_multiple_ODS.fr.sup
Is it still the case, or is it necessary to include the full language name in English ("french" in your example)?

staina
29th July 2018, 09:26
Pray for addition support for 4k UltraHD Bluray. Thank you Standa

r0lZ
29th July 2018, 10:29
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
16th December 2018, 10:27
What is the actual status of developement ?

asarian
2nd January 2019, 22:02
The whole program (4.0) doesn't sppear to be available on the server any more. :( Is this tool dead?!

r0lZ
2nd January 2019, 23:55
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
3rd January 2019, 06:32
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
1st February 2019, 16:00
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
2nd February 2019, 04:39
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
3rd February 2019, 01:24
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
3rd February 2019, 11:00
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
3rd February 2019, 13:20
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
3rd February 2019, 14:10
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
4th February 2019, 05:41
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
20th March 2019, 14:14
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
20th March 2019, 14:29
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
20th March 2019, 14:41
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
20th March 2019, 14:45
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
20th March 2019, 15:14
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
20th March 2019, 15:16
See my edited post. Shouldn't the resulting file size stay the same in that scenario?

r0lZ
20th March 2019, 15:20
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
21st March 2019, 00:20
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
29th May 2019, 10:53
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
12th August 2019, 01:47
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
12th August 2019, 07:35
This is a Java application. If you install a Java Runtime Environment to your Windows, it runs under Windows.

r0lZ
16th August 2019, 09:06
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
16th August 2019, 10:29
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
16th August 2019, 15:30
@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
22nd September 2019, 10:28
יש מדריך גם בעברית לבניית כתוביות?

hubblec4
23rd September 2019, 10:56
יש מדריך גם בעברית לבניית כתוביות?

No, I don't think so.

Welcome to Doom9. Please use English.

markfilipak
10th February 2020, 23:09
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
2nd July 2020, 13:06
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
3rd July 2020, 11:40
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
8th July 2020, 16:29
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
20th February 2021, 18:32
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
22nd February 2021, 18:45
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
2nd April 2022, 11:12
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
4th April 2022, 17:09
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
28th September 2022, 11:35
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
29th September 2022, 10:45
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
27th May 2023, 17:41
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.