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

[0xdeadbeef]

SupRip?

[HeartWare2]

Thanks for the suggestion. It's a great step on the way, but the parser is not as good as SubRip's (fails to find spaces between words and doesn't in many cases recognize letters already specified). It may be that I can make a post-processing tool that - via a dictionary - can detect the "missing spaces" problem.

Anyone know of a big dictionary of various languages? I need it as a large text file with an alphabetic list of known words in correct spelling, preferably with several languages available.

Or if I could make SubRip work it probably would be better...

[prenz]

Originally Posted by 0xdeadbeef

BTW: Did you test if tools like MKVMerge and SubtitleCreator accept SUB files with padding?

Both MKVmerge and SubtitleCreator accept and process .sub with padding stream. .mkv-Playback with VLC correctly displays the subs.

[0xdeadbeef]

I'm not so much concerned about the additional padding, but about the stuffing bytes (in case the padding size is < 6 bytes). I'd assume that some tools with SUB/IDX import consider them to be always 0.

[0xdeadbeef]

@prenz:
Hm, it seems my worries were not unfounded. SubtitleCreator doesn't open SUB/IDX streams with stuffing bytes (no crash, no warning, just behaves as nothing was loaded) and VobSub Resync simply doesn't display captions that use stuffing bytes in the packet header.

So while adding padding packets doesn't seem to hurt, using stuffing bytes obviously does. Or maybe I messed up the implementation. But I rather don't think so.

Besides, VobEdit doesn't seem to be much happier with the SUB using padding/stuffing. It displays more or less the same crap as for any other SUB. My impression is that even with the padding/stuffing, the SUB file is still too far from being a valid transport stream to allow VobEdit to parse it correctly.

Just for you (prenz) for testing, this is not an official release:
http://www.sendspace.com/file/7k2i9i

If you can't tell me that my implementation is buggy, I guess I won't take over these changes in the next release as they seem to make the created VobSubs incompatible to any application reading VobSub.

[Ulf]

0xdeadbeef,

Something happened with v3.5.3 regarding 720p XML import - BDSup2Sub assumes 1080p on import.

[mrr19121970]

@0xdeadbeef

I have a couple of small requests for the log file:

1. show the incoming command line
2. for each of the converted files new name, old name (before or after the block of texts)

as this might be of interest when using wildcards like:

java.exe -jar bdsup2sub *.sub *-NEW.SUB

&

3. suppress warning etc that do no apply, for example when using /forced you don't need to see mesages about animations that weren't even extracted.

thanks...

[0xdeadbeef]

Originally Posted by Ulf

Something happened with v3.5.3 regarding 720p XML import - BDSup2Sub assumes 1080p on import.

Yep, unfortunately a side effect of my quick hack for 576i and 480i. Will be fixed in the next revision.

Originally Posted by mrr19121970

1. show the incoming command line

The whole command line is not available for a Java program. Only the arguments passed to the Java program are (and the path of the JAR can be determined with some tricks). I can print them out, but I don't think that makes much sense, as every option passed to BDSup2Sub is commented on anyway ("OPTION").

Originally Posted by mrr19121970

2. for each of the converted files new name, old name (before or after the block of texts)
as this might be of interest when using wildcards like:

java.exe -jar bdsup2sub *.sub *-NEW.SUB

I don't quite get this either. The source and target file names are already printed in the console (Loading xxx, Writing yyy) and the wildcarded names should be known to the caller anyway. Then again, this happens only in verbatim mode (since I introduced this), so I guess I should print this even in silent mode.

Originally Posted by mrr19121970

3. suppress warning etc that do no apply, for example when using /forced you don't need to see mesages about animations that weren't even extracted.

This is not easily possible as these warning are printed during the first parsing of the SUP, when also the "forced" flags are determined. Besides, the "export only forced" option could be changed later from the GUI again.

[0xdeadbeef]

10.05.2009 3.5.3 -> 3.5.4

• Changed: VobSub: control header now can be split over two packets. Seems to increase compatibility with SubtitleCreator.
• Changed: some more info is printed in the non-verbatim output mode (loading/writing files)
• Fixed: BDN XML: due to the last fix in 3.5.3, 720p was not recognized any more

[Adub]

I am receiving an error ("Invalid end sequence offset") with the latest release (3.5.4) when loading a VobSub idx file. Here is zip file containing the problematic files.

www.mirror.adubvideo.net/VIDEO_TS.zip

[0xdeadbeef]

Did it work with older versions? Does with work with other programs such as SubtitleCreator or VobSub Resync?
Anyway, it will take a while until I can have a look. Maybe not before tomorrow.

[0xdeadbeef]

Ok, I had a look. The error message is somewhat correct since not a single captions in this sample has a valid end sequence in its control buffer. Then again, I'm not 100% sure if this is allowed, so I'll add a workaround in the next version.
Anyway, since the end sequence is missing, also the end times are missing. This is also visible when opening the file with VobSub Resync.

[mrr19121970]

Originally Posted by 0xdeadbeef

This is a general issue of 64bit versions of Windows XP/Vista but shouldn't have an influence on applications reading the key. See e.g.:
http://www.insidetheregistry.com/reg....asp?keyid=387

Anyway, the registry key and the suggested approach both are correct.
http://java.sun.com/javase/6/webnote...e_windows.html

Here is a standalone checker, the same function I've installed in Clown_BD:

JAVA Version Check

I've tested on Vista & XP x32 & x64. Should be 'future proof', assuming JavaxFamily is derived from CurrentVersion 1.x

[nwg]

Thanks for the HD DVD to BD conversion. I was fed up using conversion to srt. I have only used it twice but it worked great each time. Also, using mrr19121970's Clown_bd makes the conversion even more effortless.

[0xdeadbeef]

I'd be really interested under which circumstances the created BD-SUPs display on a standalone and under which they don't.

Anyway, a minor update again:

12.05.2009 3.5.4 -> 3.5.5

• Changed: VobSub: added padding packets (and stuffing bytes via PTS length) to the exported stream.
• Changed: VobSub: invalid offset to end sequence only throws a warning, but import continues.
• Fixed: VobSub: entries in 4 color frame palette were truncated to two bits during import.
• Fixed: VobSub: padding by manipulating the PTS length was not always processed correctly during import.

[Jaja1]

Yesterday I revisited some problematic sup files. Suprip and supread can't read them at all and earlier versions of BDSup2Sub weren't able to give correct sup => sub conversions. However BDSup2Sub has now grown to a mature status, it gives great results on all these pain-in-the-ass .sups. Very much appreciated.

A question about the situation that there are more English .sups in a movie. For instance the main .sup, commentary and forced .sup. When I playback for instance a m2ts file with external subs (.sup converted to .sub in Zoomplayer or MPC-HC) it is impossible to see which one is which. I only see three subtitles all named "English". Would it be possible to give them a meaningfull name? This is possible with .srt files. Or is another party (vobsub?) responsible for this.

[0xdeadbeef]

Originally Posted by Jaja1

Yesterday I revisited some problematic sup files. Suprip and supread can't read them at all and earlier versions of BDSup2Sub weren't able to give correct sup => sub conversions. However BDSup2Sub has now grown to a mature status, it gives great results on all these pain-in-the-ass .sups. Very much appreciated.

Nice to hear. Anyway: from my experience, SupRip is handling much more (probllematic) SUPs correctly than SupRead. Both don't handle transparency animations though.

Originally Posted by Jaja1

A question about the situation that there are more English .sups in a movie. For instance the main .sup, commentary and forced .sup. When I playback for instance a m2ts file with external subs (.sup converted to .sub in Zoomplayer or MPC-HC) it is impossible to see which one is which. I only see three subtitles all named "English". Would it be possible to give them a meaningfull name? This is possible with .srt files. Or is another party (vobsub?) responsible for this.

AFAIK the information about language etc. is not located inside the M2TS transport stream, but inside some BD structure (probably MPLS). E.g. if you use EAC3TO to print out information about an M2TS transport stream, it doesn't name the subtitle tracks etc., while it does so when you use EAC3TO on the BD structure or a playlist ( like "1)" ).

So indeed this information is lost after demuxing (or even when copying only an M2TS from a BD folder to a new location) if it's not stored somewhere else. That's why it's usually a good idea to name the demuxed subtitle streams according to the info EAC3TO displays. Indeed if you demux all streams, EAC3TO automatically names the SUP files in this way.

Anyway, the file name is the only thing that BDSup2Sub can use to determine the (possible) language of a SUP file. That's why it scans the file name for language names (like "English", "German", "French") and preselect the language. When storing a format that includes language info (like VobSub or BDN XML), this language will be used if nothing else is selected in the export dialog.

[Arshad07]

I cant get it to open with java. Its opening with my Nokia Application file Any help please

Thanks

[Adub]

Use the command line.

Simply type:

java -jar my/path/to/my/application

[Arshad07]

Getting this error