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

[0xdeadbeef]

Ok, let's say I changed my mind about editing ;)
Anyway, this release includes a major internal rework, so chances are again that I broke some things here and there.
I kinda wished I had used a more sensible system of revisions from the beginning, but indeed I never planned to include half of the features that are in now.
One good thing about the world economic crisis you might say as major parts of BDSup2Sub were written during forced vacations and short-time work.

22.03.2009 2.2 -> 2.3

Split export dialog into conversion dialog and export dialog.
Completely reworked the time stamp check. It's done at import now, not at export
Also the source time stamps are not altered any more to fix missing/invalid times.
Added edit dialog to change offsets and timestamps
Added check/fix possibility for very short display durations. Also new command line option "/tmin".
Automatic selection of language for SUB/IDX export if filename contains language name (e.g. "spanish")

[hubblec4]

22.03.2009 2.2 -> 2.3

Split export dialog into conversion dialog and export dialog.
Completely reworked the time stamp check. It's done at import now, not at export
Also the source time stamps are not altered any more to fix missing/invalid times.
Added edit dialog to change offsets and timestamps
Added check/fix possibility for very short display durations. Also new command line option "/tmin".
Automatic selection of language for SUB/IDX export if filename contains language name (e.g. "spanish")


wow amazing. it looks so good.
i will test it in the next time.

so i need no more another programm to convert my BD.sups!
GREAT THANKS TO YOU.

hubble

[hubblec4]

22.03.2009 2.2 -> 2.3


Automatic selection of language for SUB/IDX export if filename contains language name (e.g. "spanish")


ok this feature are very bugy. german, english and turkish works correct but all other language not. when i want save the file it shows me ever French(fr).

test it with:
Thai
Portuguese
Spanish
Polish
Icelandic
Hungarian
Hebrew
Modern Greek
Czech

hubble

[hubblec4]

00001 - 12 - Subtitle (PGS), Czech, 627 captions.sup
00001 - 13 - Subtitle (PGS), Modern Greek, 629 captions.sup
00001 - 14 - Subtitle (PGS), Hebrew, 634 captions.sup
00001 - 15 - Subtitle (PGS), Hungarian, 628 captions.sup

demux by eac3to3.14 (switch, -demux)

hubble

[0xdeadbeef]

Works for me!?

[hubblec4]

Works for me!?

mmh sorry for me not:confused:

[0xdeadbeef]

This leaves me puzzled. I tried with about ten different languages. No matter what I do, the language pre-selection works like it is supposed to.
Can anybody else confirm a problem with this feature???

[alc0re]

Converted .sup from get smart bluray to 720p...muxed with tsmuxer, played on my panasonic bd35 bluray player. No subtitles shown. :(

Back to using suprip for now I guess.

[0xdeadbeef]

Well, I would mostly blame the person who decided to include all that damn additional PTS and DTS stuff in the BD-SUPs. Compared to HD-DVD-SUPs, BD-SUPs are really a complete mess and obviously most authoring tools are kinda broken too if you look at all the garbage and redundancy that can be found in a typical BD-SUP.

Anyway: as long as nobody answers my according thread how to exactly calculate these various additional PTS and DTS timestamps, there's nothing I can do about this.

Most probably however, nobody (except the TsMuxer guys maybe) can answer this question at all because IMHO it's the muxer that has to fix all the time stamps of the muxed streams. All it should care about regarding the SUPs are the timestamps for start and end - which are correct almost certainly in the SUPs created by BDSup2Sub. If the Muxer can do this for SRT subtitles, I can't see any reason why it shouldn't be able to do this with BD-SUPs as well.

[~bT~]

Can anybody else confirm a problem with this feature???

yes i can confirm. tried with hellboy and king kong so far.. ger is being detected always even tho it should be eng.

[0xdeadbeef]

Was there an "english" in the name(s) at all? "tried with Hellboy" doesn't really tell that much.
Again: what this feature does is simply scan the input file name for one of the integrated language names ("Spanish", "English", "German", "Norwegian" etc.). If there is no language given in the file name or if it's misspelled, then there's nothing to detect.

[~bT~]

^ my bad. it works as intended :)

[Pati]

Many many thanks 0xdeadbeef for this very useful tool!

However, I do have a problem with the subtitles of one HD-DVD I want to convert to Blu-Ray. Or actually two problems:

1) All the subtitles show all black (or rather, they show nothing).
2) All the subtitles have a duration of 28ms. The starting times seem to be correct, though.

Since the log of BDSup2Sub displayed offsets to the SUP file (a very useful feature, thanks for that!), I managed to do some debugging of this problem with a HEX editor. This is what I found:

1) The subtitles seem to show only black because all "Alpha Info" buffers/tables are filled with hex code 0xFF, instead of 0x00 like in a working HD-DVD SUP file I tested. I tested what happens if I just clear the buffer (rewrite 0x00 over all the 0xFFs), and after I did that to the first subtitle and reloaded the SUP file into BDSup2Sub, the first subtitle showed up fine. I tried the same thing to the second subtitle and that showed up fine as well.

It looks to me like 0xFF should be handled similarly to 0x00 in Alpha Info table. No tool I tried (BDSup2Sub, SUPRead and SupRip) seemed to do this, though. I don't understand *why* 0xFF should be the same as 0x00, but at least that way the subtitles seem to be shown correctly. Also ,it looks like I am not the only one that has encountered this problem: http://forum.doom9.org/showthread.php?p=1255086#post1255086

2) I also compared the timestamps of my problem SUP with a working SUP file, and found out that the timestamp hexcodes of my problem SUP are like this:


#1
DCSQ start ofs: 0x00002af9 (00:00:55:026) 00 00 00 00 2F 09 01
DCSQ stop ofs: 0x00002f13 (00:00:55:054) 00 02 00 00 30 11 84
#2
DCSQ start ofs: 0x000066f0 (00:00:57:262) 00 00 00 00 2D 88 01
DCSQ stop ofs: 0x00006b0a (00:00:57:290) 00 02 00 00 2E 90 84


However, in a HD-DVD SUP file that seems to give correct durations, the timestamps are as follows:


#1
DCSQ start ofs: 0x00001879 (00:23:00:718) 00 00 00 00 1C 89 01
DCSQ stop ofs: 0x00001c93 (00:23:02:157) 00 7E 00 00 1C 89 02
#2
DCSQ start ofs: 0x00005148 (00:37:22:579) 00 00 00 00 38 BC 01
DCSQ stop ofs: 0x00005562 (00:37:25:918) 01 25 00 00 38 BC 02


I don't quite understand the timestamp format, but it seems like there is an increment part and a base part, and looks like BDSup2Sub only handles the increment part.

(That working example is from a HD-DVD forced subtitles SUP file which only contains 5 subtitles events, which made it nicely compact for my tests :-)

Would it be possible for you to fix BDSup2Sub to handle this problem HD-DVD SUP file correctly? I suppose I could code a program that will preprocess my problematic SUP file, but I'm sure it would benefit many others as well if you could fix BDSup2Sub instead!

Thanks a lot for reading this far, and again thanks for BDSup2Sub!

Pati

[Freddy68]

Hi I am new to this forum, I've been using BD RB 2003 . I dont know if this is the right thread to post this question, but I have some hddvd movies that I've converted to bluray using HDBR Extractor and then TS Muxer 1.3.4. and I've been succesful as far as video and audio. But when it comes to subs, after I do HDBR extraction I have to use SupRead to export the subs in an acceptable container so TS Muxer is able to recognize it and convert it to bluray. After that is done, when I burn it, the video flashes when the subs appear and this happens back and forth. Let me remark that if I do the conversion without the subs everything plays perfectly. It only happens when I try to convert from Hddvd to bluray with the subtitles. Can someone help me on this?

[0xdeadbeef]

1) The subtitles seem to show only black because all "Alpha Info" buffers/tables are filled with hex code 0xFF, instead of 0x00 like in a working HD-DVD SUP file I tested.
That's because HD-DVD uses an inverted logic for alpha values. 0xff is fully transparent and 0x00 ist fully opaque while usually (RGBA, but also BD-SUP) it's vice versa. A typical HD-DVD uses a fully transparent color as background color and fully opaque colors for the text. Values in between are used for anti-aliasing.

I tested what happens if I just clear the buffer (rewrite 0x00 over all the 0xFFs), and after I did that to the first subtitle and reloaded the SUP file into BDSup2Sub, the first subtitle showed up fine. I tried the same thing to the second subtitle and that showed up fine as well.
Not surprising, but this just goes to show that the subtitles are completely transparent in the original stream. Maybe a demuxer author thought that this was a good idea or maybe the stream is defective. Hard to tell.

It looks to me like 0xFF should be handled similarly to 0x00 in Alpha Info table. No tool I tried (BDSup2Sub, SUPRead and SupRip) seemed to do this, though.
Of course they don't, since this would disable transparency and would be plain wrong.

I don't understand *why* 0xFF should be the same as 0x00, but at least that way the subtitles seem to be shown correctly.
As I said, this is either a demuxer "feature" (most probable) or a corrupt stream (less likely) or maybe (but highly unlikely) there is some unknown bit somewhere that tells to not allow transparency at all. Anyway, treating 0xff just like 0x00 is wrong for sure.


2) I also compared the timestamps of my problem SUP with a working SUP file, and found out that the timestamp hexcodes of my problem SUP are like this:
#1
DCSQ start ofs: 0x00002af9 (00:00:55:026) 00 00 00 00 2F 09 01
DCSQ stop ofs: 0x00002f13 (00:00:55:054) 00 02 00 00 30 11 84


The first word at the given offset is the time offset to the PTS for the start/stop display commands. The start display offset is 0, so the subtitle is displayed at the PTS (this is typical). The stop display offset is 0x0002, which is 2*1024/90000 seconds or 22.756ms after the start command. This is obviously crap. Could be a demuxer bug or whatever. The displayed duration of 28ms is due to frame rate synchronization btw.


I don't quite understand the timestamp format, but it seems like there is an increment part and a base part, and looks like BDSup2Sub only handles the increment part.
As I said, the start/stop commands define a time offset based on the PTS. Though I don't think that's what you implied.
Anyway, most obviously BDSup2Sub handles both correctly, else every frame for every HD-DVD-SUP would have a zero duration or would start at the same (zero) time.


Would it be possible for you to fix BDSup2Sub to handle this problem HD-DVD SUP file correctly?
If the stream is broken (and I'm pretty sure it is), there is no "correct" way to handle it. You're asking for a hack, not for a correction.
This being said, it's hard to impossible to automatically fix every possible defective stream. Anyway, to investigate an issue, I need the stream and I need to know how it was created.

E.g. if the inverted alpha was a common problem, I could add a hack for this (e.g. menu option "invert alpha"). As I said, maybe (but not very likely) it's even a feature of the stream but that's impossible to tell without any data to investigate.

About the timestamps: maybe this is an issue of multiple stop command as BD-SUPs are ridden by multiple start packets. Again: if I had the stream, I could have a look. Then again, maybe the stream is just bollocks since it was created by a buggy demuxer.

I would propose to extract the SUP again with a current version of either EAC3TO or TSMuxer and post it here (or better upload it anywhere and send me a PM) if it still gives you problems.

BTW: with BDSup2Sub 2.3 you can edit the display duration and can even force a minimum display duration of e.g. 2000ms.

[Pati]

If the stream is broken (and I'm pretty sure it is), there is no "correct" way to handle it. You're asking for a hack, not for a correction.
This being said, it's hard to impossible to automatically fix every possible defective stream. Anyway, to investigate an issue, I need the stream and I need to know how it was created.
....
I would propose to extract the SUP again with a current version of either EAC3TO or TSMuxer and post it here (or better upload it anywhere and send me a PM) if it still gives you problems.


Thanks for a reply!

Sorry if I implied that BDSup2Sub was broken and needed a fix (that was not my intention, although reading my message again it does look like that). I am indeed after a "hack" that would allow me to use this broken SUP file.

I can upload it somewhere tomorrow (it is late here at the moment) so you can take a look at it. I tried all the tools I could find (and latest versions of all) to extract the stream, and all of them gave a similar result (and one tool, could have been EVODemux, complained about the original stream containing authoring errors). So I don't think the problem is the way I extracted the SUP stream, I believe the problem is in the stream itself.

Thanks again, I'll get back to you tomorrow!

Edit: Private message sent, hope you have the time and interest to look into it!

Edit2: Oh, and I forgot to comment on that duration problem...



#1
DCSQ start ofs: 0x00002af9 (00:00:55:026) 00 00 00 00 2F 09 01
DCSQ stop ofs: 0x00002f13 (00:00:55:054) 00 02 00 00 30 11 84



What I meant with the "base and incerement part" was that perhaps the 0x0002 in the "DCSQ stop" is the increment, and 0x3011 is the base (while the base for the DCSQ start is 0x2F09). I saw that in the working SUP file those 3rd words are the same in both "DCSQ start" and "DCSQ stop", while in my problem SUP they differ. Of course, since I know nothing about the timestamp format, other than what you explained above, that 3rd word might have nothing to do with anything.

Pati

[0xdeadbeef]

What I meant with the "base and incerement part" was that perhaps the 0x0002 in the "DCSQ stop" is the increment, and 0x3011 is the base (while the base for the DCSQ start is 0x2F09).
Nope. That's what I meant with "I don't think that's what you implied".

Of course, since I know nothing about the timestamp format, other than what you explained above, that 3rd word might have nothing to do with anything.
As I already said: only the first word does. the following dword is the (byte) offset to the next DSCQ and has nothing to do with timestamps.

Anyway, I had a look at the SUP and I think I know what the problem is there. Yet this isn't easy to fix and I don't even know if I want to invest much time in this.
The problem seems to be that the subtitles in this SUP are faded in (and out?). This (kinda) explains why the first subtitle is completely transparent at first and why the display duration is so short. Indeed after the display end marker, another alpha buffer follows and then a dozen more. I kinda lost track after the 4th or 5th, but there are lots more alpha buffers. There also seem to be several palettes. As the DSCQ times are accumulated, this also explains the short duration: BDSup2Sub only takes the first fading step, which results in a fully transparent, much too short subtitle.

While at first glance it seems to be easy to skip all the additional alpha and palette buffers and simply use the last one(s), this would only work for a fade-in, not for a fade out. There would be some ways to handle this of course, but I'm not quite sure if I want to invest the time for a dead format.

[Pati]

Ah, okay, thanks for taking a look, and for the explanation of what is going on with the subtitle.

That is fine, I'll just code something myself so that I can handle this particular subtitle (a preprocessor of sorts so that I can use BDSup2Sub for the actual work, and fix the durations manually if needed).

So, thanks again for BDSup2Sub itself!

Pati

[0xdeadbeef]

Don't get me wrong: I'll probably add a fix for finding the correct end time and skipping the first palette/alpha buffers the next days. Then again as I said, this won't completely fix the problem as it will only cure fade ins.

[hubblec4]

22.03.2009 2.2 -> 2.3


Automatic selection of language for SUB/IDX export if filename contains language name (e.g. "spanish")

ok this feature are very bugy. german, english and turkish works correct but all other language not. when i want save the file it shows me ever French(fr).

test it with:
Thai
Portuguese
Spanish
Polish
Icelandic
Hungarian
Hebrew
Modern Greek
Czech

hubble


This small bug is simple. All BD.sup files works correct but the movie-folder named "French Connection". BDSup2sub choose french for the language.

hubble

[~bT~]

^ its not buggy really :p it does what it says.

Originally Posted by 0xdeadbeef View Post

22.03.2009 2.2 -> 2.3

* Automatic selection of language for SUB/IDX export if filename contains language name (e.g. "spanish")


which it does :) change it to chinese connection or something :p and see what happens.

[0xdeadbeef]

I'll change this in 2.4 amongst a couple of other things.
@Pati: there'll also be better (yet not nearly perfect) support for faded HD-DVD captions.
I'm too tired now and want to do some more testing, but chances are 2.4 will be released tomorrow.

[Pati]

Ah, much appreciated! No hurry, take your time and all the rest you need!

Pati

[0xdeadbeef]

25.03.2009 2.3 -> 2.4

Improved support for HD-DVD-SUPs (multiple DCSQ START commands are supported, DCSQ is accumulated)
BD-SUP: subtitles without RLE buffer are ignored (led to NullpointerException)
Fully transparent colors are always interpreted as transparent black to not mess with scaling
Automatic language selection now only considers file name, not the path name
Bilinear scaling is also used for scaling down
Better exception handling for general exceptions inside threads
Edit dialog: duration can be entered as float value now (just for consistency)
Accidentally changed time format from "hh:mm:ss:ms" to "hh:mm:ss.ms" in IDX files. Fixed.

[saint-francis]

Would it be possible for you to include a changelog with each version? With the blazing rate at which you are making updates it's getting difficult to keep track of the progress and what version I currently have.

Also, when switching to a new version is it OK to keep the .ini from the previous version?

Thanks for the great tool!

[turbojet]

Converted .sup from get smart bluray to 720p...muxed with tsmuxer, played on my panasonic bd35 bluray player. No subtitles shown. :(


What version did you try?

I had problems pre 2.1 I believe it was with sup's showing in PowerDVD 8 and MPC-HC from TSMuxer's BD output but since 2.1 I haven't had an issue. I haven't been able to test on a standalone yet.

0xdeadbeef: If you are looking for SMlabs a developer has been active in in this thread (http://forum.doom9.org/showthread.php?t=134104) lately another way to reach them is by email tsmuxer@smartlabs.tv

[Pati]

Thanks for version 2.4! I quickly tested the fade-in/fade-out SUP, and the subtitles are now visible, great!

However, the durations do not seem to be correct yet, and most of the time the subtitle stays visible half-transparent for what seems like much too long. Perhaps this is the fade-out problem you mentioned?

Anyways, this is a big step forward, thanks!

Pati

[0xdeadbeef]

Would it be possible for you to include a changelog with each version? With the blazing rate at which you are making updates it's getting difficult to keep track of the progress and what version I currently have.
There's a complete revision history at the end of the online help.

Also, when switching to a new version is it OK to keep the .ini from the previous version?
Yep, there's not too much stored there anyway.

0xdeadbeef: If you are looking for SMlabs a developer has been active in in this thread (http://forum.doom9.org/showthread.php?t=134104) lately another way to reach them is by email tsmuxer@smartlabs.tv
I already tried to reach him by PM but with no success.

[0xdeadbeef]

However, the durations do not seem to be correct yet, and most of the time the subtitle stays visible half-transparent for what seems like much too long. Perhaps this is the fade-out problem you mentioned?
Perhaps. Maybe that's why I called it "better (yet not nearly perfect) support for faded HD-DVD captions"?

[turbojet]

I already tried to reach him by PM but with no success.

I've had some issues with pm popup notification on this board so that may be an issue for them as well. However I recently received a reply via e-mail, maybe you would have better luck through email.

[Pati]

Perhaps. Maybe that's why I called it "better (yet not nearly perfect) support for faded HD-DVD captions"?

Right. :-) Well, I just wanted to let you know I appreciate your work and follow with great interest your progress!

Though, since you have the exact same file that I am using as test material, perhaps my reporting my test results is not that informative or useful, so I'll just silently follow your progress from now on.

Thanks!

Pati

[0xdeadbeef]

26.03.2009 2.4 -> 2.5

Fixed: Cr and Cb color components were switched when reading BD-SUPs (in since 1.0)
Fixed: inconsistent behavior of "export forced" checkbox (probably introduced in 2.3)
Changed: console is cleared before loading a SUP to avoid heap and performance problems (Swing text components are SLOW).
Changed: when copying console output to clipboard, the clipboard is reset first to avoid OutOfMemoryException.
Changed: improved console output for BD-SUP reading to use less lines in the console

[hubblec4]

thanks for the new version.


hubble

[turbojet]

Since 2.4 this colored sup (http://www.sendspace.com/file/m1t7m0) is recognized as yellow, it should be a turqoise blue. When outputting to idx/sub it looks ok in yellow, when outputting as sup it looks like yellow with orange spots. Could you take a look?

[0xdeadbeef]

Since 2.4
Do you mean 2.5?


this colored sup (http://www.sendspace.com/file/m1t7m0) is recognized as yellow, it should be a turqoise blue.
In revision 2.5, I swapped the order of Cr and Cb components when reading SUPs. This was because I had the first BD with colored SUPs in my hands ("Iron Man") and could verify the colors. So IMHO, version up to 2.4 had wrong colors, while 2.5 has correct colors.
Since you complained about 2.4, but probably mean 2.5, I'm pretty uncertain how to handle this complaint. Do you complain that the colors are different in 2.4 and 2.5 (which they should be) or did you compare 2.4/2.5 to the real BD in a standalone player and found that 2.4 was correct while 2.5 was not? This would really puzzle me though since my PS3 shows the colors exactly like 2.5 does.

When outputting to idx/sub it looks ok in yellow, when outputting as sup it looks like yellow with orange spots. Could you take a look?
As I changed the order of Cr/Cb components in 2.5 when reading SUPs, I somehow forgot about writing SUPs. I already fixed it locally though.

[turbojet]

2.3 gui shows and outputs the correct color.
2.4 and 2.5 gui shows and outputs the wrong color.

[0xdeadbeef]

2.3 gui shows and outputs the correct color.
2.4 and 2.5 gui shows and outputs the wrong color.
Sorry, but this is impossible, as 2.4 behaves exactly like 2.3 when it comes to colors. The change was done in 2.5.

And did you really compare the SUP as displayed by 2.5 to the output of a standalone?

If so and you still say that the colors displayed by 2.5 are wrong, this really leaves me puzzled. Then either my PS3 or your standalone shows wrong colors or I'm totally missing something else.

I'm already playing with the idea of a "swap Cr/Cb" option for the conversion dialog...

[turbojet]

2.0-2.2 also output the correct colors. I didn't test in a standalone, don't have one here. But with any luck at all I can test it in a couple this weekend.

MPC-HC, PowerDVD, suprip, vobsub resync are what I've been using to detect the colors which also matches what BDsup2sub gui displays.

Does Iron Man subs display wrong color in v 2.0-2.3?

[0xdeadbeef]

As I already said: version 1.0 until 2.4 did use the same order of color components and therefore display the same colors. These colors are wrong (swapped Cr/Cb) when compared to what my PS3 displays - which I couldn't test until I got "Iron Man" which was the 1st BD with colored captions that I got my hands on. As I discovered this, I swapped Cr/Cb in 2.5 and now colors in BDSup2Sub 2.5 are identical to what my PS3 displays when the original BD is played.
So as I said: either the PS3 is wrong (which seems extremely unlikely) or your player(s) are wrong. Hard to tell without a 2nd standalone.
Anyway: I added a menu option to swap Cr/Cb manually.


27.03.2009 2.5 -> 2.6

Fixed: Cr and Cb color components were switched when writing BD-SUPs (introduced in 2.5)
Fixed: DSCQ is updated instead of accumulated for HD-DVD-SUPs with multiple DSCQs
Changed: better detection for faded HD-DVD-SUPs
Changed: improved luminance threshold detection
Changed: added menu entry to swap Cr/Cb components

[turbojet]

Swapping Cr/Cb fixed it in 2.6 thanks.

Actually I downloaded 2.4 from videohelp just now and it handled it correctly, I obviously wasn't paying much attention to the version in title bar, you are right 2.5 is where the issue started.

[0xdeadbeef]

Well, your use of "correct" is debatable. IMHO BDSup2Sub handles colors correctly since 2.5. I find it hard to believe that Sony, core member of the BD Association, screwed this in the PS3, which probably still is one of the most popular BD players.

[turbojet]

Correct meaning the swap setting came very close to replicating the original sup I uploaded which is tough to debate. I have a feeling you'll experience the same thing in PS3 with that sup. I actually prefer the yellow vobsubs over the turquoise but the 2.5 sups were very difficult to read.

I don't know about Iron Man sup, I don't have that one and I believe your claims about it.

Probably just a case where some need the swap while others don't, luckily we have control of that now.

[0xdeadbeef]

Correct meaning the swap setting came very close to replicating the original sup I uploaded which is tough to debate.
As long as you didn't actually see the captions of the original BD on a certified standalone, I'd argue that it's impossible for you to judge if the colors are correct or not. So it's not tough, but pointless to debate.

I have a feeling you'll experience the same thing in PS3 with that sup. I actually prefer the yellow vobsubs over the turquoise but the 2.5 sups were very difficult to read.
I'm pretty sure indeed that the SUPs of the original BD displayed on a PS3 would look pretty close to what BDSup2Sub 2.5/2.6 shows (ignoring lack of calibration and gamma correction). The fact that the BD-SUPs created by 2.5 had an inconsistent palette is a completely different matter.

Which however raises the questions if you're actually using the SUPs created by BDSup2Sub to mux a transport stream. If so: does this work reliably?

I don't know about Iron Man sup, I don't have that one and I believe your claims about it.
It's almost 100% certain that any BD on any PS3 shows exactly the same behavior as they share the same software.

Probably just a case where some need the swap while others don't, luckily we have control of that now.
I don't think so. I guess that other people stumbled over the same assumption as I did: if the color space is commonly called "YCbCr", it seems likely that the color components are also stored in that order. As SupRip shows the "Iron Man" caption in wrong colors, it's pretty clear to me that it uses the wrong Cr/Cb order just like BDSup2Sub did until (including) 2.4.

[turbojet]

You could if you wanted to test out that sup stream on a PS3 and compare color palettes of the original to swap vs unswapped setting in BDSup2Sub. As I understand it the color palette is contained inside the sup and I don't see why a PS3 would interpret it differently then these other tools/players do.

I've only watched a few 720p movies with sup's converted with BDSup2Sub and they seem to be reliable since I think it was 2.1 when they started showing, except for this one colored forced sup stream. I'll let you know if I do find some thing else though.

[0xdeadbeef]

[...] I don't see why a PS3 would interpret it differently then these other tools/players do.
You aren't serious, are you?

Besides, at least one of the tools you named, Vobsub Resync, doesn't even support BD-SUPs. I must admit that I'm surprised to hear that MPC-HC does. At least with the M2TS streams I tried, it certainly didn't. So, this obviously leaves us in a PowerDVD vs. PS3 situation (if at all), where I would bet on the hardware player produced by the BDA foundation member for sure.

Anyway: anybody with a standalone is invited to report if colored captions demuxed from a BD/HD-DVD appear correct (neglecting calibration/gamma correction) in BDSup2Sub compared to what the standalone displays with the original BD/HD-DVD. If not, post the SUP and some details (which captions should look how, which demuxer used, did the "swap cr/cb" option fix it etc).

[Pati]

Thanks for 2.6! The fade-in/out HD-DVD SUP files seem to be pretty much fixed now. :thanks:

I do get a few "problems decoding RLE" errors when exporting to BD SUP, though.. What causes that?

Pati

[rizu]

Hi,

First I'd like to thank you for making this tool :)

I have one request/idea.. would it be possible to add as an option to relocate subs automatically inside the picture, simply something like keep subs inside set bounds?

I'm planning to get myself 2.35:1 screen and having subs outside the screen isn't really an option :) I though about making such tool myself but then I saw your tool and though it could be easy to add such feature to already existing software, I'm sure there would be loads of people who'd have use for such feature anyway. I know I can do this with srt subs but I really do prefer bitmap subs as there are several cons on srt.

I've put a quick sketch as an attachment to show what I'm after. Basically you'd enter Min and Max Y and treshold, these values would set the final bounds, no subs would be left outside these values. Then all subs would be scanned and determined the ones that need repositioning. Software would mark subs that has to be lowered and subs to be risen and also save highest and lowest Y found on sub frames.

Treshold would describe how much subtitle can get below min Y or above max Y to be marked for repositioning while min and max Y would tell where the new lowest or highest subtitle would be repositioned.

Then after all subs were scanned repositioning would take place by following logic: rise ALL subs that were below (Max Y-Treshold) by (biggest Y found on subframes-Max Y entered). Same logic on too high positioned subtitles. So it would process only the frames that need repositioning. Treshold would keep frames away from bouncing all over the screen too. If both Min Y and Max Y would be true over the same frame, then tell user about it and leave frame as it is (let user deal with that particular frame by himself manually).

[turbojet]

Found an oddity with the swap cr/cb.
With the same colored sups I've been dealing with if I disable swap the text in the gui appears yellow but it outputs blue subtitles.
If I enable swap the gui shows blue but it outputs yellow subtitles.

Also the color of the sup in MPC-HC, PowerDVD, SupRip, SupRead matches the color of what is shown on a Panasonic BD30.
I'll try testing on a PS3 soon.

[jonathonsunshine]

As of version 2.6 is it able to automatically detect the language when you are running it from a command prompt ? I couldn't see anything in the help, no switchs and it defaulting everything to german unless you specify something else (from the command prompt).

[0xdeadbeef]

I do get a few "problems decoding RLE" errors when exporting to BD SUP, though.. What causes that?
In this particular SUP, it seems that the last line in the 2nd buffer (either even or odd lines) is a bit too long. Or let's say: there's more information in the RLE buffer than needed to decode the picture. As long a no image is cut or garbled, I decided to live with it. If you find a pic that is, please report though.

First I'd like to thank you for making this tool :)
You're welcome, although by experience, there's usually a "but".

I have one request/idea.. would it be possible to add as an option to relocate subs automatically inside the picture, simply something like keep subs inside set bounds?
Surprise ;)
Indeed I played with the idea myself, but then decided that probably nobody would ever need this as I couldn't imagine a (commonly needed) use case.

I'm planning to get myself 2.35:1 screen and having subs outside the screen isn't really an option :)
Ok, this sounds like a use case. Although I'm not 100% sure if I'd implement it this way if I would.

I though about making such tool myself but then I saw your tool and though it could be easy to add such feature to already existing software, I'm sure there would be loads of people who'd have use for such feature anyway. I know I can do this with srt subs but I really do prefer bitmap subs as there are several cons on srt.
There's no such tool for SUB/IDX? Or which type of captions do you export?
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.

Found an oddity with the swap cr/cb.
With the same colored sups I've been dealing with if I disable swap the text in the gui appears yellow but it outputs blue subtitles.
If I enable swap the gui shows blue but it outputs yellow subtitles.
Are you sure that this isn't a misconception on your side? If you swap Cr/Cb, save as a SUP and load it again (with the swap setting still on), the colors will change (again) of course. That's the idea of the swap function. To see the correct colors after saving a file with swapped colors, you need to uncheck the swap option of course.

Also the color of the sup in MPC-HC, PowerDVD, SupRip, SupRead matches the color of what is shown on a Panasonic BD30.
SupRip shows the wrong colors compared to a PS3 (if it doesn't crash). SUPread shows only a few captions of your example, but what it shows looks exactly like in BDSup2Sub:

http://imagedash.com/uploads/bfi1238341351l.png (http://www.imagedash.com)

So if you say that "SupRead matches the color of what is shown on a Panasonic BD30", this would also mean that BDSup2Sub shows the same colors. Then again, since SupRip shows different colors than SUPread, the whole statement is questionable to say the least.

Also, I'm still not convinced that MPC-HC can display SUPs at all. With all M2TS I tried up to now, MPC-HC didn't display any embedded SUPs at all (option greyed out).

As of version 2.6 is it able to automatically detect the language when you are running it from a command prompt ? I couldn't see anything in the help, no switchs and it defaulting everything to german unless you specify something else (from the command prompt).
No, you have to define the language explicitly from the command line. Since the automatic 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"...