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

[rizu]

You're welcome, although by experience, there's usually a "but".
As always :) But I like this SW as it is already, I currently use it to convert blu-ray subs to 1080p nonscaled vobsubs so I can mux my hd movies to mkv, no other SW can do it as far as I know :)

Ok, this sounds like a use case. Although I'm not 100% sure if I'd implement it this way if I would.
There are few drawback, sometimes subs are positioned differently just to avoid burned in subs or text on original movie but colliding on those with this kind of algorythm should be a rare case because such subs are already repositioned above normal position.

There are other ways around of course, like using resolution 1920x800 and some zoom mode for video on such playback SW where subs have fixed position. I'm currently playing with different ideas so it's hard to say directly what would work out best.

When I look into my blu-ray/hd dvd collection I'd say around half of the titles have subs inside the video frame and others are like on normal DVD release, partly outside the video frame.

There's no such tool for SUB/IDX? Or which type of captions do you export?
I doubt current tools work with 1080p vobsubs ;)

BTW: Changing Y position alone would be no complete solution. I stumbled over subtitles which nearly fill the whole screen vertically, since there's an upper line above the picture and a lower line below the picture. In this case, the described algorithm would fail, since the subpicture would need to be scaled down.Agreed, that's why suggested to leave such frames unaltered and tell user about it. Scaling would be ideal but may make overall algorythm just more complicated? Anyways there are not many such cases anyway.

Would be nice to know if there are any other having same kind of ideas, I mean I can't be only one considering wider screen and needing subtitles at the same time :)

[cavediver]

I just discovered this tool today and I must say I'm impressed. I prefer subtitles to be positioned in the black bar below the image in 2:35 movies. While BDSup2Sub can do this, I could only figure out how to do it frame by frame. Would it be possible to implement some sort of global repositioning box so all subtitles can be repositioned at once?

[0xdeadbeef]

Damn, I can feel the pressure increasing to implement such a feature. Let's say, I'll consider it, ok? Dunno though how motivated I'll be the next days...

[laserfan]

I prefer subtitles to be positioned in the black bar below the image in 2:35 movies.Ha, ha! Cuz I need to get the subtitles INTO the 2.35:1 frame so I can project onto my 'scope screen!

Currently I make an .srt, then re-create and re-position using tsMuxeR, but if this tool could just re-pos the original sups that might work too (though now that I think of it, this may put the original sups too high into the picture).

[turbojet]

Hopefully these pics will take out the confusion.

Clockwise from upper left: MPC-HC, 720p in suprip 1.13, 720p in supread, 1080p in bdsup2sub set to resize to 720p, 720p output in bdsup2sub

no swap in 1.26 (http://tinypic.com/view.php?pic=2ebxpur&s=5)

swap in 2.6 (http://tinypic.com/view.php?pic=9zlx1f&s=5)

bdsup2sub 2.4 (http://tinypic.com/view.php?pic=520rjr&s=5)

panasonic BD30 shows what mpc-hc and suprip see in these cases.
the original 1080p source appears blue in bd30, mpc-hc and suprip, supread doesn't display.

to enable bdsup in mpc-hc you need to choose vmr windowless, haali or evr in options > playback > output, restart the player, then choose from navigate > subtitle language

if PS3 and BD30 are showing different colors I think there is an issue with bdsup2sub's color palette as the original displays blue on both players.

[0xdeadbeef]

Hopefully these pics will take out the confusion.
Well, if MPC-HC shows a SUP in this case (which is hard to tell), then this only proves that it uses the (inverted) color order that SupRip does, but not the one that the PS3 does.

panasonic BD30 shows what mpc-hc and suprip see in these cases.
You kinda avoid talking about the original BD. How does it look like on the Panasonic? Or what is the "original source" exactly?

to enable bdsup in mpc-hc you need to choose vmr windowless, haali or evr in options > playback > output, restart the player, then choose from navigate > subtitle language
OK, I'll try this later.

if PS3 and BD30 are showing different colors I think there is an issue with bdsup2sub's color palette as the original displays blue on both players.
That's obviously a wrong assumption, as BDSup2Sub "has" not palette. It uses the frame palette defined for each frame of the SUP. Then again, if (and I'm not yet convinced that this is the case) the Panasonic shows different colors than a PS3 for the same original BD, there seems to be confusion about the color component's order even among different hardware vendors.
In this case, the definition in the BD specs was somewhat worthless anyway and BDSup2Sub way to handle it (via swap option) was the only possibility anyway.

[jonathonsunshine]

Since the automatic (language) detection is only based on the file name, it doesn't work reliably enough to use it without any user feedback. Imagine titles like "French Kiss" or "Italian Job"...

I think your forgetting thou, EAC3TO and TSDEMUX and realistically, any program that is going to demux streams from something, will put the base title at the start of the file name, from EAC3TO for example, the english subtitles from "The Italian Job" would come out as

"The Italian Job - 10 - Subtitle (PGS), English, 1467 captions.sub"

so BDSup2Sub simply needs to load the LAST language found in the file name.


Also, for what its worth, the GUI successfully detected the following languages for me, granted, in a file name without conflicting language codes.

Italian, Spanish, French, Japanese, Korean, Swedish, Dutch... only one I found that may be a bug (or perhaps only my ignorance) is detecting what EAC3TO described as "Modern Greek" as "Greek"...

Also, your program rocks. But it still needs a switch for loading language tags automatically from the command prompt. If you think it is an issue then just turn it off by default, but I have a dream of dropping 15 sup files on a batch file...

[turbojet]

Well, if MPC-HC shows a SUP in this case (which is hard to tell), then this only proves that it uses the (inverted) color order that SupRip does, but not the one that the PS3 does.


You kinda avoid talking about the original BD. How does it look like on the Panasonic? Or what is the "original source" exactly?


OK, I'll try this later.


That's obviously a wrong assumption, as BDSup2Sub "has" not palette. It uses the frame palette defined for each frame of the SUP. Then again, if (and I'm not yet convinced that this is the case) the Panasonic shows different colors than a PS3 for the same original BD, there seems to be confusion about the color component's order even among different hardware vendors.
In this case, the definition in the BD specs was somewhat worthless anyway and BDSup2Sub way to handle it (via swap option) was the only possibility anyway.

Look again, I said BD30 and PS3 (USA) display the original as blue.

SupRip 2.4 or earlier works correct

Since 2.5 the inverse of the gui is what's being displayed on BD30. If gui shows blue the BD30 will show yellow with a bunch of orange spots and it's very difficult to read. If gui shows yellow BD30 shows blue.

I don't know how it is for Iron Man, if I had access to the sup I'd try it out.

But for now I will just stick to 2.4 as I don't want to play this guessing game with colors. At least until BDSup2Sub is fixed or I come across a colored sup that doesn't keep it's correct colors.

Thanks for the app anyways.

[0xdeadbeef]

Look again, I said BD30 and PS3 (USA) display the original as blue.
No, in fact you didn't. You said "if PS3 and BD30 are showing different colors" (which in the context sounds like a speculation), but you never said you actually tested it on a PS3. And even after I insisted twice, you don't talk of a BD, just of an "original".


SupRip 2.4 or earlier works correct

No offense, but sentences like this make it hard to tell which of your statements are correct and which are misleading.


Since 2.5 the inverse of the gui is what's being displayed on BD30. If gui shows blue the BD30 will show yellow with a bunch of orange spots and it's very difficult to read. If gui shows yellow BD30 shows blue.
I guess it's futile to repeat that 2.5 had a bug which stored colors as YCbCr, although YCrCb was read and displayed. But even then I can't really understand how this would lead to orange spots.

Just in case that this is still not 100% clear: when exporting SUPs, BDSup2Sub doesn't touch the palette at all. Neither colors are altered nor added. The only possible change to the palette is swapping the Cr and Cb components if (and only if) the swap option is active. This is what 2.5 always did by mistake.
Or to put in other words: the fact that 2.6 displays (!) different colors than 2.4 has no influence on the saved palette at all as long as you store a SUP. Conversion to SUB/IDX is based on the actually shown colors of course.

But for now I will just stick to 2.4 as I don't want to play this guessing game with colors. At least until BDSup2Sub is fixed or I come across a colored sup that doesn't keep it's correct colors.
Well, you seem to be kind of unconvincable regarding this topic, so it's probably pointless to tell you that your refusal to use 2.6 is mainly based on wrong assumptions. I just hope that your misjudgement doesn't influence other users.

Let me put it this way: maybe the color model or at least he order of the Cb and Cr depends on some information in the original M2TS stream. E.g. it could be possible that it's bound to the video codec. If so, this information is gone in the ripped SUP stream. As far as I can tell, there's nothing in a SUP stream that would tell me if the colors are stored as YCbCr or YCrCb.

The only thing I can tell is that if I demux the M2TS of the German edition of "Iron Man" with EAC3TO, the color order needed to reproduce the colors displayed on a PS3 is YCrCb.
If there are discs or other circumstances which need YCbCr instead, I implemented the swap option, which makes BDSup2Sub behave exactly as it did before version 2.5 regarding SUB/IDX. For SUPs, 2.6 (with disabled swap option) behaves exactly like 2.4 anyway despite of the different colors displayed.
To claim that only 2.4 behaves "correct" and 2.5 and above lead to a "guessing game with colors" or simply "incorrect" colors, is therefore not really reasonable. The opposite is true: BDSup2Sub 2.6 gives you much more control than 2.4 did (or any other tool does).

BTW: I tried MTC-HC (1.2.990.0) with different output settings (EVR, EVR custom pres., VMR9 (windowed), VMR9 (renderless) - Haali was greyed out) and none of them showed any subtitle of any original (decrypted, but otherwise untouched) M2TS I tried. Now I updated to 1.2.1015.0 and it displays subtitles. But as I already guessed, the colors are different to what the PS3 shows (yellow is cyan, cyan is yellow).

[turbojet]

Have you even looked at the pics?

If you have and read what I wrote you should know what I mean by 2.4 being correct and a guessing game with 2.5 and 2.6 as far as Panasonic BD30, SupRip, MPC-HC, PowerDVD, ArcSoft TMT, WinDVD, and BD Rebuilder is concerned. I really would expect to get the same color output the gui shows me which has been the case up until 2.5

Have you even tested the sup I'm working with that's still available (http://www.sendspace.com/file/m1t7m0)?

Take that sup and see what color the original is on your PS3 and also see what colors are shown after running it through BDSup2Sub both swapped and unswapped and report back.
This way you can prove or disprove my assumption that if the original plays with the same color on all players but different then blue when ran through BDSup2Sub unswapped there's something wrong with BDSup2Sub's output.

Anyhow unless you test my sup I don't want to spend any more time trying to explain it through words to you.

[0xdeadbeef]

Have you even looked at the pics?
[...]
I don't think you'll ever seem to understand it without trying it yourself and I'm not appreciating being called a liar when I'm just trying to help.
I completely understand your assumptions and explained in detail which of them are wrong and why. I'm not quite sure how to explain this in more detail or if this would make sense at all, since you seem to be pretty much unconvincable.

[turbojet]

What are you trying to convince me of?

The least we could do to figure this all out is work with the same source.

I can't discuss the Iron Man subs at all with you as I don't have them to test, the subs could yield completely different results for me.

It could also be your PS3 doesn't agree with other players including USA PS3, which hopefully I'll get to check out soon with swapped and unswapped. I already know of a case where PAL PS3's played some BD5/9 with menus while USA PS3's don't. You don't need to try and tell me I'm right or wrong about this, I'm only stating it as a possibilty.

[0xdeadbeef]

Just re-read my postings. I invested quite some time to explain this to you, so it would be at least polite to read it. You also wouldn't need to ask "if I even had a look" at your example then.

[turbojet]

Sure I've invested a few hours trying to explain it to you as well, even going as far as making pics, next step would be to do it on your computer.

I don't see anything concerning the sup I used in your posts, but I do see some of Iron Man.

Anyways this is getting nowhere, if you don'r understand it by now I give up.

[0xdeadbeef]

Sure I've invested a few hours trying to explain it to you as well, even going as far as making pics, next step would be to do it on your computer.
If you still think this would change anything, you haven't read my postings (carefully enough).

I don't see anything concerning the sup I used in your posts, but I do see some of Iron Man.
Which goes to show how carefully you read my postings.
http://forum.doom9.org/showpost.php?p=1267198&postcount=150
Yeah, Iron Man sure loves his sake.

Anyways this is getting nowhere, if you don'r understand it by now I give up.
Yes, must be me :rolleyes:
Or wait, wasn't I the author and you the guy who didn't even recognize his own SUP. Hm?

[0xdeadbeef]

31.03.2009 2.6 -> 2.7

Changed: added option to move all captions inside/outside bounds (typically the cinemascope bars)
Changed: temporarily added workaround for (what I consider) a bug in SupRip's RLE decoder
Changed: automatic language selection also from the CLI if no language is given explicitly

[turbojet]

Basically it all comes down to a disagreement on what colors should be shown in te gui.
I understand why you want it to display supread colors for your PS3 hopefully you can understand why I prefer the old way which was suprip colors for BD30 and various software players. I found out PowerDVD 7 and Arcsoft TMT3 display supread colors, while PowerDVD 8 and TMT2 display suprip colors.

It's unfortunate there isn't standard way of displaying these colors. Anyhow maybe you could add an option thats read from ini to invert gui colors to suprip in the future?

Also is drag and drop and/or open with from context menu possible?

[0xdeadbeef]

Basically it all comes down to a disagreement on what colors should be shown in te gui.
Exactly. This of course also reflects the obvious confusion about the color order amongst different tools and obviously even standalones.


I understand why you want it to display supread colors for your PS3 hopefully you can understand why I prefer the old way which was suprip colors for BD30 and various software players. I found out PowerDVD 7 and Arcsoft TMT3 display supread colors, while PowerDVD 8 and TMT2 display suprip colors.
Then again, as I said, as long as you export SUPs, It's completely irrelevant how the colors are displayed in BDSup2Sub as it doesn't change the palette (as long as the swap option isn't activated).


It's unfortunate there isn't standard way of displaying these colors. Anyhow maybe you could add an option thats read from ini to invert gui colors to suprip in the future?
I'm not quite sure what this would be good for since it wouldn't add any functional benefit over the swap function but make this matter even more confusing.

Also is drag and drop and/or open with from context menu possible?
Drag'n'Drop should be possible, but integration into the Windows explorer is nothing that can be handled from Java. It should be possible to create a registry entry though with an external script or probably by just importing a ".reg" file. Then again, BDSup2Sub currently doesn't accept only one command line parameter. This should be easy to add though.
Let' say I'll consider these suggestions.

[cavediver]

I just downloaded 2.7. Thank you for the new ability to move all frames out of bounds for 2:35 material.

[rizu]

Thank you :) I like the way you implemented it.

[jonathonsunshine]

and thank you for auto language selection from command prompt

[0xdeadbeef]

As a side note, I am certain now, that the colors are stored as Y, Cr, Cb in a Blu-Ray PDS segment. This means that the colors displayed by SupRead, BDSup2Sub and my PS3 are correct.

[rizu]

I found a weird HD DVD sub which puts BDSup2Sub to deadlock (just freezes on 0%).

It's evodemux stream but eac3to demuxed worked just the same way. If I try to import stream directly it freezes. If I use supRead and export it to BD sup and then open in BDSup2Sub there's about half of the subs giving error about subs ending before starting so I guess there is something messed up on original authorization :) For some reason TMT2 shows muxed BD with supRead subs just fine.

[0xdeadbeef]

02.04.2009 2.7 -> 2.8

Changed: added drag'n'drop support
Changed: if one parameter (which is neither "/?" nor "/help") is given, it's used as input file for the GUI
Fixed: HD-DVD-SUPs: next DSCQ is checked to avoid endless loops.

[alc0re]

I mean this in the kindest of ways...but I wish you as the developer would pursue fixing the output bd .sup so that it worked muxing with tsMuxer for avchd/bluray playback. I know you've said you need someone to respond to your asking for help regarding this issue...but the only way anyone is going to see that are the people that know about your program (and read the whole forum thread), and they for the most part are not developers with the knowledge to help with that issue. My wish is that you would pursue the developers of bd-rebuilder and/or tsMuxer for some help on this issue. This tool is very promising but its still lacking that feature. Now I know you're going to take my request that you pursue the issue with other developers with a grain of salt, since you are obviously not getting paid for developing this program, but I know I would be more than happy myself to pay for a program that could resize the original .sup to 1280x720 and have it work in a muxed avchd/bluray format. I appreciate your work on this program...if you don't have the time to fix this issue oh well. Thanks for your hard work on this program.

[turbojet]

Thanks for the drag and drop, works well.

alc0re: I have resized to 720p sup, muxed with tsmuxer 1.8.18-1.8.34 and they worked correctly on Panasonic BD30 and PS3. I've done this on about 15 so far.
Is it the Panasonic BD35 you are having issues with?
Have you tried other sups other then get smart?

[alc0re]

Yah I only tried it once. It was on my BD35 with the Get Smart subs.

I'll try it again with a different movie on my next transcode.

EDIT : Trying on Kung Fu Panda now...its burning.

EDIT 2 : Kung Fu Panda sup convert to 720 on BD35 works. I'll try it with more tomorrow...crossing my fingers as ocr'ing takes too much time and is error prone. I would love to be able to take that step out of the process.

[0xdeadbeef]

@rizu:
2.8 also fixes the problem with you stream. About the warning: while it's completely legal in HD-SUB and BD-SUPs to have no end time (which will just display the caption until the begin of the next caption), I decided to force end times as this allows me to export always exactly the same stream format. So a warning displayed by BDSup2Sub doesn't necessarily mean an authoring bug. Indeed palette and cropping animations will also generate warnings as BDSup2Sub can't (or doesn't want to) really handle them.
Let's put it this way: a warning usually just means that BDSup2Sub doesn't like a certain stream structure and therefore isn't sure that the decoded caption is really correct.

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

@alc0re:
As I already pointed out, the matter is a little more complex than it might seem. In a nutshell the problem is that a player needs a certain time to decode the different parts of the subpicture to be able to display it at the scheduled time stamp.

There are several additional time stamps in a transport stream that tell the player when to load a segment into its decoder so it's ready for display when it's needed. Since calculation of these timestamps is a little tricky and depends on buffer sizes and decoding frequencies, this is typically handled by the authoring tool. Since e.g. SUB/IDX files (and also HD-DVD-SUPs) don't contain this information at all, it's completely up to the muxer or authoring tool to create these time stamps.

For whatever reason though, the guys who defined the BD-SUP format decided to let these time stamps in the demuxed SUP and most obviously, tsMuxer also uses them (without any further correction (?)) for Muxing. So now it's up to the tool that creates the SUP to somehow create these timestamps. As I already pointed out BDRebuilder cheats around this by simply not touching any relevant data and only moving the display offset (resulting in too big captions that may be partly outside the screen). I'm not quite sure about the BD-SUPs that SupRead exports if the source was a HD-DVD SUP. It seems to create at least some of the timestamps. Can't say how correct they are though.

Anyway, currently BDSup2Sub uses static offsets (derived from some untouched SUPs exported by TsMuxer) to write more or less plausible values to these time stamps. Since they are not calculated and in no way related to the size of the segments or size of the caption, it's very likely that a player might get into trouble if it implements the buffer/speed limitations exactly and not muxer/authoring tool fixes the time stamps. This is especially likely for standalones, since due to memory/performance limitations, they have to rely on the offsets much more than a software player running on a high end PC.

Then again, I was recently provided with some useful information that might help me to improve the situation. I'm actually currently digging through this and am kinda optimistic that I find a way to actually calculate the offsets instead of guessing them. It's kind of a major task though and may take a while.

Also keep in mind that in the end, it's the muxer/authoring tool that has to put the pieces together correctly. It shouldn't be forgotten that replacing an M2TS transport stream with another one muxed with some free Muxer is a hack. It might work with some players/movies and it might not with others. We're really still in the stone age of re-authoring BDs and due to the complexity of the BD format and the fact that every (real, not AVCHD) BD must have AACS (which makes free authoring tools either illegal or pointless), chances are this won't change soon.

[alc0re]

Thanks. I appreciate your feedback and a better explaination of the problem. Helps me understand what's going on.

PS. I just tested, and the output bluray .sup file from your newest version does not crash suprip anymore. :)

[rizu]

Thanks, that HD DVD stream works like a charm now :)

About your reposition routine, while it works, it still makes subs jumpy as it always calculates sub position by lowest point on current bitmap. For example sub with any of y,g and q will be basically positioned higher than subs where font doesn't reach below normal level. Sub jumpiness is noticed especially if subs are positioned close to actual video frame as you kinda remember the gap to the frame.

I can see few ways around this, first would search through all frames and get the lowest and highest bitmap positions on all subs and use it to calculate the amount subs which need to be repositioned..

Other simpler way would just mark the first found low and high position after repositioning.. eg if first low bitmap was lifted by 41px then lift all the rest by same amount too if lift value is somewhere around +-15px, that way you could keep subs from bouncing and not needing to go through all subs before determining a good value.

As a side note, I'm kinda exicited how current HD sw tools are working now that time has passed from the early days. I can pretty much backup my entire HD collection and view those films now in about every mediaplayer without sacrificing picture or audio quality :)

[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]

@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]

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]

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.



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]

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]

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]

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.



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]

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.