BDSup2Sub - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP) [Archive] - Page 7

Mtz

28th April 2009, 11:51

OK, I'll give up. I just hope that someday you will understand that I'm right. Also the SupRip join feature have this bug. Working with text subtitles for more than 5 years and I saw over that 3000 srt subtitles, checking them for errors with subtitles workshop and also I helped the author of that program for fixing some minor bugs and translating the program in my language.
Good luck! You are making a very nice job, but seems that sometimes not looking deep in some posts.

Edit: just for fun, play these 3 subtitles test with any video: http://uploaded.to/file/d4bo9v Will cost you 1.30 minutes.

enjoy,
Mtz

Ulf

28th April 2009, 12:55

- if is possible to move all subtitles to bottom-right corner. Now I can edit the frame, but the edited is not applyed to all. In move all captions I cant move X position, only Y.

If you open your SUP in BDSup2Sub and save it as XML/PNG you'll get a XML file you can edit to achieve what you want. Part of the XMl file will look as this:

<Event InTC="00:00:00:00" OutTC="00:00:00:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0001.png</Graphic>
</Event>
<Event InTC="00:00:00:17" OutTC="00:00:01:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0002.png</Graphic>
</Event>
<Event InTC="00:00:01:17" OutTC="00:00:02:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0003.png</Graphic>
</Event>
<Event InTC="00:00:02:17" OutTC="00:00:03:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0004.png</Graphic>
</Event>
<Event InTC="00:00:03:17" OutTC="00:00:04:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0005.png</Graphic>
</Event>
<Event InTC="00:00:04:17" OutTC="00:00:05:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0006.png</Graphic>
</Event>
<Event InTC="00:00:05:17" OutTC="00:00:06:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0007.png</Graphic>
</Event>
<Event InTC="00:00:06:17" OutTC="00:00:07:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0008.png</Graphic>
</Event>
<Event InTC="00:00:07:17" OutTC="00:00:08:16" Forced="False">
<Graphic Width="576" Height="36" X="896" Y="900">00009_0009.png</Graphic>
</Event>

You can for example change all occurences of X="896" to X="1194". Increase Y if you want to move your subs further down. Then you import your XML to BDSup2Sub and save it as a SUP.

From what I can see from the XML file, BDSup2Sub handles the in/out timings completely correctly (frame accurately). The timings in a XML file are in the format HH:MM:SS:FF, where FF is frames. The timings in a XML file are somewhat confusing - they are given as if the frame rate is 30 fps when the frame rate is actually 29.97 fps.
One benefit is that the timings are completely unambiguous.
Note that there is no frame missing a subtitle, they all go out in on frame 17 and out on frame 16.

Ulf

29th April 2009, 10:27

0xdeadbeef,

Could you please make it an option in BDSup2Sub to merge/not merge identical subtitles if they are separated in time.

I have an example where the same subtitle is shown twice, with a short brake in between. If you look at the movie, it's quite clear that they are meant to be shown like this. BDSup2Sub (v3.4.3) are merging the two into one.

If I export the original SUP to XML/PNG by SUPread, one can see that the two identical subs are separated in time (three frames with no subtitle shown):

<Event InTC="00:49:44:11" OutTC="00:49:47:05" forced="False">
<Event InTC="00:49:47:09" OutTC="00:49:49:14" forced="False">

whereas BDSup2Sub merge the two:

<Event InTC="00:49:44:11" OutTC="00:49:49:14" Forced="False">

If InTC for the second (identical) subtitle was InTC="00:49:47:06", it would be no gap in time and merging would be OK.

0xdeadbeef

29th April 2009, 14:48

Currently BDSup2Sub uses a fixed time difference (200ms) to decide whether to merge identical captions or not (at least if there is a gap at all). BTW: merging is only implemented for BD-SUPs, as multiple repetition of the very same bitmap with short/no gaps is a common problem of this format (only).
The main reason for not letting the user set this value was that it's already needed during parsing. So I'd either need an additional dialog before loading the file or you'd need to reload the file after changing the option. Both seems awkward. The only proper way would be to move the merging from the parsing code to the scanning code, but this is a lot of effort.
The only quick'n'dirty solution I could offer was to make this (only) a command line option for the moment.

Honestely, I don't see any benefit in this anyway. In 99.99% of the cases where identical subtitles have a gap < 200ms, it's an authoring fault. And really: IMHO it seems strange to insist on getting a short flicker instead of a constant display.

So, in a nutshell: while it's not impossible that some future version will implement this (as GUI option), this is about as low in priority as can be. Indeed chances are it will never happen as rewriting the parser and scanning code just for this doesn't sound very appealing to me.

Ulf

29th April 2009, 15:39

The only quick'n'dirty solution I could offer was to make this (only) a command line option for the moment.

It would be great if one could set the "gap time" as a command line option!

turbojet

29th April 2009, 20:45

These bdn xml subs (http://www.mediafire.com/download.php?knl1nkzh3oz) crashes the gui after loading, error log is included in the zip.

The bdn xml subs were created with avs2bdnxml (http://forum.doom9.org/showthread.php?t=146493). BDSupEdit loads and outputs them correctly.

0xdeadbeef

29th April 2009, 22:13

These bdn xml subs (http://www.mediafire.com/download.php?knl1nkzh3oz) crashes the gui after loading, error log is included in the zip.

Nope. The Java Virtual Machine crashes on your PC. This is not a crash of BDSup2Sub and the sample XML works ok for me.
I'd assume it's a bug in the 64bit implementation of the JVM - at least that seems to be the most likely solution if your PC is stable otherwise.

turbojet

29th April 2009, 22:30

Must be 64 bit jvm, I wonder how I'd go about reporting that. Any ideas?

Edit: Also I noticed the vobsub output can't be joined with VobSubMuxer (http://www.trustfm.net/divx/SoftwareVobsubMuxer.php?page=VobsubMuxerDownload&b2=1) but it works with dvd subs from gabest vobsub and subtitlecreator. Is there a chance BDSup2Sub vobsub output could be changed to support it?

Edit2: I found out what's causing it.

If you change these BDSup2Sub lines:
# Language
langidx: 0
id: en, index: 0

# Vob/Cell ID: 1, 1 (PTS: 0)

to what gabest vobsub tools produce:
# 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)

It works so the commented lines must have some meaning.

micha019

1st May 2009, 11:17

Hello,

BDSup2Sub is a fantastic tool.
Will there be soon a support to convert *.idx back to *.sup?
Or is it already possible and I can't find the option to load *.idx/sub files?

0xdeadbeef

1st May 2009, 12:01

It works so the commented lines must have some meaning.
Well, a comment is a comment and while it's ok to parse comments to get additional info, I would call a tool buggy that insists on certain comments instead of taking them for what they are.
Still, while I'm not really keen on adding workarounds for bugs in other people's tools I can add that in the next version.

Will there be soon a support to convert *.idx back to *.sup?
Or is it already possible and I can't find the option to load *.idx/sub files?
Currently, there is no support to load SUB/IDX. Then again, chances are that there will be.

turbojet

1st May 2009, 12:25

Well, a comment is a comment and while it's ok to parse comments to get additional info, I would call a tool buggy that insists on certain comments instead of taking them for what they are.
Still, while I'm not really keen on adding workarounds for bugs in other people's tools I can add that in the next version.

Thanks as I have a feeling VobsubMuxer development is dead and while the same type of error had been mentioned in the forum over there in february, all that was offered was a workaround by running it through vobsub resync.

mrr19121970

3rd May 2009, 15:01

I tried what you suggested:

http://forum.slysoft.com/showpost.php?p=194612&postcount=5

but even on my machine it's in:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment

I think it's best for the user to locate their own RTE.

Thanks anyway.

0xdeadbeef

3rd May 2009, 16:52

but even on my machine it's in:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment

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/regdatabase/browse.asp?keyid=387

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

0xdeadbeef

3rd May 2009, 20:16

SquallMX

3rd May 2009, 22:18

Changed too much, tested too little. So chances are I messed some things up. Side note: some (multi packet) VobSubs created by versions < 2.1 can't be imported (since they were indeed partly corrupt). Also the support for VobSub import is pretty basic currently. No detection of fading and other fancy things (yet).

03.05.2009 3.4.3 -> 3.5.0

Changed: added support for importing VobSub (SUB/IDX)
Changed: forced flags are preserved when exporting to VobSub
Changed: added/changed comments in IDX files to workaround bug in VobsubMuxer
Changed: added command line switch (/tmerge) for setting the maximum time for merging (BD-SUP) captions
Changed: end time of one frame can be start time of the next frame (no forced gap of 1 frame any more)
Fixed: assumed number of pixels in odd/even RLE buffers was wrong for captions with odd line numbers
Fixed: scaling of very small captions (like 3x3) could still lead to crashes when using filters with large radius

Hi, :thanks::thanks::thanks::thanks::thanks:, but I found a bug for VobSub input, the timecodes for the input and output files are totally wrong:

http://www.imagechile.net/img/img6_1241384968w.png

http://www.imagechile.net/img/img8_1241385416f.png

Sample Sub:
http://rapidshare.com/files/228836683/Bourne.rar

According to subtitlecreator the timecode for the first subtitle is: 00:00:02,102 --> 00:00:04,139, and for the next subtitle is 00:00:04,238 --> 00:00:07,014, ¿bad timecode parsing?

:helpful::helpful::helpful:

0xdeadbeef

3rd May 2009, 23:41

Yeah, didn't test that much ;)

03.05.2009 3.5.0 -> 3.5.1

Fixed: VobSub: delay was read from wrong position of control buffer (-> wrong end time).

turbojet

3rd May 2009, 23:59

Thanks for the new version.

VobsubMuxer now accepts vobsub output.

shon3i

4th May 2009, 16:18

@0xdeadbeef, what about DVD SUP (+IFO palete) I/O ? VobSub isn't common format for many DVD muxers?

0xdeadbeef

4th May 2009, 17:47

I hate to disappoint you, but this is very unlikely to happen.

SquallMX

4th May 2009, 18:29

@0xdeadbeef, what about DVD SUP (+IFO palete) I/O ? VobSub isn't common format for many DVD muxers?

Most DVD SUP can be converted to VOB/IDX using Subtitle Creator 2.2+, and vice versa.

turbojet

5th May 2009, 07:44

Is there much of a difference outside of headers between BD and DVD sup's?

I would think it would be easier to implement then vobsub actually.

prenz

5th May 2009, 09:55

@0xdeadbeef: Great program, very handy for BD to DVD conversions. One thing though: On VobSub-Export, could you use a Padding Stream (i.e. 0x000001BE) instead of just stuffing 0xFF's till the pack end?

0xdeadbeef

5th May 2009, 11:34

Is there much of a difference outside of headers between BD and DVD sup's?

Both formats have more or less nothing in common. IMHO HD-DVD-SUPs are closer to DVD-SUPs, but still very different.

I would think it would be easier to implement then vobsub actually.
My understanding is that the DVD-SUP stream format should be pretty close to the SUB file of SUB/IDX, but reading the start times from the SUP, determining which the real start and end of the caption and handling the IFO for the palette make quite a difference. Regarding export, writing the palette to an IFO seems very messy.

@0xdeadbeef: Great program, very handy for BD to DVD conversions. One thing though: On VobSub-Export, could you use a Padding Stream (i.e. 0x000001BE) instead of just stuffing 0xFF's till the pack end?
I'm not sure if I can follow you here. The packets/segments are aligned to 0x800 so unused part of a package is filled with padding bytes. In all the samples I saw, 0xff is used as padding byte - probably as this is also the end command.

prenz

5th May 2009, 13:15

Deadbeef, this is about the calculation of stream lengths. Let me show a subtitle pack (this is from DVDLab, as displayed by VobEdit):

[Pack Header]
[0000] Pack identifier (start code) 442 [000001ba]
[0004] SCR (System clock reference) 68 2 156 173 181 99 [44 02 9c ad b5 63 ]
SCR 02725302.177
[000a] Program Mux Rate: 25200 (1260000 BPS) (10080000 bps) 1 137 195 [01 89 c3 ]
[000d] Pack stuffing length: 0 248 [f8]

[Private Stream 1]
[000e] Private Stream 1 start code 445 [000001bd]
[0012] Length 1728 [06c0]

In this particular stream, the private stream doesn't use up all of the 2k of the pack, but just 0x6C0 bytes, putting the end position to 0x6D4 relative to the start of the pack. Unfortunately some parsers expect the next Header Prefix (0x00 0x00 0x01) to follow immediately. If you just put a bunch of 0xFF here, there is no more Header and Stream/Pack-Parsing may crash. The correct way to pad to the pack end is to use a Padding Stream (as shown below). It has the Prefix (0x00 0x00 0x01) and stream ID 0xBE. Add the length (0x126, the remainder to the end of the pack) and then finally pad 0x126 bytes (usually 0xFF as you have seen in most streams).

[Padding Stream]
[06d4] Padding Stream start code 446 [000001be]
[06d8] Length 294 [0126]

You may also encounter streams, where the remainder to pad is less than 6 bytes (what you would actually need to place a padding stream header). If this is the case, fill the Pack Stuffing field of the Pack Header with the byte count of the padding (Byte 13, Bits 0-2)

turbojet

5th May 2009, 13:30

My understanding is that the DVD-SUP stream format should be pretty close to the SUB file of SUB/IDX, but reading the start times from the SUP, determining which the real start and end of the caption and handling the IFO for the palette make quite a difference. Regarding export, writing the palette to an IFO seems very messy.

Oh I forgot dvd sup relies on ifo for palette. While input from dvd sup would be badly colored you do have the option to change palette within the program or with vobsub. Also the ability to get colors from an ifo would help.

As for as export I agree writing an ifo would be a mess but there's an alternative at least with pgcedit by importing/exporting raw clb or rgb txt files. (http://www.mediafire.com/download.php?jtmnxdvmkdd)

Mtz

5th May 2009, 14:00

Changed: end time of one frame can be start time of the next frame (no forced gap of 1 frame any more)
Thank you! If is not difficult, I hope you can force 100-300 ms for the first subtitle if the starting value is: 00:00:00,000
So, if first line start with: 00:00:00,000, to have in the saved SUP: 00:00:00,300 In my tests with MPC-HC and tsmuxer are some problems and also my TViX refuse to play this file and I suspect the problem is that 000 ms. 300 ms can't harm the reading of a subtitle.

enjoy,
Mtz

0xdeadbeef

5th May 2009, 17:16

Deadbeef, this is about the calculation of stream lengths. Let me show a subtitle pack (this is from DVDLab, as displayed by VobEdit):
[...]

I still don't get what this has to do with SUB/IDX export. AFAIK DVDLab doesn't export SUB/IDX and VobEdit doesn't import SUB/IDX for sure. So it seems to me that you confuse VobSub (as synonym for SUB/IDX) with VOB. As the SUB file contains snippets from the SUP stream embedded in the VOB, there are some similarities of course but still it should be clear that a SUB file from SUB/IDX is not a transport stream that can be used directly for muxing.

In this particular stream, the private stream doesn't use up all of the 2k of the pack, but just 0x6C0 bytes, putting the end position to 0x6D4 relative to the start of the pack. Unfortunately some parsers expect the next Header Prefix (0x00 0x00 0x01) to follow immediately.
I'm still not convinced that you're talking about VobSub (aka SUB/IDX) here. A SUB/IDX parser would be pretty much braindead to expect the header prefix after a complete caption as the offset to the next caption is defined in the IDX file. Again: are you sure you're talking about VobSub = SUB/IDX and not about VOB or DVD-SUP???

If you just put a bunch of 0xFF here, there is no more Header and Stream/Pack-Parsing may crash. The correct way to pad to the pack end is to use a Padding Stream (as shown below). It has the Prefix (0x00 0x00 0x01) and stream ID 0xBE. Add the length (0x126, the remainder to the end of the pack) and then finally pad 0x126 bytes (usually 0xFF as you have seen in most streams).

Indeed I'd bet that most tools featuring SUB/IDX import would plain crash if I did so.

0xdeadbeef

6th May 2009, 18:30

06.05.2009 3.5.1 -> 3.5.2

Changed: VobSub: wrong packet length is detected and fixed (-> now SUB/IDX files exported before 2.1 can be imported)
Changed: VobSub: improved luminance threshold detection when importing SUB/IDX files.

prenz

7th May 2009, 08:24

it seems to me that you confuse VobSub (as synonym for SUB/IDX) with VOB.
No, I'm pretty much aware of the differences, although after discussing this with you I'm not too sure if my assumptions about VobSub are correct. Until now I have perceived .sub as a multiplexed program stream with a private stream inside - a subtitle stream according to DVD specs - and the .idx for a bunch of additional information as to e.g. timing, palette, file positions and some other things. Given the fact that .sub looks very much like a program stream, coming with pack and stream headers and all that stuff, I was confused why the packs ended early (because, from a parser's view, after the end of a stream there is either another stream or the end of the pack). Obviously VobSub doesn't care about PS-conformity. Some VobSubs are padded in a PS-conform way (e.g. those generated from DVB-Subtitles by ProjectX), others just fill up with 0xFF (as I have seen in VobSubs created by SubtitleCreator)

VobEdit doesn't import SUB/IDX for sure
You'd be amazed what VobEdit will import. Contrary to its name it will edit any program stream you feed it (but indeed, it will crash on displaying packs #2-n of a .sub that doesn't use a padding stream).

Indeed I'd bet that most tools featuring SUB/IDX import would plain crash if I did so.
You mean if the VobSub used a padding stream? Why do you think so? Anyway, I'd wager against it. :) I'm convinced that a VobSub-Import would simply ignore anything after the end of the pack's subtitle stream (including a padding stream or plain 0xFF-Padding), and will look for the next stream at the file position given from .idx. At least BDSup2Sub and SubResync will import a VobSub + padding stream without problems.

0xdeadbeef

7th May 2009, 11:34

Hm, I would assume that by adding the padding bytes, the SUB would get very close to a (DVD-)SUP. I never really examined the DVD-SUP format closely enough to tell for sure. I kinda fear that if I go in that direction people will jump onto the bandwagon and insist that the SUB is a 100% consistent and muxable DVD SUP stream. And this idea honestly gives me headaches.

BTW: Did you test if tools like MKVMerge and SubtitleCreator accept SUB files with padding? If so, I might consider adding the padding (and it rhymes, too).

Ulf

7th May 2009, 12:34

0xdeadbeef,

BDSup2Sub only treats a "PAL" XML file correctly on import if the video format is specified as "576p" in the XML file. If the video format is specified as "576i" (which is the correct way to specify the format), BDSup2Sub seems to assume that the import format is 1080p.

Could you correct this?
I guess it's the same thing with "480i", but I haven't tried it.

0xdeadbeef

7th May 2009, 15:48

Admittedly, I kinda didn't care much about interlaced formats up to now. Now regarding the BDN XML format the question arises if a frame (for the time stamp) is an interlaced frame or a progressive frame.

mrr19121970

7th May 2009, 17:47

Do you think it would be possible, when executing say:

java.exe -jar BDSup2Sub.JAR '*.sup' '*_FORCED.sup' /res:1080 /forced

to not stop when

#> 1542 (01:38:51.217)
ERROR: No forced subtitles found.
Press any key to continue . . .

is found, but to continue to the next file ?

that would be great.

0xdeadbeef

7th May 2009, 18:42

Yep, will be changed in the next version. Indeed the try/catch-block is already inside the loop, but currently each error exits the program.

mrr19121970

7th May 2009, 18:45

is this likely to happen soon, otherwise I'll change clown_bd - but I'm sure you're faster than me ;)

0xdeadbeef

7th May 2009, 18:59

Just two quick fixes, untested. Ulf, mrr19121970 please have a look.

07.05.2009 3.5.2 -> 3.5.3

Changed: when converting multiple files from the command line, a fatal error will not quit the program but just skip the file.
Fixed: BDN XML: 576i and 480i are used for PAL and NTSC instead of 576p and 480p.

mrr19121970

7th May 2009, 19:24

great, works 4 me. thanks.

Ulf

7th May 2009, 23:18

Fixed: BDN XML: 576i and 480i are used for PAL and NTSC instead of 576p and 480p.

Thanks 0xdeadbeef - works fine! :)

HeartWare2

8th May 2009, 07:53

Thank you for this excellent program. It works fine, but... (there's always a "but" :-))

I have tried - unsuccessfully - to use this program to deliver something that I can process further with SubRip to do OCR scanning of the subtitles, but so far without any luck. I have tried 720p SUB/IDX, which kinda works, but for some pics SubRip seems to not be able to decode the file properly (shows garbage).

The PAL output seems to be processable, but due to the resizing, it is quite often that SubRip can't recognize the same letter as being such, which leads to an awful lot of manual entering of letters.

1080p SUB/IDX doesn't seem to be supported at all by SubRip.

I have also tried the PNG output, which I then converted to BMP using PMView (again 720p), but these files doesn't seem to be properly read by SubRip either.

Would it be possible to have your program output SUB/IDX files in a format compatible with SubRip (f.ex. without RLE encoding or something like that?).

Or if anyone knows about another utility that can du OCR processing on the SUB/IDX files created by BDSup2Sub (preferably the 1080p versions, as these should be clearer and thus easier to do successful OCR processing on).

0xdeadbeef

8th May 2009, 10:31

SupRip?

HeartWare2

8th May 2009, 12:16

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

8th May 2009, 12:58

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

8th May 2009, 15:51

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

8th May 2009, 18:42

@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

9th May 2009, 00:04

0xdeadbeef,

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

mrr19121970

9th May 2009, 14:50

@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

10th May 2009, 16:21

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.

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

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.

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.