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

[alc0re]

0xdeadbeef

Two things...and I know I may just be asking you to repeat yourself. Forgive me, I know nothing about programming. If you take a demuxed bluray sup, and remux it with tsMuxer the bluray plays the sups fine (as expected.) You can't extrapolate the information you need from the original untouched bluray sup to use on the resized one? Now, I'm not expecting you to say yes, as I know if it was that easy you would do that. And I'm not looking for a long answer, partly cause I don't want to bother you with what may seem like stupid questions. What I am looking for is a brief answer...maybe even just a "no, its not that simple." I guess its just trying to satisfy my curiosity as to why its not that simple. It seems like a simple resize would not involve as much as it does, but apparently that's not the case.

Second...is there any way I can donate some cash money? It wouldn't be a huge contribution, but your tool is gonna save me a lot of time and I would like to give you some monetary kick back for your work. Perhaps Paypal?

[turbojet]

Originally Posted by 0xdeadbeef

@turbojet:
Did you try the explorer integration (see first posting or online help)?

Just tried and yes it does work fine on vista x64, thanks.

One thing I'm trying to accomplish now is adding Convert to 720p for .sup files:

[HKEY_CLASSES_ROOT\.sup\shell\Convert to 720p\command]
@="C:\\Program Files\\Java\\jre6\\bin\\java.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" %1 *-720p.sup /res:720"

Is the best luck I've had, it seems to process it but I don't know where the file is outputted, any ideas?

[0xdeadbeef]

Originally Posted by turbojet

One thing I'm trying to accomplish now is adding Convert to 720p for .sup files:

[HKEY_CLASSES_ROOT\.sup\shell\Convert to 720p\command]
@="C:\\Program Files\\Java\\jre6\\bin\\java.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" %1 *-720p.sup /res:720"

Is the best luck I've had, it seems to process it but I don't know where the file is outputted, any ideas?

Probably in the current directory, which is a little vaguely defined in windows (usually something like "My Documents").

The problem is however, that this approach can't work anyway because you're using a wildcard in the target name (only) in a way that BDSup2Sub currently doesn't support. Besides, as the parameters passed to BDSup2Sub are not in double quotes, the Java runtime would try to expand the wildcard which might lead to interesting behavior. Also, as you erased the double quotes enclosing "%1", file names with spaces wouldn't work.

Honestly, I don't think it's a good idea anyway, but if you really need this way of calling BDSup2Sub, I could add support for (one) asterisk in the target file name that would be replaced with the source path+filename without the extension. Even then you'd need a different command string though. I'd also suggest to write the output to a log. This would look something like this (note the double quotes around the parameters passed to BDSup2Sub and the single quotes around "%1"):

@="C:\\Program Files\\Java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" \"'%1' *-720p.sup /res:720\" > C:\\TMP\\%1.LOG"

Note that this wouldn't work anyway currently. For the moment you could try this (no special single/double quotes this time as no wildcards are passed):

@="C:\\Program Files\\Java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" \"%1\" \"%1-720p.sup\" /res:720 > C:\\TMP\\%1.LOG"

This would however create files with two ".sup" extensions.

You could also write a Perl script or whatever that calls BDSup2Sub with an appropriate target file name.

[0xdeadbeef]

Originally Posted by alc0re

You can't extrapolate the information you need from the original untouched bluray sup to use on the resized one? Now, I'm not expecting you to say yes, as I know if it was that easy you would do that. And I'm not looking for a long answer, partly cause I don't want to bother you with what may seem like stupid questions. What I am looking for is a brief answer...maybe even just a "no, its not that simple." I guess its just trying to satisfy my curiosity as to why its not that simple. It seems like a simple resize would not involve as much as it does, but apparently that's not the case.

I can't take the original time stamps for a couple of reasons:
1) BDSup2Sub simplifies SUPs by removing palette/cropping animations and other stuff. So the structure of the SUP usually changes even if a BD-SUP is converted into a BD-SUP of the same resolution.
2) When scaling captions up/down, all the internal time stamps need to be recalculated because they are based on video/image sizes.
3) When converting a HD-SUP into a BD-SUP, there are none of these internal time stamps at all to use for the output file.

Originally Posted by alc0re

Second...is there any way I can donate some cash money? It wouldn't be a huge contribution, but your tool is gonna save me a lot of time and I would like to give you some monetary kick back for your work. Perhaps Paypal?

Despite of all that forced vacations due to the world economic crisis, I'm still in a financial situation that allows me to gently refuse this offer. Indeed, as I said before, I tend to lose interest in my projects after some time, but would feel obliged to implement stuff just because people donated a few bucks.
Anyway, I really prefer to be able to tell people to take it or leave it

By the way, I think I figured out all the offsets in question in the meantime. The calculation is actually pretty simple if you know how do to it. Then again, I also realized that my "guessed" offsets were not so bad after all. Indeed, generally they were (mostly) rather too big than too small when scaling down. So while there will be an update soon with improved calculation of PTS/DTS time stamps, I'm not 100% sure if this will really fix muxing problems with all streams.

[alc0re]

Ok...thanks for the reply. The offer to donate would not hold you to anything if you walked away from the project, but I understand where you're coming from. You seem to be a person with some values, and I would feel the same way about it, even if the person did not intentially mean to make you feel obligated I would still feel that way. Good to hear about the calculations progress.

Another quick question...

With the warnings I get from your program...I get ones about not having ending times that were fixed automatically (does suprip fix these too then without telling the user about it? Cause I've never seen that type of error from suprip. It just outputs the .srt with start and end times.) And the other errors I get sometimes are sub's times being too short...but I'm assuming they were too short in the original sup (obviously, thats where its coming from.) So can I safely ignore that error without using the correct too short option and still have it play on my standalone without issues?

[0xdeadbeef]

Originally Posted by alc0re

With the warnings I get from your program...I get ones about not having ending times that were fixed automatically (does suprip fix these too then without telling the user about it? Cause I've never seen that type of error from suprip. It just outputs the .srt with start and end times.) And the other errors I get sometimes are sub's times being too short...but I'm assuming they were too short in the original sup (obviously, thats where its coming from.) So can I safely ignore that error without using the correct too short option and still have it play on my standalone without issues?

Well, as I already pointed out before, BDSup2Sub expects a start time, one image with one palette and an end time per caption. Any deviation from this scheme will result in a warning - this doesn't necessarily mean though that the stream is corrupt or that the result displayed in BDSup2Sub is invalid. Yet, both could be the case.

Missing end times for example are perfectly valid in VobSubs, HD-DVD SUPs and BD-SUPs. This just means that the caption is displayed until the next subtitle starts. Programs like SupRead display an end time in this case (e.g. start of next frame minus 1ms), but don't export an end time. In contrast, BDSup2Sub shows an end time of "00:00:00.000" in the source window and the "fixed" end time in the target window (which is also used for export). In the end, there shouldn't be much of a difference. The only exception is the very last caption. If it has no end time, BDSup2Sub will force a duration of 10 seconds or so (too lazy to look it up) while the unpatched version would be displayed until the movie ends.

The "too short" frames are usually the result of unexpected (yet probably legal) structures in the stream. E.g. quite a lot of BD SUPs have captions with multiple start sections, often with repeated image and palette data. So a feature meant for animation is used without any obvious reason - maybe because the authoring tool is crap. Still, while preposterous, this is most probably allowed. Still BDSup2Sub now has to decide which (of multiple) start end stop times to use in the end.
While I added several hacks here and there to work around these issues, there still might be cases, where BDSup2Sub uses the start/stop time from the wrong segment/epoch/whatever. Yet I didn't stumble over this issue lately. Still, reworking the start/end detection code to be more robust is already on my list.

Anyway, keep in mind that the presentation graphics stream of a BD is quite a complex beast. It can contain multiple objects with multiple palettes per frame ("epoch"), where images, palette entries and cropping windows can be updated to create all kind of animation/fading/transition effects. Since BDSup2Sub is focused on plain subtitles and conversion of these effects to VobSub would be more or less impossible or at least pointless, BDSup2Sub will never be able to display every fancy (animated) effect contained in the PGS.

[turbojet]

@="C:\\Program Files\\Java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" \"%1\" \"%1-720p.sup\" /res:720 > C:\\TMP\\%1.LOG"

Didn't work even after changing to java.exe, just opened and closed right away. I think the added double quotes are the issue

I also am having no luck getting a log with: > C:\\%1.LOG

@="C:\\Program Files\\Java\\jre6\\bin\\java.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" %1 *-720p.sup /res:720"

actually works with paths/file names with spaces somehow someway, I know with cmd it needs double quotes but maybe java handles ir differently.

I did make a little progress with

@="C:\\Program Files\\Java\\jre6\\bin\\java.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" %1 %1-720p.sup /res:720"

Using this on a file named 00001.track_4614.sup outputs what appears to be a correct 720p file named 00AB71~1.SUP-720p.sup in the working directory.

eng 00001.track_4614.sup outputted ENG000~1.SUP-720p.sup

Any ideas on how I could get the output file named with just the -720 added?

[Rectal Prolapse]

I just want to point out that supread's colors use the wrong colorspace conversion formula (YCbCr to RGB). At least in one of the later versions I tried. As far as I know, MPC-HC uses the correct colorspace conversion formula (I actually provided the formula to Casimir and should be in the MPC-HC main discussion thread). All standalone players should use the same formula, with the addition that some players can be set to expand to PC levels (ie. PS3 Full Range option instead of Limited).

Colorspace conversion should follow BT.709 (aka SRGB), with video levels (where black is at 16 and white is at 235).

This is just an FYI message...I have not used BDSup2Sub. I don't remember what suprip does for color conversion.

[0xdeadbeef]

Originally Posted by Rectal Prolapse

I just want to point out that supread's colors use the wrong colorspace conversion formula (YCbCr to RGB).
[...]
This is just an FYI message...I have not used BDSup2Sub. I don't remember what suprip does for color conversion.

Do you mean slightly wrong (e.g. by using the full 0..255 range) or completely wrong due to swapped Cr/Cb?
As I said, due to certain input (*hint*), I'm now 100% sure that the color order is Y,Cr,Cb and not Y,Cb,Cr. Since BDSup2Sub uses Y,Cr,Cb and displays the same color as a PS3 does for the very same SUPs, I'm almost 100% certain that the colors displayed by BDSup2Sub are accurate (letting aside calibration, gamma etc.). If BDSup2Sub would display the wrong colors due to a bug in the RGB<->YCbCr conversion (which is very unlikely, since I checked it again and again), this would also mean that the PS3 shows wrong colors.
BTW: currently I'm using a color space conversion according to BT.601. Dunno how much this differs from BT.709, but it looks ok for me (compared to PS3). Keep in mind that video color space conversions are based on gamma corrected RGB, not on linear RGB that's used by PCs. So a 100% perfect color reproduction is kinda unlikely anyway.

Since SupRead shows the same colors as BDSup2Sub and SupRip doesn't, this makes SupRead right and SupRip wrong in my humble opinion. Again: is it more likely that the PS3 is right and SupRup screwed it or the other way around? Yeah, that's my guess, too.

@turbojet:
I'm a little surprised that the double quotes are not needed, but you seem to be right. Most probably windows adds them automatically if the file name contains spaces or other problematic characters. Anyway, either with or without double quotes filenames with spaces won't open with my proposed default shell integration. I think I now why, yet the automatic quoting of windows makes things a little complicated. I'll have to investigate.
Whatever: regarding your special case, support for a wildcard in the target string will be added in the next release. The asterisk (only) in the target string will be replaced by the full source file name (including path, but excluding extension).

Then again, I just started a major rework of the whole BD-SUP start/stop segment detection, so this may take a while.

[turbojet]

Ah no rush, it's just a little convenience that probably I'd only use unless you were to put it in as an option.

[0xdeadbeef]

Actually I made good progress and it looks as if I could release a new version today. Yet, after some testing, I have to correct my above statement: as I originally assumed, the double quotes around "%1" in the registry command string are necessary for file names with spaces. It's only that BDSup2Sub currently assumes one parameter with spaces inside it to be a wildcarded full CLI call. I already added a workaround for this locally, but this only works as expected if "%1" is inside double quotes.
Currently, it's beyond me why the unquoted version would work for you...

[magic144]

Any chance of an enhancement to allow/compensate for cropped encodes of the source.

i.e. Original video is 1920x1080, cropping is done to leave output at 1920x800 (sometimes rescaling is done too to produce 1280x528, but we'll leave that aside for now)

First step would be to do what can be done with BDSup2Sub already - ensuring all subs are moved INSIDE the picture area.
Second (new) step would be to recalculate sub positions so that 0,0 would now be top-left of the cropped area (and 800 would be the maximum Y-coord extent).

Anyway, I don't know how the code is structured, but I presume this wouldn't be a major undertaking and it would be a fantastic feature for anybody who does these 'cropped encodes'.

[0xdeadbeef]

Hm, I think all that's needed to handle this would be a freely definable output resolution, as BDSup2Sub scales width and heigth independently anyway. The only issue would be that the preview windows would be somewhat bound to a 16:9 resolution. So they would show a distorted picture and the cinemascope bars would be off.

[magic144]

Hmm, well the preview window shows what you're doing to the input space/coords (which is still uncropped anyway). This doesn't need to change I don't think - you still want to visually make sure that the first step (repositioning the subs to be INSIDE the 'scope bars) is doing the right thing.

You'd just need a checkbox or something to indicate that the output coordinates would only be relative to the PICTURE area (and not the WHOLE SCREEN). Or am I barking up the wrong tree?!

[0xdeadbeef]

Originally Posted by magic144

Hmm, well the preview window shows what you're doing to the input space/coords (which is still uncropped anyway). This doesn't need to change I don't think - you still want to visually make sure that the first step (repositioning the subs to be INSIDE the 'scope bars) is doing the right thing.

Then again, if you'd ask me (and something tells me that I might have a little more insight into the inner workings of BDSup2Sub), the preview window does what its name implies: it's a preview of the exported target.

Originally Posted by magic144

You'd just need a checkbox or something to indicate that the output coordinates would only be relative to the PICTURE area (and not the WHOLE SCREEN). Or am I barking up the wrong tree?!

Maybe. The preview windows is based on the idea of a 16:9 aspect ratio. When the image is cropped, this changes the aspect ratio to something else and BDSup2Sub can't really know what it is then.

Then again, I wonder why you would care about the preview windows anyway. If one could set the target screen size to the cropped screen size, there wasn't even any need to move the subtitles at all, because they would be inside the given target resolution anyway.

The only problem with this approach is that the cropped size would also be stored inside the IDX or SUP file (dependent on the output format). Since this is non-standard anyway, I can't really tell what your player expect there. How does it know that the image is cropped and what was its original aspect ration anyway?

[magic144]

well I certainly don't mean to presume to tell you how BDSup2Sub works !!! :-)
It is the first and only useful BD sup tool to come out that doesn't involve OCR, so it is a breath of fresh air

Having the target screen size be the cropped screen area would be a bonus. In so doing, I would not want/expect the aspect ratio of the subs to change. It would merely be a translation of the subtitle coordinate origin (0,0) from the original top-left (inc. black bars, in a screen 1920x1080) to the 'new' top-left - again (0,0), but with a new range of 1920x800 in this example.

i.e. a letter of 50 pixels in height would still be 50 pixels in height in the output space.

I can do this somewhat artificially right now by editing the idx file. If I maintain the output size to be 1920x1080, I can adjust these lines:-

org: 0, 0
to
org: 0, -189

and

scale: 100%, 100%
to
scale: 100%, 135%

(there being 140 pixel crop at top and bottom of original video, and 140*1.35=189)
where 1.35=1080/800

however this involves scaling, since the video is being rendered at 1920x800 but the subtitle coordinates are 1920x1080 still, therefore I have to artificially adjust the subtitle Y-axis.

if the subs were already limited/constrained to 1920x800 coordinate range, I could leave the idx file alone :-)

fyi, I am using ZoomPlayer with VobSubFilter

[0xdeadbeef]

Hm, what about this:

I could add a "crop offset" input field to the "move captions" dialog. Default setting is 0. If it is changed to e.g. 100, a colored line is displayed in the preview pane that is 100 pixels below the top of the screen. When moving captions, this would also be the upper limit - no caption could start above that line.
When exporting, every y-position is than simply decremented by that cropping offset.

Wouldn't be fancy, but easy to implement and should fix your problem.

[magic144]

That sounds like just the ticket! Would be great to try.

[0xdeadbeef]

Originally Posted by magic144

That sounds like just the ticket! Would be great to try.

Ok, it's pretty likely that this will be added in the next release. At least if I don't need the next one as panic release to fix the bugs introduced in this one:

05.04.2009 2.8 -> 2.9

• Changed: DTS (and internal PTS) time stamps are calculated now based on decoding and composition pixel rates. Should hopefully improve muxing results of exported SUP streams.
• Changed: improved detection of start/end of caption - should result in less warnings and better handling of problematic SUPs
• Changed: better handling of BD-SUP palettes (multiple IDs, palette update, alpha blending detection)
• Changed: much more flexible handling of CLI parameters. Options are allowed now even if no target file name and/or no source file name is given.
• Changed: support for one asterisk in target file name even if there is no wildcard in the source file name. The asterisk will be replaced with source path+filename without the extension.
• Fixed: calling BDSup2Sub with source file name as only parameter would fail if the file name contained spaces. Now it should work with all file names as long as they don't have multiple SUP/SUB/IDX extensions in them.
• Fixed: when changing the caption number in the edit and move dialogs, the wrong caption number was displayed after returning to the the main view.

Note that this is really a major update regarding BD-SUPs and will lead to different results than 2.8 in certain cases. Since I'm not so keen on regression testing, chances are that 2.9 will behave worse than 2.8 for selected SUPs. I sure don't hope so though and some complex SUPs that were completely screwed before look almost perfect now. So just give it a try.

[magic144]

Thanks for another new release.