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

[0xdeadbeef]

http://javaforge.com/displayDocument/icon_128.png?doc_id=76805

BDSup2Sub is a tool I wrote initially to convert captions demuxed from a Blu-Ray transport stream (M2TS) into the DVD VobSub format (SUB/IDX) used by many DVD authoring tools - hence the name. Many more features were added over time as was support for other formats. So in the meantime the name seems a little inappropriate. In a nutshell, it's a subtitle conversion tool (for image based formats) with scaling capabilities and some other nice features.

Feedback is welcome - especially from the authors of other tools to discuss compatibility issues.

To report problems with a subtitle stream, please either post the zipped stream (if it is compliant with the forum rules) or upload it to a "one click hoster" and send me a PM with the link. And don't forget a detailed error description.

Supported Formats

Blu-Ray SUP: Import (since 1.0) and Export (since 1.6)
Sony BDN XML: Import and Export (since 3.3.0)
HD-DVD SUP: Import (since 1.9)
VobSub (SUB/IDX): Import (since 3.5.0) and Export (since 1.0)
DVD-SUP (SUP/IFO): import and export (since 3.9.0)


Features

add a fixed delay to all timestamps (since 1.0)
perform a frame rate conversion e.g. for pal speedup (since 1.0)
synchronize time stamps to output frame rate (since 2.0)
edit times and position of each caption (since 2.3)
control all features (except editing) from the command line (since 1.7)
move all captions inside or outside a given area (since 2.7) or horizontally (since 3.9.6)
scale up/down with a variety of filters (from bilinear over bicubic to Lanczos3 and Mitchell) (since 3.4.0)
edit "forced" flags (since 3.6.0)
exclude single captions from export (since 3.6.0)
erase rectangular regions of a caption (since 3.6.0)
scale captions independently of screen size (since 3.7.0)
automatically remove fade in/out from imported subtitle streams
export the target palette in PGCEdit text format (RGB values 0..255) (since 3.9.0)
edit the imported DVD palette when input is either VobSub or SUP/IFO (since 3.9.1)
edit the frame palette and alpha values when input is either VobSub or SUP/IFO (since 3.9.3)
set/clear forced flags for all captions (since 3.9.9)


Documentation
The complete documentation is available from the help menu inside the application. You can also read it online (http://bdsup2sub.javaforge.com/help.htm).

Download

Current version: 4.0.0 (14.12.2009)
http://www.sendspace.com/file/j3df4s


Previous versions:
3.9.9:http://www.sendspace.com/file/4mcnk5
3.9.8:http://www.sendspace.com/file/epw7ng
3.9.7:http://www.sendspace.com/file/k8lcmo
3.9.6:http://www.sendspace.com/file/w5tfal

The download is a JAR archive that needs an installed Java runtime (Java 6 JRE) to run. You can get it from Sun's website:
http://java.sun.com/javase/downloads/index.jsp (e.g. JRE 6 Update 13)

A complete revision history (http://bdsup2sub.javaforge.com/help.htm#Change_History) can be found at the end of the online help.

Usage

With the Java runtime installed, the JAR can be started by double clicking on it. Alternatively, you can start it from the command line via:

java -jar BDSup2Sub.jar

or in Windows if you don't want a open CMD box:

javaw -jar BDSup2Sub.jar


Have fun.

Screenshots
Main screen (source in upper part, target in lower part)
http://javaforge.com/displayDocument/scrn_main.png?doc_id=76807

Conversion dialog with the basic conversion options
http://javaforge.com/displayDocument/scrn_conv.png?doc_id=76804

Edit dialog
http://javaforge.com/displayDocument/scrn_edit.png?doc_id=76808

Move dialog
http://javaforge.com/displayDocument/scrn_move.png?doc_id=76806

[BigCondor]

Thanks very much for your effort and sharing.

I have tried to convert two sups with your program and it works. I noticed that the results of idx+sub will vary with the size of the original sup (font size of the original).

The first one in the figure is very nice.
The second one, which engages smaller font, the edges are not all correctly marked.(upper image taken from suprip, lower one from .son file)

[Selur]

any plans to open the source of the tool?

[0xdeadbeef]

I noticed that the results of idx+sub will vary with the size of the original sup (font size of the original).
Well, of course they do. The smaller the input picture, the smaller the output picture. For OCR purposes, the best choice would be the original picture from the Blu-Ray SUP. Therefore it doesn't make much sense to use the converted low-res picture for OCR. Besides, the subsampling used for antialiasing also contradicts the idea of OCR in a way.

any plans to open the source of the tool?
Not in the sense of a real open source software since it would be a major effort to clean up the sources to a state that they were worth to be publicly released. Then again, as always with my software, if someone kindly asks for the sourcecode, I will share it of course. Just be warned: the sources are quite a mess currently.

[Adub]

Well, of course they do. The smaller the input picture, the smaller the output picture. For OCR purposes, the best choice would be the original picture from the Blu-Ray SUP. Therefore it doesn't make much sense to use the converted low-res picture for OCR. Besides, the subsampling used for antialiasing also contradicts the idea of OCR in a way.

Yes, but unfortunately, there doesn't exist a "perfect" solution yet for OCRing blu-ray subtitles. Suprip is pretty good, but suffers from a few major bugs here and there.

[0xdeadbeef]

Well I sure don't intend to add OCR to SupToSub, so all I could offer would be an export to an easy to implement format. E.g. a bunch of GIFs plus a text file similar to the IDX of VobSub. Then maybe someone could set up a scripting tools to convert this to SRT or whatever.

[0xdeadbeef]

A little update:

26/02/2009 1.0 -> 1.1
-Added progress dialog for import
-Added check for existing target files and write protection
-Added detection of forced subtitles and the possibility to export only forced subs
-Removed some checks from RLE decoding to support some non-standard frames which write to the next line without EOL
-Fixed two small bugs in run length decoding (fixes reading exports from SupRead)
-Support for multi-packet pictures (well, exactly two packets are supported for the moment)

I edited the first posting...

Sorry, another micro update to 1.1b (not visible in GUI) since there was another bug with multi-packet support for SUPs. This should really work for all two-packet SUPs. I'll add unlimited packet support later though no SUP stream seems to use it.

[shon3i]

Do you think about reverse process? DVD->BluRay?

[0xdeadbeef]

Not really. Would this make sense?

[SquallMX]

Not really. Would this make sense?

Yes:), some Bluray titles don't have subtitles that the DVD versión does have, and sometimes de DVD version is better placed or have better font (Warner BR subtitles are placed in the black bars if the movie is 2.35, some of us hate that, and right now there's no way to change the position, the DVD subtitles can be placed inside the 2.35 image itself).

Another petition, an option to resize BR subs from 1080p to 720p, currently it's not possible to have BD5 at 720 with subtitles because no program exist that converts the subs from 1080p to 720p.

:thanks:

[woah!]

1080 to 720 resizing would be very cool if possible, otherwise it works very well thx :)

[0xdeadbeef]

The resizing to 720p itself, although a little different compared to the approach used for VobSub, would be easy to implement. Then again, I don't have any SUP writing functionality yet (as well as SUB/IDX Reading). While one might think that it should be easy to implement a writer when you already know the format to implement a reader, the problem is that I can skip a lot of unknown stuff when reading, but have to write it when writing.
Chances are that with all the guessing about these unknown fields I have to do, the written SUP file creates all kind of problems when used with different players.

[woah!]

for me it was just that my WD TV HD Media Player plays MKV/SUB/IDX and i encode my blurays down to 720p MKV's for storage on it. i use subrip right now to ocr to srt and this app would save those steps thats all :)

either way your app does a great job thx ..


edit: actually they look pretty good as they are on my tv playing on the WD player :) so thats very cool and saves me alot of work thx :)

[0xdeadbeef]

Hm, my only option would be to export 720p SUPs since SUB/IDX doesn't officially support 720p (and I would be surprised if any player could handle it). Then again, I would be surprised to hear that MKV streams can contain SUPs.
So the 720p SUP would only make sense for the use case that SquallMX suggested (converting a 1080p BD to 720p BD5 to save space).

[SquallMX]

Hi, i found a little bug, the program crash when i load this Sup file (From Matrix R1 Bluray):

http://rapidshare.com/files/204262182/00005.track_4609.sup

:helpful:

[0xdeadbeef]

Hm, this seems to be from an NTSC stream? The screen size is 720x480, therefore the "downsizing" to PAL (which is the default target resolution) fails with a division by zero.
I'm thinking of a workaround - yet this is not really a planned scenario.

[0xdeadbeef]

A little update (edited the first post for download)

02.03.2009 1.1 -> 1.2

Reworked SUP multipacket parsing to support unlimited packets (kinda untested though for > 2 packets).
Fixed bug in detection of primary color & luminance thresholds.
Added workaround to prevent crash when loading SUPs in NTSC/PAL resolution.
Note that "upscaling" NTSC to PAL will not change the size of the bitmap, only the offsets.
Also downsizing from PAL to NTSC might fail - I'll have to reconsider this issue later.
Info was not updated when switching output format
Added fixed line feed after even and off RLE buffer since VobSub sometimes skipped the last line

[~bT~]

request: is it possible to remember last folder?

also i noticed after loading the above file for matrix, it says, source fps 23.976 dest fps 25?

is that correct? and yes, that was using the latest version.

[0xdeadbeef]

While the program is running, it remembers the last folder. However, it doesn't save any ini file yet. This is on my list however.

Regarding the SRC/TRG frame rates: AFAIK the SUP file doesn't contain any info about the frame rate. Therefore, if you want to convert the frame rate, you have to select the source and target frame rates manually. The 23.976 as source and 25fps as target is just the default setting as this is my typical scenario (PAL speedup from 24p). Indeed the source and target frame rates are only used to calculate a speedup/slowdown factor that's used to manipulate the time stamps.

[~bT~]

^ sorry. my bad. it was late last night when i posted that and didn't realise the option above which u must tick to enable changing.

[saint-francis]

Therefore, if you want to convert the frame rate, you have to select the source and target frame rates manually.

How is this done? I see no option to specify frame rate. Only resolution. I actually see nothing about frame rates at all in your tool.

Fantastic tool BTW. I'm loving it. Thanks for all of your hard work.

[0xdeadbeef]

How is this done? I see no option to specify frame rate. Only resolution. I actually see nothing about frame rates at all in your tool.
Changing the frame rate is not visible in the main view. However, when you select "Save" in the file menu, an export dialog pops up where you can set the checkbox for "Change frame rate". If this checkbox is active, the source and target frame rate can be edited and the time stamps will be changed accordingly during export.

[saint-francis]

Changing the frame rate is not visible in the main view. However, when you select "Save" in the file menu, an export dialog pops up where you can set the checkbox for "Change frame rate". If this checkbox is active, the source and target frame rate can be edited and the time stamps will be changed accordingly during export.

Gotcha. Thanks.

[turbojet]

Hey thanks for the program it's definitely useful however I came across some subs that are misaligned that I reported here (http://forum.doom9.org/showthread.php?p=1257351#post1257351). If you could take a look at it be much appreciated.

[0xdeadbeef]

How am I supposed to take a look if you didn't post a stream?
Besides, if two different tools which don't share a single line of code, show the same behavior, chances are that the stream is either buggy or uses an undocumented/unknown formatting feature.
Anyway, without a stream, nobody can tell for sure.

[~bT~]

how do i get the subs to show up in white rather than grey?

[turbojet]

Here's one of the many streams (http://www.sendspace.com/file/iyrnxf), most sup's I've converted to 720p with BD-RB has shown the problem so I think it would be a pretty common issue. I just found BDSup2Sub earlier today so this is the first.
I think it is issues with the streams like you say, I've seen many strange displays with SupRip over the past year or so but they seemed to ocr ok so I didn't pay much attention to it. But these strange displays play fine in the retail somehow.

[0xdeadbeef]

Can you name a frame that you think is misaligned in this SUP?
On the first look, the window (WDS) locations and sizes seem to be valid.
BTW: how was this created? It contains DTS info, so it was probably not created with EAC3TO...

[hubblec4]

i converted some BD.sups and i finde a timestamp problem in the sub.idx
some subtitles are shown too long...

sample is here (http://rapidshare.com/files/205270057/BDSUP-idx.rar.html)

load the sub/idx in SubtitleCreater an go to subtitle 135 and you will see what i mean.
Thats not a mistake of SC because during the playback in MPC the subtitle are shown too long.

hubble

[turbojet]

Can you name a frame that you think is misaligned in this SUP?
On the first look, the window (WDS) locations and sizes seem to be valid.
BTW: how was this created? It contains DTS info, so it was probably not created with EAC3TO...

5, 8, 11-26, 29-40, 42-56, 58, 63-71, 73,75, 77, 81-83, 86-90, 92, 93, 95-101 are all the 'shifted' entries in the first 100.

It was demuxed with tsmuxer I will try eac3to and see if that changes anything.

eac3to threw an error
s06 Writing the destination file failed.
Aborted at file position 2052063232.

[0xdeadbeef]

@turbojet
Hm, looks like the windows are perfectly centered, but the image is quite a bit smaller than the window in this case (which it usually isn't). Since there is no window in the VobSub format, the image is displayed at the coordinates of the window and thus is shifted left. Problem is that I'm unsure how to handle this case (image smaller than window) in general. Maybe centering is an option, maybe there are flags in the stream that define what to do. I'll have a look.

@hubblec4
This is obviously a problem in the original stream (or created by the demuxer). If you go to frame 134 in BDSUP2Read, it shows an end time stamp "00:00:00:000". This is of course a bad thing to start with.
Since I wanted to add some time stamp inconsistency checking anyway, I might add some auto fix code as well.

[0xdeadbeef]

Hope I didn't destroy more than I fixed this time. First post is updated again.

04.03.2009 1.2 -> 1.3

x/y ofs from start PCS is used instead of that from the window definition (fixes most misaligned subtitles)
Time stamp inconsistencies are reported and fixed
Swapped checkboxes in export dialog to emphasize the relation between the "Change frame rate" checkbox and the src/trg FPS
Added ini file to store frame size/position and load/save paths. Probably more to follow.
Added upscaling (indeed the scaling algorithm already supported it, only the factors were wrong)
Allowed all output formats for the moment. Dunno where this will take us, but it's worth a try.
Added layout panel that shows the location of the subtitle
Worked a bit on the user interface (less rescaling of components)
Removed warnings about empty palettes since this seems to be pretty common.
All editable fields of export dialog read out again before saving (indeed already done in 1.2)

[turbojet]

Thanks!
1.3 got rid of the misaligned subs, at the least the ones I had remembered on 3 of 3 sup's so far. I'm considering it fixed and not going to try to remember those other ones that were misaligned. I'll let you know if I see it happen in the future.

One thing I notice in vista x64 is progress bar is very small screenshot (http://i39.tinypic.com/2i1gt4m.png)

[hubblec4]

Hello

Thanks for the new version.

A new problem i found.
sample (http://rapidshare.com/files/205493213/00005_-_8_-_Subtitle__PGS___German__893_captions.rar.html)

The subtitles are doubled and the first sub has no endtime in the timestamp. the problem i found on SupRead to. Only SupRip load and show the file correctly.

hubble

[0xdeadbeef]

Well, again, this is more a problem of the stream.

The section sequence of a typical stream looks like this:
PCS(start)/WDS/PDS/ODS/END PCS(end)/WDS/END

In your stream it looks like this:
PCS(start)/WDS/PDS/ODS/END PCS(start)/WDS/PDS/ODS/END PCS(end)/WDS/END

So the whole start sequence including the the palette and RLE compressed bitmap is duplicated, yet with different start times (PTS). IMHO this doesn't make sense since it wastes lots of space. So this is most probably a authoring fault or a problem with the demuxer.

Then again, I think I can add a workaround.

[0xdeadbeef]

Just a small update, mainly for the last two issues reported.
Hubble/turbojet, could you give it a try and report back?

06.03.2009 1.3 -> 1.4

Tinkered around with progress dialog to solve problems under Vista. Can't test it though.
Added frame/sequence number checks/warnings
Added automatic elimination of double subtitle start frames.

[turbojet]

I think progress bar looks ok now (http://i41.tinypic.com/nbez68.png) in vista.
Thanks again

[hubblec4]

Just a small update, mainly for the last two issues reported.
Hubble could you give it a try and report back?

06.03.2009 1.3 -> 1.4


Added automatic elimination of double subtitle start frames.


Well done. it works pretty good. No doubling anymore.

Thank you

[hubblec4]

Another problem i have found. please look at my sample (http://rapidshare.com/files/205493213/00005_-_8_-_Subtitle__PGS___German__893_captions.rar.html)

After transcoding the time to show this subtitles is very short. Example. Subtitle 78
here is the original length from SupRip:
78
00:08:47,068 --> 00:08:50,820
-Ich heirate.
-Was? Hör auf, ich versteh ihn nicht.

but in the new file.sub/idx (open it in SC)

78
00:08:49,070 --> 00:08:50,822
-Ich heirate.
-Was? Hör auf, ich versteh ihn nicht.

the endtime seems to be correct but the starttime is too late and nobody can read this subtitle in this short time.


hubble

[0xdeadbeef]

Damnit, how many samples do you actually have ;) ?

I will have a look this evening. However I assume that this is another case of stream inconsistency that SupRip detects and fixes. I just fear that each workaround added might create new problems. Also with all that stream bug fixing I somehow don't find the time to continue core development.

[hubblec4]

Damnit, how many samples do you actually have ;) ?


its the same sample like the first with the doubling issue.
i hope you can find a solve. then it works perfect. and the 1080p-output for sub/idx is the best feature!!

the subtitles looks like the original.

hubble

[manusse]

and the 1080p-output for sub/idx is the best feature!!

I didn't even know it was allowed as sub/idx is a DVD format at the origin. Did you test such a sub/idx stream with VobSub when playing a HD stream. Is it working? Is it also working with AviSynth (TextSub)?

Gives me some ideas for SubtitleCreator....

Cheers
Manusse

[hubblec4]

I didn't even know it was allowed as sub/idx is a DVD format at the origin. Did you test such a sub/idx stream with VobSub when playing a HD stream. Is it working? Is it also working with AviSynth (TextSub)?

Gives me some ideas for SubtitleCreator....

Cheers
Manusse

only i use mkv with subtitle.sub/idx (and sometimes SRT) and VSfilter.
It works very good the subtitles are correct shown and looks like the original. But SC can't shown the subtitles correctly.

Working with AviSynth....I don't know.

hubble

[0xdeadbeef]

I didn't even know it was allowed as sub/idx is a DVD format at the origin.
Indeed I just added this as an experimental feature since I was (and am) not sure what the different filters/players make of it. But since there's at least one happy customer, I think I'll leave it in ;).

BTW: SubtitleCreator v2.3rc1 seems to have quite some problems with the SUB/IDX files created by BDSup2Sub. With most of the files (which VobSub resync displays ok), SC crashes at the end of the import. Seems to be a System.NullReferenceException in SubtitleCreator.PreviewForm.ReadSUPCompleted().

[0xdeadbeef]

Another problem i have found.
...
but in the new file.sub/idx (open it in SC)

78
00:08:49,070 --> 00:08:50,822
-Ich heirate.
-Was? Hör auf, ich versteh ihn nicht.

the endtime seems to be correct but the starttime is too late and nobody can read this subtitle in this short time.


Ok, a quick look in the console output shows that this is a tripled start packet. While I thought I fixed it for any number of start packets, my workaround seems to work only for two. I'll have a look.

[manusse]

BTW: SubtitleCreator v2.3rc1 seems to have quite some problems with the SUB/IDX files created by BDSup2Sub. With most of the files (which VobSub resync displays ok), SC crashes at the end of the import. Seems to be a System.NullReferenceException in SubtitleCreator.PreviewForm.ReadSUPCompleted().

Thanks for the information. I'll try to have a look.

Cheers
Manusse

customer
??? Do you plan to sell your software later?

[0xdeadbeef]

Thanks for the information. I'll try to have a look.
Great, thanks!

??? Do you plan to sell your software later?
No way. This was supposed to be ironic. Obviously failed ;)

[hubblec4]

Ok, a quick look in the console output shows that this is a tripled start packet. While I thought I fixed it for any number of start packets, my workaround seems to work only for two. I'll have a look.

When i open a BD.sup with the "doubling-issue" in SupRead. It shows me that the starttime from the first subtitle is the correct time. but it have no endtime. and the second subtitle had the right endtime but the wrong starttime.

so you could try to take the starttime from the first subtitle and the endtime from the second subtitle...maybe


hubble

[0xdeadbeef]

06.03.2009 1.4 -> 1.5

Fixed redraw bug and reduced memory needed for zoom modes.
Fixed bug that caused wrong start time in case of multiple start packets or missing end packets.
Extended primary color detection to support "white,light grey" in addition to "light grey, dark grey"
Added possibility to edit/save/load Vobsub palettes
Fixed blatant bug in export of forced subtitles which would export the same frames over and over again
Set default alpha threshold to 80

[hubblec4]

06.03.2009 1.4 -> 1.5


Fixed bug that caused wrong start time in case of multiple start packets or missing end packets.




Wow, i am very impressed. it works now 100%

Great thanks to you.

Where i can find the Logfile to check the warnings?

hubble

[hubblec4]

one thing again.

in the save-box where i can choose the language: i miss some languages like norwegian etc. ...

can you add this?

hubble

[0xdeadbeef]

Just a dumb error - exactly half of the languages that ought to be in the list didn't get there. Will be fixed in the next version. I won't release a new version just for this though. But I'm pretty confident that you'll find another issue ;)

[~bT~]

06.03.2009 1.4 -> 1.5

Fixed redraw bug and reduced memory needed for zoom modes.
Fixed bug that caused wrong start time in case of multiple start packets or missing end packets.
Extended primary color detection to support "white,light grey" in addition to "light grey, dark grey"
Added possibility to edit/save/load Vobsub palettes
Fixed blatant bug in export of forced subtitles which would export the same frames over and over again
Set default alpha threshold to 80


thanks a lot 0xdeadbeef! any way to donate?

[0xdeadbeef]

thanks a lot 0xdeadbeef!
You're welcome! And there was not even a "but" ;)

any way to donate?
This is a spare time project and mainly driven by my own needs and the fun of it. While I might implement features requested by other people, I might as well decide to ignore such requests. Accepting donations, among a couple of other issues, would put me in a position where I would feel obliged to implement requested features no matter if I want to or have time to. This contradicts the idea of a fun spare time project (at least in my humble opinion).

[Kurtnoise]

great stuff...:)

May I ask you to add command line support ?

something like:
BDSup2Sub -i input.sup -o output.sub -lang English

:thanks:

[0xdeadbeef]

It's on my list. There is one big feature I'd like to add first though.

[IceM]

Nice work!

I did about the same as you did, but I could not manage to fix the vobsubs properly and put the project in the freezer.
If you want I can send you my reader implementation (all written in java). I managed to get quite a bit of info out of it (though, still some options unknown for me). Or we could work together on it? My plan was to make it an open source app... If interested you can drop me a pm or something.

[0xdeadbeef]

If you want I can send you my reader implementation (all written in java). I managed to get quite a bit of info out of it (though, still some options unknown for me).
I guess my SUP(BD) parser is nearly complete right now and I understand most of the fields. I'd take a SUP-Parser for HD-DVD though ;)


Or we could work together on it? My plan was to make it an open source app... If interested you can drop me a pm or something.
For the moment, this is a one man show. Indeed the project is too small and too "experimental" (other name for "dirty hack") at this time to make sense for shared development. If (and this is a big "IF") I will ever finish the planned core features AND I find the time to restructure and comment the sources to a degree that someone else can make use of them, I plan to release the sources for the common good. I don't think that this will become a big Sourceforge project though. At least it's not planned to become a big"all in one" solution like SubtitleCreator or whatever.
As I already mentioned, I plan to implement only two more bigger feature, where one of them is command line support. Chances are that I'll do only bug fixes after this point.

[0xdeadbeef]

08.03.2009 1.5 -> 1.6

Added support to write (BD-)SUPs (kinda experimental though, SupRip doesn't like'em). This included a major rework of the program's structure, so I hope I didn't break anything.
Rewrote upscaling function (bilinear: slower, but much better quality)
Fixed: half of the languages in the language selection box were not displayed
While I was at it, I sorted the lower part of the list alphabetically

[chros]

A long awaited feature was implemented by You!!! Thank You !
I'll try it ...

[hubblec4]

08.03.2009 1.5 -> 1.6

Added support to write SUPs (kinda experimental though, SupRip doesn't like'em). This included a major rework of the program's structure, so I hope I didn't break anything.
Rewrote upscaling function (bilinear: slower, but much better quality)
Fixed: half of the languages in the language selection box were not displayed
While I was at it, I sorted the lower part of the list alphabetically


thanks for your hard work.

i have tested somthing an found 0 errors.

In the Box "Mode" SUP->SUP better you call this SUP->DVD.SUP maybe


hubble

[0xdeadbeef]

thanks for your hard work.
i have tested somthing an found 0 errors.
Ah, great. I feared I might have broken something that worked before.

In the Box "Mode" SUP->SUP better you call this SUP->DVD.SUP maybe
It's a "BD-SUP to BD-SUP" conversion actually. As discussed in the online help, it's meant to e.g. convert a BD-SUP from 1080p to 720p. Since BD-SUPs are the only SUPs supported by BDSUp2Sub, I thought this was pretty obvious. I'll edit the history though.

[hubblec4]

It's a "BD-SUP to BD-SUP" conversion actually. As discussed in the online help, it's meant to e.g. convert a BD-SUP from 1080p to 720p. Since BD-SUPs are the only SUPs supported by BDSUp2Sub, I thought this was pretty obvious. I'll edit the history though.

ok. i understand. thats helpful for the BD-Copy_Community...

I test your new version again and when i found some bugs i report this...

hubble

[avivahl]

Great work! :)

[SquallMX]

The program works great :D.

I just have a little request, the option to resize subs to 1440x1080p, it's a Bluray compilant resolution helpful for movies too hard to compress at FullHD 1920x1080p (if you don't want to use 720p).

:helpful:.

Thanks for your hard work.

[0xdeadbeef]

I just have a little request, the option to resize subs to 1440x1080p, it's a Bluray compilant resolution helpful for movies too hard to compress at FullHD 1920x1080p (if you don't want to use 720p).

I might add this in the next release. But here's the one for today:

10.03.2009 1.6 -> 1.7

BDSup2Sub now also works from the command line. See online help for parameter description.
Some minor tweaks and correction here and there
Optimized RLE encoding for SUPs a little bit (two pixels of the same color don't use RLE code)
Tried to add some better (?) fake time stamps to the ODS/WDS/PDS/END packets.

[0xdeadbeef]

Me again...

11.03.2009 1.7 -> 1.8

Fixed bug in the palette conversion introduced in r1.6 that could lead to artefacts on the left side of the subpic (SUB/IDX export only)
Fixed wrong alpha threshold default in command line version (SUB/IDX export only)
Introduced new resolution 1440x1080

[SquallMX]

Me again...

11.03.2009 1.7 -> 1.8

Fixed bug in the palette conversion introduced in r1.6 that could lead to artefacts on the left side of the subpic (SUB/IDX export only)
Fixed wrong alpha threshold default in command line version (SUB/IDX export only)
Introduced new resolution 1440x1080


:thanks: You're amazing, thanks for make this incredible program!!!

[0xdeadbeef]

13.03.2009 1.8 -> 1.9

Added support for reading HD-DVD SUPs (I own only one HD-DVD, so chances are it won't work with many HD-DVDs)
The same selectable values appear in the ComboBox for source and target FPS (still can be edited)
Reworked online help a little bit (working Hyperlink to Doom9 thread and copy to clipboard functionality)
Renamed Mode/Format ComboBoxes to "Output Format" and "Output Resolution"
Fixed wrong display of target image size (introduced in r1.6)

[rack04]

Does anyone have a sample m2ts with subs they wouldn't mind sharing?

[turbojet]

Thanks for the sup to sup conversion however I haven't gotten them to display while playing when muxing with tsmuxer. I've tested both resizing and not resizing, powerdvd 8 and mpc-hc. The sup I posted earlier also shows this issue. Could you look into this?

SupRip before the rewrite (I think it was 1.10 or earlier) handles these same sup files ok except some characters are skipped over and I gave up tweaking suprip after about 10 minutes. SupRip versions after rewrite crash on these files but I've seen this happen quite often with the later versions.

Also any chance of a wildcard string for input via command line?
e.g. java -jar bdsup2sub.jar C:\sups\* /res:720 would resize all sup files in C:\sups\ to 720 and adding 720 to each filename during output

rack04: there's an example .sup I posted in this thread from a full movie you can mux that with any video as a test if that's what you are looking for.

p.s. as megaupload seems to be gaining popularity is there any specific reason for preferring it with a silly captcha and wait times, which reminds me of old rapidshare without the speed limiting which raipdshare still has, over one without all this extra stuff like sendspace or mediafire?

[0xdeadbeef]

Thanks for the sup to sup conversion however I haven't gotten them to display while playing when muxing with tsmuxer. I've tested both resizing and not resizing, powerdvd 8 and mpc-hc. The sup I posted earlier also shows this issue. Could you look into this?
Indeed I fear that this is an issue of the PTS/DTS time stamps. While I would assume that all the image related data in the exported SUPs should be ok as should the PTS time stamps of the display start and stop commands packets (PCS), I kinda don't know how to recreate the PTS (and DTS?) time stamps of the other packets (WDS, PDS, ODS and so on). I don't really know why a Muxer would need these time stamps and can only assume that it's possible to detect the frame rate of the SUP stream via packet size/time stamp calculations. It's kinda weird though to not implement a fall back if this fails. It's no like HD-DVD-SUPs or SUB/IDX files would have this kind of information.

SupRip before the rewrite (I think it was 1.10 or earlier) handles these same sup files ok except some characters are skipped over and I gave up tweaking suprip after about 10 minutes. SupRip versions after rewrite crash on these files but I've seen this happen quite often with the later versions.
All my trials with SupRip ended in SupRip simply ignoring my SUPs without the slightest hint why it does so. Any kind of output would help. Heck, I even tried to dig myself though these Delphi sources, but I couldn't even find a single line of code that seems to be related to BD-SUP decoding.

Also any chance of a wildcard string for input via command line?
e.g. java -jar bdsup2sub.jar C:\sups\* /res:720 would resize all sup files in C:\sups\ to 720 and adding 720 to each filename during output
I'll put it on my list. I'd prefer a syntax like this though:

java -jar bdsup2sub.jar C:\sups\*.sup c:\sups\*_720.sup /res:720


p.s. as megaupload seems to be gaining popularity is there any specific reason for preferring it with a silly captcha and wait times, which reminds me of old rapidshare without the speed limiting which raipdshare still has, over one without all this extra stuff like sendspace or mediafire?
There's no special reason to use MegaUpload apart from the fact that it seemed to be popular, simple and fast (enough). Any suggestions?

[turbojet]

Maybe you could compare what BDSup2Sub at 720p outputs from the sup I uploaded earlier to what BD-Rebuilder outputs at 720p (http://www.sendspace.com/file/e8ohwr) to help debug it? (beware that BD-Rebuilder has bad alignment while BDSup2Sub has good alignment)

Even a lot of retail sups I've tried crash the latest SupRip versions, have you tried SupRip 1.01 or earlier?

Your wildcard suggestion makes more sense.

Sendspace (http://www.sendspace.com/) I prefer these days, it seems to have very good routing throughout the world and no captcha, wait, speed limit (it says it does but it doesn't), 300 MB max file size, basic online file manager and a standalone app that supposedly can resume and upload multiple files but I've never tried it.
Mediafire (http://www.mediafire.com/) is another good one but it has a popup window, 100 MB file limit (if it ever matters), not the greatest routing, probably < 95% uptime, and it has just a basic online file manager. I've come across some other ones that are 'clean' but I can't remember the names.

[0xdeadbeef]

Maybe you could compare what BDSup2Sub at 720p outputs from the sup I uploaded earlier to what BD-Rebuilder outputs at 720p (http://www.sendspace.com/file/e8ohwr) to help debug it? (beware that BD-Rebuilder has bad alignment while BDSup2Sub has good alignment)
I don't need to take that indirection as I can simply load any SUP, export it and compare both versions. Unfortunately, the matter is a little more complex than it might seem. See also here: http://forum.doom9.org/showthread.php?t=145654

Besides, BD-Rebuilder cheats around this issue by not touching any important data at all. It only patches the screen size and offsets and doesn't even touch the image data. Since it doesn't change any package length with this attempt, it doesn't need to recalculate the PTS/DTS time stamps and simply copies them. Anyway, this of course means that the subtitles appear quite a bit larger in a downscaled 720p, because they are scaled up together with the video picture.

Even a lot of retail sups I've tried crash the latest SupRip versions, have you tried SupRip 1.01 or earlier?
Apart from the fact that I mixed SubRip and SupRip, I think I know what crashes SupRip, but I honestly think that this is an issue with the RLE decoding there (accepts EOL only if the line is complete - which contradicts the idea of RLE compression). So while I think I could change my exports to satisfy SupRip, I'd rather see SupRip fixing this issue.

[turbojet]

Yup BD Rebuilder texts are huge after resizing to 720p which is annoying, hopefully that's fixed soon.

Ya I agree that it's SupRip's responsibility to fix it as the issue goes way beyond BDSup2Sub output. My current fix is to not upgrade, unfortunately this is a fix that is becoming more and more common these days with various software.

[SquallMX]

13.03.2009 1.8 -> 1.9

Added support for reading HD-DVD SUPs (I own only one HD-DVD, so chances are it won't work with many HD-DVDs)
The same selectable values appear in the ComboBox for source and target FPS (still can be edited)
Reworked online help a little bit (working Hyperlink to Doom9 thread and copy to clipboard functionality)
Renamed Mode/Format ComboBoxes to "Output Format" and "Output Resolution"
Fixed wrong display of target image size (introduced in r1.6)


Hi, is this a bug?, MKVMerge fails to load some parts of the subtitles created with BDSup2Sub:

Original Sub:
http://rapidshare.com/files/209412308/BRSup.rar

IDX/VobSub:
http://rapidshare.com/files/209412099/VobSub.rar

MKVMerge Error Code:
Warning: spu_extraction_duration: Encountered broken SPU packet (next_off < start_off) at timecode 00:55:09.556. This packet might be displayed incorrectly or not at all.
Warning: spu_extraction_duration: Encountered broken SPU packet (next_off < start_off) at timecode 01:07:35.676. This packet might be displayed incorrectly or not at all.

:thanks::helpful:

[saint-francis]

Same here.
http://forum.doom9.org/showthread.php?t=145416
I thought it was an issue with mkvmerge.
It doesn't seem to affect playback though.

[SquallMX]

Same here.
http://forum.doom9.org/showthread.php?t=145416
I thought it was an issue with mkvmerge.
It doesn't seem to affect playback though.

In my case, subtitles for that timecode don't appear (if I load the subtitles has external subs in MPC they work fine), everything else works perfectly.

[0xdeadbeef]

Hm, I converted the "Spanish.sup" and loaded it into SubtitleCreator. Can't see any overlaps there. Can you? Does any other SUB/IDX tool display overlaps?

Then again, this problem might be related to the fact that BDSup2Sub currently is a little relaxed when it comes to creating time stamps. Indeed, BDSup2Sub currently doesn't care for the target frame rate and simply uses a millisecond time stamp, no matter what the output frame rate is.

A multiplexer might stumble over this as the timestamps (and display durations) are supposed to be multiples of a frame duration. If they are not, rounding up an end time and rounding down a start time to the next multiple of the frame duration might indeed lead to the same value of start and end. Which however is still no overlap.

Anyway, I already started reworking BDSup2Sub to always work with the 90KHz time ticks and synchronize the time stamps to the target frame rate. I'm not completely convinced though that this will resolve this issue in all cases (especially when there's also a speed up/down involved).

[rack04]

I haven't had any luck converting .sup to .idx using the command line. Here is the command line that I'm using:

java -jar "C:\Program Files\BDSup2Sub\BDSup2Sub.jar" "C:\Personal\Videos\DELSCENE1.sup" "C:\Personal\Videos\DELSCENE1.idx" /lang:en /res:480

Using this command line I get ERROR: File C:\Personal\Videos\DELSCENE1.sup is not a valid BD SUP stream.

However if I use the user interface I'm able to convert the .sup to .idx no problem.

[0xdeadbeef]

Yeah, I kinda forgot to remove the file check for the command line interface. So it still blocks HD-DVDs from the command line. Will be fixed in the next release.

[0xdeadbeef]

16.03.2009 1.9 -> 2.0

SUP: palette is only exported up to the highest entry actually used (previous versions always exported 256 entries)
Increased resolution of all internal time stamps to 90kHz (was 1kHz)
During export, start/end time (or start/delay) are synchronized to the target frame rate (special handling for PAL, NTSC and 24P)
HD-DVD SUPs were refused from the command line: fixed.
New frame rate: 23.975Hz. equal handling of frame rates for command line and export dialog (e.g. aliases)
Frame rate info is written into the PCS headers of created BD-SUPs (and read for src fps detection)
Wildcard support for command line (read online help for details)

[0xdeadbeef]

Regarding the MKVMerge issue, I got a little more insight what causes this problem. Indeed MKVMerge doesn't complain about a time overlap, but about a "wrong" offset. This seems to happen for each subtitle that doesn't fit into one 0x800 bytes packet and thus uses an RLE buffer split over multiple (usually 2) packets.

While I'm not so keen to claim that there is no chance that I messed something in my implementation, chances are that MKVMerge doesn't consider multi-packets at all. At least the fact that VobSync is able to decode the multi-packet subtitles created by BDSup2Sub hints that the command buffer and the offset can't be that wrong. Besides, I'm pretty sure I saw multi-packet subtitles displayed correctly when used to create a DVD.

So this might be an issue of MKVMerge. I'm not yet 100% sure though.

[SquallMX]

Thanks for the update and the research, you're right, only MKVMerge has problems with the subs, others VobSub programs works fine (VobSub, DirectVobSub, MPC Subtitle Module, SubSync, etc).

:thanks:

[turbojet]

Thanks for the update and uniterrupted download of it.

I tried the wildcard cli: java -jar BDSup2Sub.jar "'00001*.sup' '*-bbsup2sub.sup /res:720"

and I got

OPTION: set resolution to 720p (1280x720)
Exception in thread "main" java.lang.NullPointerException
at BDSup2Sub.main(BDSup2Sub.java:313)

I tried with spaces (added ') and without spaces in path and also outputting to *.sub and also without resziing maybe I'm missing something?

Also exported sups (1080 and 720) are displaying correctly now in mpc-hc and powerdvd, great work!

[0xdeadbeef]

I tried the wildcard cli: java -jar BDSup2Sub.jar "'00001*.sup' '*-bbsup2sub.sup /res:720"

You don't need the single quotes here at all since the file names don't contain any space. So the following should do as well:
java -jar BDSup2Sub.jar "00001*.sup *-bbsup2sub.sup /res:720"

If you need the single quotes (due to spaces in file names), they have to be around a filename, not around filename+parameter. I'll improve syntax checking in the next version though to avoid the exception.

[turbojet]

With same files but no space in path I tried: java -jar BDSup2Sub.jar "00001*.sup *-bbsup2sub.sup /res:720"
and the same error popped up

I also tried: java -jar BDSup2Sub.jar "00001*.sup *-bbsup2sub.sup" /res:720
and got: ERROR: No extension given for target /res:720

[0xdeadbeef]

Ok, it has nothing to do with single quotes. It's just that I always tested with the source files in a path. So I overlooked that no path inside the source file name results in a null pointer exception.
Until I fix this in the next release, use the following workaround:
java -jar BDSup2Sub.jar ".\00001*.sup *-bbsup2sub.sup /res:720"

[turbojet]

Thanks that works, that's not a bad way to do it especially for people with linux experience.

[0xdeadbeef]

While we're at it, there are some restrictions to the characters that the wildcard will replace. Indeed more or less only alphanumeric characters (and ".") are supported. I guess I will switch to a more relaxed regular expression for the next release, bur for the moment, special characters like "(){}[]!%&§#~" etc. are not matched by the wildcard.

I also made some progress regarding the MKVMerge issue. Indeed it's really a bug in BDSup2Sub. It happens only for subtitle frames where the RLE data would fit into 0x800 bytes, but due to the control header, a 2nd packet is needed. In this case, the overall packet length is wrong which is exactly what MKVMerge reports (if you know how to take it). VobSub Resync seems to be pretty relaxed about this and SubtitleCreator crashes when it tries to show such a subtitle. I have also at least one report that hints that this could lead to problems with standalone DVD players.
-> Will be fixed in next version.

[hubblec4]

I also made some progress regarding the MKVMerge issue. Indeed it's really a bug in BDSup2Sub. It happens only for subtitle frames where the RLE data would fit into 0x800 bytes, but due to the control header, a 2nd packet is needed. In this case, the overall packet length is wrong which is exactly what MKVMerge reports (if you know how to take it). VobSub Resync seems to be pretty relaxed about this and SubtitleCreator crashes when it tries to show such a subtitle. I have also at least one report that hints that this could lead to problems with standalone DVD players.
-> Will be fixed in next version.

Thats sounds really good. Thanks again for your hard work!

I had converted some BD.sups and found another issue.
in the idx-file i found some entries like this:

timestamp: 01:26:34:439, filepos: 000ce2000
timestamp: 00:00:00:000, filepos: 000ce3800
timestamp: 01:26:39:444, filepos: 000ce6800
timestamp: 01:26:40:486, filepos: 000ceb800

thats the last 4 entries!

in another case:

timestamp: 01:26:37:775, filepos: 000cdc000
timestamp: 01:26:41:613, filepos: 000cdf000
timestamp: 00:00:00:000, filepos: 000ce2000
timestamp: 00:00:00:000, filepos: 000ce4000


i think this entries are to much.

hubble


sample (http://rapidshare.com/files/210564392/subs.rar.html)

[0xdeadbeef]

Approval may take a while, better use Sendspace or whatever. Then again I had enough for today anyway.

17.03.2009 2.0 -> 2.1

Fixed: usage of wild card from the command line would cause exception when source file name didn't contain a path
Fixed: wrong VobSub packet size if only the control header was shifted to the next packet, but the first packet was not completely filled.
Fixed: delay can be entered in milliseconds again. It's adjusted to target frame rate automatically.
Added command line parameter "/dly" to define a delay
Added target frame rate auto detection for command line
Changed command line parameter "/fps" to allow setting of only the target frame rate

[turbojet]

Wildcards are working as documented in the help now thanks again.
Without really bloating the cli help do you think wildcard usage could be added?

[hubblec4]

17.03.2009 2.0 -> 2.1


Fixed: wrong VobSub packet size if only the control header was shifted to the next packet, but the first packet was not completely filled.



this fix is ok. mkvmerge shows no warnings anymore.

but the 00:00:00-timestamp-entries are there.

thats the last entries in the idx-file(BDSup2sub v.2.1)

timestamp: 01:26:34:355, filepos: 000ccb800
timestamp: 00:00:00:000, filepos: 000cce800
timestamp: 00:00:00:000, filepos: 000cd1000
timestamp: 01:26:41:446, filepos: 000cd6000
timestamp: 01:26:41:613, filepos: 000cd8800
timestamp: 00:00:00:000, filepos: 000cdb000
timestamp: 00:00:00:000, filepos: 000cdc800

its possible to delete this entries automaticly?

sample (http://rapidshare.com/files/210567462/00116_-_31_-_Subtitle__PGS___French__1670_captions.rar.html)


hubble

[0xdeadbeef]

Invalid timestamp are usually corrected by BDSup2Sub. There are obviously special circumstances here that I need to examine.
It's also possible that I broke this correction (partly) in 2.0 or 2.1. It basically still works though, as I tested several SUPs with invalid time stamps before I released 2.1.
We'll see when I get back from work and can have a look at your samples.

[Edit]
Ok, let's say it will be fixed in the next release ;)

[0xdeadbeef]

Only one little change this time:
18.03.2009 2.1 -> 2.2

Fixed: missing end times were not handled correctly.

[hubblec4]

Only one little change this time:
18.03.2009 2.1 -> 2.2

Fixed: missing end times were not handled correctly.


thanks. now i think works the converting perfect!!

question: sometimes is the time too short for showing the subtitles.

is it possible manuelly change the start- and endtime in your tool? :-)


hubble

[Mtz]

I don't think that is possible. But maybe to add some check if a subtitle have duration under 1 second (23 frames), to automatically extend the duration to at least 23 frames for any subtitle, but with the caution to not overlap the timmings with the next one.

enjoy,
Mtz

[hubblec4]

ok but i hope 0xdeadbeef can find a way to implement this feature. because SubtitleCreater doesnt support 1080p.sub/idx-files at the moment.

hubble

[0xdeadbeef]

Editing the times/position is not really planned currently as it would involve a redesign of several program parts.

Detecting too short subtitles is something I thought about some time ago but simply forgot.
I'd like to output a warning as default and fix the length only if it's selected via (export) menu.

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

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

[cavediver]

Under the "Move all captions" option, what does the "Offset" setting do?

[0xdeadbeef]

Keeps the caption from the selected border.

[Ryu77]

I've had a quick read through and it's possible I may have missed the answer to the question I am about to ask, but...

Which would be the best tool to mux these newly created, DVD ready subtitles with the video and audio?

Is there a program as easy to use as tsMuxeR that I could load the video, audio and sub/idx files into and create DVD folders, ready for burning?

[SquallMX]

I've had a quick read through and it's possible I may have missed the answer to the question I am about to ask, but...

Which would be the best tool to mux these newly created, DVD ready subtitles with the video and audio?

Is there a program as easy to use as tsMuxeR that I could load the video, audio and sub/idx files into and create DVD folders, ready for burning?

Try Muxman, but you will need to convert the VobSub subtitles to .Sup (DVD format), you can do that with Subtitle Creator (The conversion is lossless).

:helpful:

[Ryu77]

Try Muxman, but you will need to convert the VobSub subtitles to .Sup (DVD format), you can do that with Subtitle Creator (The conversion is lossless).

:helpful:

Yes, in the interim I had actually tried that method and the result was an option to select a subtitle that didn't actually display??

I will experiment some more and see what I can work out.

PS: I am working with Vietnamese subtitles for my Fiance to watch English speaking movies a little easier (I am Australian).

[bananas]

Got this sup that I can't get to work in pdvd,but works in ps3.
warning: multiple PDS/ODS definitions: result may be erratic it says with v2.9
and no errors with v2.8.Opened it up in suprip seems it doesn't recognise the font.
It's a bd sup im trying to convert to 720p.Here's the link to the .sup http://www.sendspace.com/file/n7vfsi

[0xdeadbeef]

Got this sup that I can't get to work in pdvd,but works in ps3.
warning: multiple PDS/ODS definitions: result may be erratic it says with v2.9
and no errors with v2.8.Opened it up in suprip seems it doesn't recognise the font.
It's a bd sup im trying to convert to 720p.Here's the link to the .sup http://www.sendspace.com/file/n7vfsi

Maybe I missed the question!? Does the original SUP cause troubles in PowerDVD or the SUP exported by BDSup2Sub?

Anyway: this is one of the very few examples of a SUPs that not only has (redundant) repeated image data per frame, but also some of the images are corrupt. Since 2.8 had another (less exact) way of selecting the image if there were multiple updates per epoch, chances are 2.8 selected the non-corrupt version of the image (by chance) while 2.9 selects the corrupt one. There is one flag left that I currently don't take into account and that might be used to ignore invalid images. I'll have a look if doing so will help here.
Yet, I'm pretty much convinced that the authoring tool that created this stream is somewhat broken.

[bananas]

It's the exported .sup by BDSup2Sub

[0xdeadbeef]

It would help a lot to precisely describe the problem. What exactly happens in PowerDVD? Does this happen with SUPs exported by 2.8 as well etc.?

Anyway: I found a problem with fragmented image objects if there are also image updates in the epoch. Hope this will also fix the RLE decoder warnings in your SUP. Then again, this begins to get really complicated as it's hard to tell which captions animations should be displayed and which should be eliminated.

[bananas]

The text does'nt show up at all in pdvd in both v2.8 and 2.9.
I made some experimenting I ocr'd the original sup
to .srt and then opened it up in subrip and saved
it with ansi.After that I made an .sup file with supread
and opened it up in BDSup2Sub and converted to 720p.
That method got it to work besides letters like ♪ shows up
like this "?".Trying to open up a .srt saved in unicode
doesnt work in supread.So I guess the problem is letters
like this ♪ .Im kinda new to this,but that is the result of
my little experiment ;P

[0xdeadbeef]

The text does'nt show up at all in pdvd in both v2.8 and 2.9.
I made some experimenting I ocr'd the original sup
to .srt and then opened it up in subrip and saved
it with ansi.After that I made an .sup file with supread
and opened it up in BDSup2Sub and converted to 720p.
That method got it to work besides letters like ♪ shows up
like this "?".Trying to open up a .srt saved in unicode
doesnt work in supread.So I guess the problem is letters
like this ♪ .Im kinda new to this,but that is the result of
my little experiment ;P
All this SRT/OCR stuff has nothing to do with BDSup2Sub (which works on bitmaps only), so I'm still not quite sure how this related to the original problem.
Anyway, I analyzed your SUP and I figured out why BDSup2Sub has issues with it. Yet unfortunately I need to rewrite parts of the SUP parser (*again*) since there are some pretty weird things happening in this SUP that I didn't expect.
I'm not 100% certain that this will fix your problems with PowerDVD as it won't influence the structure of the saved SUPs. Also I understand the SUPs exported by BDSup2Sub are displayed by a PS3. Though I kinda lost track if the unmodified SUPs were displayed by the PS3 or if this was the case for the "experimental" SRT-cross-conversion.

[kikker]

Sorry for the noobish question, but I'm attempting to backup a BD title to 720p x264 encode in either of the MP4 or MKV containers. Is there a way to use this tool to convert the SUP to the SUB/IDX format as a stream wrapped in the MKV?

Or, is that the holy grail people are searching for at the moment. I've read conflicting reports that the SUB/IDX binary format can handle HD (720p or 1080p) subtitles. Even if it were possible to obtain this subtitle format, it seems there's not even a DS filter to play it. Please correct if I'm wrong. If a DS filter does not exist for this format, is there a "stand alone" player that could play back HD SUB/IDX?

Thanks for any info....

[rizu]

Even if it were possible to obtain this subtitle format, it seems there's not even a DS filter to play it. MPC-HC plays 1080p sub/idx just fine and so does MediaPortal with MPC sub-engine mod. I've tested both. Heard that vsfilter also would work but haven't tested it myself. I think all mentioned are based on same routines ( vsfilter ) when it comes to sub/idx rendering.

As mentioned before, vobsubs were originally meant to handle only DVD subs so 720p or 1080p subs are all non-standard and not likely to be supported on stand-alone devices..

[kikker]

MPC-HC plays 1080p sub/idx just fine and so does MediaPortal with MPC sub-engine mod. I've tested both. Heard that vsfilter also would work but haven't tested it myself. I think all mentioned are based on same routines ( vsfilter ) when it comes to sub/idx rendering.

As mentioned before, vobsubs were originally meant to handle only DVD subs so 720p or 1080p subs are all non-standard and not likely to be supported on stand-alone devices..

OK, great! Thanks...So, in theory, I could use this app to convert the SUP to a 720p SUB/IDX and have it played back by any directshow player? I should have clarified what I meant by "stand alone". I was really talking about other software players that have their own internal codecs/filters like VLC, but I suppose this doesn't matter to me at least, as I prefer directshow-based players.

I don't have a BD drive quite yet, so I can't really experiment with this app, but can it take the 1080p subs and downsize them to appear as normal on a 720p encode?

[hubblec4]

Sorry for the noobish question, but I'm attempting to backup a BD title to 720p x264 encode in either of the MP4 or MKV containers. Is there a way to use this tool to convert the SUP to the SUB/IDX format as a stream wrapped in the MKV?

Or, is that the holy grail people are searching for at the moment. I've read conflicting reports that the SUB/IDX binary format can handle HD (720p or 1080p) subtitles. Even if it were possible to obtain this subtitle format, it seems there's not even a DS filter to play it. Please correct if I'm wrong. If a DS filter does not exist for this format, is there a "stand alone" player that could play back HD SUB/IDX?

Thanks for any info....

Hi kikker

There is a way for you.

BDSup2Sub works perfect for 1080p.sup to 1080p.sub/idx conversion.
for playback you should use MPC-HC and this VSFilter-Version (http://www.animereactor.dk/aegisub/vsfilter-2.39c.rar)

this is an updated version by Aegis (http://www.animereactor.dk/aegisub/)

the subtitles looks like the original.

hubble

[saint-francis]

I am now using this tool to convert all of my BD subtitles to 720p and play them with 720p video in .mkv with mpc hc flawlessly. I haven't tried vsfilter though.

[rica]

Think about i extracted and accelerated video and audio to 25 via eac3to.
Shall i have to adjust sup to 25 manually?
Or any automatic way which is hidden in your tool?

[Rectal Prolapse]

0xdeadbeef, for your reference:

http://forum.doom9.org/showthread.php?p=1175551#post1175551

and

http://forum.doom9.org/showpost.php?p=1176156&postcount=4045

My tests were done using a screenshot of MPC (not MPC-HC) and the eyedropper color tool in irfanview or Photoshop to check the accuracy of the YCbCr->RGB conversions.

Technically, you should be using BT709 - as that is the color space used by all hidef material (all hidef broadcasts, all Blu-ray discs, and all HD-DVDs), and is also the default color space used by the typical computer monitor (BT.709 is the same as SRGB).

Supread I think uses BT601 and also expands to PC levels (white at 255, black at 0) instead of the technically correct white at 235 and black at 16. It is up to the user's player to do the proper expansion when rendering.

This is not a criticism of your tool (in fact I think it is a great idea - I was thinking of making a similar tool, but assumed there was a resolution limitation) - just want to give you basis for your tests. As you can see, I am anal about adhering to standards as closely as possible. :)

[0xdeadbeef]

Think about i extracted and accelerated video and audio to 25 via eac3to.
Shall i have to adjust sup to 25 manually?
Or any automatic way which is hidden in your tool?
That's up to your definition of "manually" and "hidden".
"Hidden":
After you loaded a SUP, a dialog called "Conversion options" pops up, which shows the source frame rate (read from the SUP, but it may be incorrect for exotic formats), an assumed target frame rate (merely based on the selected resolution) and a little checkbox that says "change frame rate".
"Manually":
Select the correct source and target frames rates and check the checkbox.

[0xdeadbeef]

My tests were done using a screenshot of MPC (not MPC-HC) and the eyedropper color tool in irfanview or Photoshop to check the accuracy of the YCbCr->RGB conversions.
[...]
Ok, so this is really (only) about accuracy. While I might change the color conversion anyway, this will only change the display of subtitles, not the exported SUPs (as I currently don't touch the palette at all). Besides, without extending the color space to 0..255, blacks will appear gray of course on a PC. That's why BDSup2Sub uses a version of BT.601 that's modified to extend to 0..255.

As you can see, I am anal about adhering to standards as closely as possible. :)
Your name made me guess so ;)

[magic144]

0xdeadbeef,

I've done a bit more digging
It seems perhaps VSFilter will let me vertically expand the subtitles on playback after all...

There's a setting under the General tab, under Picture Size, called "Vertical Padding" which has one value called "Extend to 16:9" which looks like it will show full-scale (1920x1080) subtitles exported from BDSup2Sub properly proportioned across the whole screen, NOT just within the confines of my cropped video encode (by default, this WAS set to "Original Height" which is what was giving me the vertically squashed presentation).

I'll do some further investigation on my end before you get too deep into implementing that Vertical Offset feature!

[0xdeadbeef]

To be honest, most of the code is already there, the only thing missing is the command line support. Yet I could quickly undo the changes if they prove to be useless. So please tell me when you're sure about it.
Then again, I'm still struggling with the BD-SUP parser anyway. Although I rewrote large parts again, I'm still not completely happy with it and it may take a while until I find a solution that works for all the problematic SUPs in my private zoo.

[Jaja1]

First of all, thanks for your tool. It helps me a lot.

I do have a question. I wonder why the 1080p sub/idx's are less smooth than the original sups which are 1080p as well. Any thoughts on that?

[0xdeadbeef]

I do have a question. I wonder why the 1080p sub/idx's are less smooth than the original sups which are 1080p as well. Any thoughts on that?
Sure and you would know the answer, too, if you read the online help.
In a nutshell: SUPs have an individual 256 color palette per caption, VobSubs have a fixed 16 color palette for the whole stream and only 4 colors of these 16 colors can be used per caption. As there's one color used as transparent color, this leaves 3 (more or less) opaque colors for the caption which is about 252 colors less compared to a SUP.
Obviously this doesn't leave much space for antialiasing and thus the images look less smooth.

[Jaja1]

Thanks for your answer.

And I did read the online help, from which I understood that the conversion to sub/idx results in a reduction of color information. However, my knowledge on this subject is way too little to see that this results in jagged edges.

[0xdeadbeef]

08.04.2009 2.9 -> 3.0

Changed: reworked BD-SUP parser again to support multiple object per epoch and to split the epoch were it makes sense.
Also equal captions can be merged now even if they're in separate epochs.
Changed: added cropping support (crop the first n lines)
Changed: colorspace conversion according to BT.709 instead of BT.601. Doesn't seem to make much of a difference though.
Fixed: the alpha fading detection for BD-SUPs could create wrong colors in certain cases.

[magic144]

Thanks for the update 0xdeadbeef

I tried out the subtitle cropping feature with my test movie/subtitle. Took me a while to realize I had to press the "Upper Bound" button instead of manually entering the "Offset Y value"!!

The original movie is 1920x1280.
I am cropping the video 140 pixels each, top and bottom, leaving 1920x800 (AR 2.4:1)

I used v3.0 using the "Move all captions" dialog, set AR=2.4, set the "move inside bounds" radio button and set a Crop Offset Y value of 140 (via the "Upper bound" button).

Only thing I have to do manually after export is change the Frame size in the idx file from:-

size: 1920x1080
to
size: 1920x800

(because I've remapped the subtitles into the picture-only area of the source video, thanks to the cropping) - so it's not a totally automatic procedure just yet. Of course 1080-2*140=800.

I tried it in BOTH VSFilter in ZoomPlayer, AND in VLC (a quite behind-the-times v0.8.6i Windows build!) and both rendered the subtitles at the correct AR.

I think this will now mostly benefit people who use VLC as their only playback solution since it allows the subs to be used in cropped encodes like this and still be shown at the correct AR.

Thanks for the work and quick support!

m

PS - by the way, is using REC.709 appropriate for non-HD resolutions?? I had read that it was only applicable for YUV to RGB conversions of HD material.
http://www.glennchan.info/articles/technical/hd-versus-sd-color-space/hd-versus-sd-color-space.htm
http://forum.doom9.org/showthread.php?t=133982

[Rectal Prolapse]

PS - by the way, is using REC.709 appropriate for non-HD resolutions?? I had read that it was only applicable for YUV to RGB conversions of HD material.

Well, considering that Blu-ray uses REC.709 and BDSup2Sub is (primarily) for conversion of subtitles from Blu-ray discs, I cannot see why this is an issue? However, I guess for SD subtitles a switch could be added for REC.601 (or maybe it can autodetect...)

0xdeadbeef: Thanks for the REC.709 support! Does it use the exact formula I mentioned? That preserves the original levels of the subtitles. But if you wanted to do levels expansion, you could always add a switch I guess. :)

[0xdeadbeef]

0xdeadbeef: Thanks for the REC.709 support! Does it use the exact formula I mentioned? That preserves the original levels of the subtitles. But if you wanted to do levels expansion, you could always add a switch I guess. :)

I'm using the following (partly self-constructed) formulas for BT.709 (based on Kb = 0.0722 and Kr = 0.2126):


/* BT.709 for RGB 0..255 (PC) -> YCbCr 16..235 */
y = 16 + (int)( r*0.2126*219/255 + g*0.7152*219/255 + b*0.0722*219/255 + 0.5);
cb = 128 + (int)(-r*0.2126/1.8556*219/255 - g*0.7152/1.8556*219/255 + b*0.5*219/255 + 0.5);
cr = 128 + (int)(r*0.5*219/255 - g*0.7152/1.5748*219/255 - b*0.0722/1.5748*219/255 + 0.5);

/* BT.709 for -> YCbCr 16..235 -> RGB 0..255 (PC) */
y1 = 1.164383562*y;
r = (int)(-253.3400548 + y1 + 1.833671233*cr + 0.5);
g = (int)( 79.05863261 + y1 - 0.218117304*cb - 0.5450762084*cr + 0.5);
b = (int)(-295.1907945 + y1 + 2.160630137*cb + 0.5);


As you can see, they include conversion from the 16..235 video range to the 0..255 RGB range, which is necessary to display correctly on a PC monitor.
Anway, I find it hard to see any difference compared to my BT.601 code: at least with the naked eye, the colors look the same to me.

[0xdeadbeef]

I tried out the subtitle cropping feature with my test movie/subtitle. Took me a while to realize I had to press the "Upper Bound" button instead of manually entering the "Offset Y value"!!
Well you don't have to. I just thought it would be more comfortable to set a sensible value with one click.


Only thing I have to do manually after export is change the Frame size in the idx file [...]

Hm, I was not quite sure about this indeed since I'm not really familiar with this use case. If this is an issue I could extend the cropping feature to assume symmetrical cropping and change the output screen size accordingly.


PS - by the way, is using REC.709 appropriate for non-HD resolutions??
AFAIK BT.709 is the color space used for HD video streams and BT.601 is used for standard definition sources. Still, currently, this is no problem, as only SUPs from HD sources are imported. The exported VobSubs are using a RGB (0..255) palette defined in the IDX file and the muxer or authoring tool has to convert this into an appropriate color space again. Besides, the difference between BT.601 and BT.709 are obviously not so big to be detect easily.

As a side note: the color model used in the IDX file is a little debatable, too. Indeed I didn't find any clear definition if it is always assumed to be RGB 0..255 or if some tools expect other color models (RGB 16..235 or YCbCr/YCrCb 16..235 or whatever).

Also the range of YCrCb/YCbCr values doesn't seem to be clearly defined. While the typical limits are 16..235 in video applications, there are some cases where this is extended to 16..240 - sometimes for all three components, sometimes only for the luminance (Y). Then again, it shouldn't really matter much in this context.

[magic144]

Well you don't have to. I just thought it would be more comfortable to set a sensible value with one click.
Oh OK - when I tried it, I don't think just manually entering a value worked, but maybe I was doing something wrong. It certainly didn't show the red line on the preview window until I pressed the button, as far as I remember. As for the size range and the symmetrical cropping, that sounds like the typical use-case, unless others think differently...

Still, currently, this is no problem, as only SUPs from HD sources are imported.
D'oh - of course! Just me being a bit stupid there. So are SUPs using YCbCr encodings then? Hence you have to choose an interpretation when converting to RGB.

I would have thought that the 16..235 luminance values would have been inherent in the subtitle source, if they were to match the underlying video (typically). Obviously, as we have just witnessed, I am not an expert :-)
The ffdshow "RGB conversion" tab (Constrast section) describes the "Standard" conversion as being Y:16-235, Chroma:16-240

Indeed the Wikipedia YCbCr page describes the RGB conversion as giving an output with Y(16-235) and CbCr(16-240).
http://en.wikipedia.org/wiki/YCbCr

ps - and again, THANKS for this great tool!

[0xdeadbeef]

Oh OK - when I tried it, I don't think just manually entering a value worked, but maybe I was doing something wrong. It certainly didn't show the red line on the preview window until I pressed the button, as far as I remember.
As for all text input fields in BDSup2Sub the value is only actually used if enter is pressed. That is by intention though, since the value is checked and written back to the text field. Personally, I hate text fields that do that while typing.

D'oh - of course! Just me being a bit stupid there. So are SUPs using YCbCr encodings then?
The palette entries of BD-SUPs and HD-DVD-SUPs use a YCrCb color model. Indeed, the exact color model used seems to depend on the video stream at least for BD-SUPs. BT.601 is used for standard definition sources and BT.709 for HD sources.
So for the rare case of SUPs with PAL/BTSC resolution I guess I'd need to select BT.601 and BT.709 for the rest.
But as I said, the difference between BT.601 and BT.709 seem to be neglectable when it comes to subtitles which seldomly use subtle colors (if at all).


The ffdshow "RGB conversion" tab (Constrast section) describes the "Standard" conversion as being Y:16-235, Chroma:16-240

In the meantime I came to the same conclusion and I will change this in 3.1. Yet, the difference will be hardly perceivable anyway.

ps - and again, THANKS for this great tool!
You're welcome, still it's always nice to get positive feedback.

[pleinlesyeux]

0xdeadbeef,

I just wanted to thank you for that great tool.

I allows me to offset the subtitles of a BD in the pictures, which is great when you have a 2.35 screen !!!

I used to manually trimmed exported .png then to reauthor my .xml and .png to recreate .sub. Took my hours. Now, 1 minute !!!

[0xdeadbeef]

Ah, another happy camper ;)
Still, there's always place for improvement.

10.04.2009 3.0 -> 3.1.0

Changed: depending on the resolution of an imported SUP, either BT.601 (PAL/NTSC) or BT.709 (HD) is selected.
Changed: cropping is assumed to be symmetrical and now also affects screen size in exported IDX or SUP.
Changed: reworked default VobSub colors a little to provide better anti-aliasing. Also white is used in combination with dark gray now.
Changed: minimum distance between two equal captions is now fixed to 200ms and doesn't depend on minimum display time any more.
Changed: merged code and look of preview windows.
Changed: all (?) edit boxes select smallest/biggest valid value if given value is out of bounds instead of just ignoring invalid inputs.
Fixed: Merging captions failed in certain cases, which also resulted in wrong end times
Fixed: BT.709 color space assumes Cr/Cb values to be inside 0..240 instead of 0..235
Fixed: exporting forced captions didn't work any more (introduced in 2.9)
Fixed: value for min display time is also used if fix short frames checkbox is unchecked.
Fixed: move dialog remembers screen ratio.

[kikker]

Fantastic App! Thanks very much. I do have a request of course ;)

Could you possibly implement a job queue of some sort such that many front end GUI encoders have? Once the jobs are queued up, they could then be started one after the other. Perhaps even a drop box to queue up the SUPs? Also, as direct VOBSUB (VSfilter) can read one IDX and one RAR'ed SUB for multiple languages, it would be fantastic to have that as a possible output as well. Thanks again!

[0xdeadbeef]

14.04.2009 3.1.0 -> 3.2.0

Changed: BD-SUP palette is created by default when scaling, mode can be selected (keep palette, new palette, dither)
Changed: reduced text output to a minimum. To get full output, select "verbatim" mode.
Fixed: progress bar was never updated when importing HD-SUPs, also cancel didn't work in this case
Fixed: progress bar didn't work for very large files (during load)

[avivahl]

Amazing work. It's wonderful to see such a professional free tool w/ an amazing development rate. Good job.
I hope you'll consider open-sourcing it one day (your code can probably help many open-source projects).

[alc0re]

Changed: BD-SUP palette is created by default when scaling, mode can be selected (keep palette, new palette, dither)

What exactly does that mean?

Well, let me ask a more direct question...if I'm just downscaling a BD-Sup to 720p to be burned back to an avchd/bluray structure...should I change my default back to keep palette?

[0xdeadbeef]

Before 3.2.0, BDSup2Sub used the existing palette for each caption. When scaling up/down, this led to suboptimal antialiasing in cases where the original palette didn't contain the according intermediate colors or versions of the same color with intermediate alpha values.

Although theses cases were rare, some people complained about it and so I decided to determine a new (optimized) palette when scaling. You can see the differences when changing the "palette mode" options in the GUI.

As the creation of a new palette proved to be about as fast as using the existing one, I decided to make this the default option. This shouldn't be a problem though.

So the answer is "no, you should get best results with the default setting".

[0xdeadbeef]

Amazing work. It's wonderful to see such a professional free tool w/ an amazing development rate. Good job.
I hope you'll consider open-sourcing it one day (your code can probably help many open-source projects).
While I still plan to release the source some day, currently, this is too much of a work in progress. Still, as written in the disclaimer, I'll give the source to everybody who asks nicely and agrees to some basic rules (mainly: don't release a branch with only your name in, give me credit if you use code, don't spread the code without asking me). Indeed, I already gave the source to one person already.

Besides, you can use the JAR as library for own Java projects. The Javadoc help is included and I can provide everyone interested with an example to use the Core classes (indeed the example is the main class of BDSup2Sub containing the CLI stuff).

[turbojet]

0xdeadbeef: I want to let you know that sendspace auto deletes files if they haven't been downloaded in 30 days. I recently found this out and got kind of burned by it.

Also did the command line change you recently did affect the convert to 720p subs from context menu I was trying to work out?
I spent a little time on it since the update but not a lot and somehow I broke default open application, probably CCleaner and now I can't seem to get it back.

Also while not a common situation do you know why this sup split with tsmuxer (http://www.sendspace.com/file/gupito) throws an error?

[0xdeadbeef]

0xdeadbeef: I want to let you know that sendspace auto deletes files if they haven't been downloaded in 30 days. I recently found this out and got kind of burned by it.
I guess I can live with that and I's suspect that every one-click-hoster will delete files after a while.

Also did the command line change you recently did affect the convert to 720p subs from context menu I was trying to work out?
I spent a little time on it since the update but not a lot and somehow I broke default open application, probably CCleaner and now I can't seem to get it back.
I'm not quite sure if I understand the question. I added the wildcard in the target name (only) as suggested some versions ago.

Also while not a common situation do you know why this sup split with tsmuxer (http://www.sendspace.com/file/gupito) throws an error?
Well, this stream start amidst an epoch. Indeed, it starts with a "NORMAL" PCS section, which is clearly invalid. Then again, I added another check to prevent the crash. Still, only 2 frames can be decoded from this sample. The first frame is incomplete and therefore lost.

[turbojet]

I meant does the cli changes you made doing anything to help out something like:
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 %1-720p.sup /res:720"

This is what no longer works for me but I think it's something with my system:
[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="C:\\Program Files\\java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar \"%1\""

A check would be nice as you never know when it may popup in a real scenario. I see suprip and eac3to don't like the stream either.

[0xdeadbeef]

I meant does the cli changes you made doing anything to help out something like:
[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 %1-720p.sup /res:720"
Yes, as I said I added support for a wildcard in the target some versions ago.
I just tried the following on my system:
[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="E:\\dev\\java\\jre_6_0\\bin\\javaw.exe -jar d:\\src\\java\\BDSup2Sub\\BDSup2Sub.jar \"'%1' '*-720p.sup' /res:720\""

Works perfectly for me. Adjusted to your system, it should look something like this:
[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="C:\\Program Files\\java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" \"'%1' '*-720p.sup' /res:720\""




This is what no longer works for me but I think it's something with my system:
[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="C:\\Program Files\\java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar \"%1\""

There's one double quote missing. It should be
[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="C:\\Program Files\\java\\jre6\\bin\\javaw.exe -jar \"F:\\TOOLS\\Sub Tools\\BDSup2Sub.jar\" \"%1\""

[turbojet]

Thanks.
My registry is messed up or something, I can't get 'Convert to 720p' to show even if I put in HKEY_CLASSES_ROOT\* nor can I get it to associate guess it's time for a windows reinstall.

[0xdeadbeef]

Hm, I can't really believe it's a windows issue.
Here's my complete test reg file for reference:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.sup]
@="SUP BD/HD-DVD caption stream"

[HKEY_CLASSES_ROOT\.sup\shell]

[HKEY_CLASSES_ROOT\.sup\shell\open]

[HKEY_CLASSES_ROOT\.sup\shell\open\command]
@="E:\\dev\\java\\jre_6_0\\bin\\javaw.exe -jar d:\\src\\java\\BDSup2Sub\\BDSup2Sub.jar \"%1\""

[HKEY_CLASSES_ROOT\.sup\shell\Convert to 720p]

[HKEY_CLASSES_ROOT\.sup\shell\Convert to 720p\command]
@="E:\\dev\\java\\jre_6_0\\bin\\javaw.exe -jar d:\\src\\java\\BDSup2Sub\\BDSup2Sub.jar \"'%1' '*-720p.sup' /res:720\""

Please note that my BDSup2Sub path doesn't contain spaces, so it doesn't need to be enclosed in double quotes.

If I import the above reg file and right click on a SUP, I can either open it or select "Convert to 720p". Both options work.

[turbojet]

I was able to fix the registry, there was HKEY_CLASSES_ROOT\sup auto_file\shell\open\command calling fastexplorer %1 which no longer exists. I deleted the sup auto_file key and now the .reg you gave me works great with 'convert to 720p' and 'open'

Thanks again

[0xdeadbeef]

18.04.2009 3.2.0 -> 3.3.0

Changed: added support for importing/exporting Sony BDN XML/PNG format (used by Sonic Scenarist).
Images are automatically cropped on import.
Changed: new command line option "/fps:keep" uses source frame rate as target frame rate (for BD-SUP and XML)
Fixed: a little inaccuracy in (all) the scaling algorithms led to suboptimal results.
The result of bilinear scaling is now very, very close to a reference implementation.
Fixed: conversion dialog fps comboboxes showed "29.967" instead of "29.97" for NTSC frame rates.
Fixed: crash when BD-SUP starts with invalid epoch.

[0xdeadbeef]

18.04.2009 3.3.0 -> 3.3.1

Fixed: using XML as input didn't work from command line if also a target was given.
Fixed: output resolution given via command line did not influence selection in GUI.

[mrr19121970]

nice tool. i tried to to convert the subs from HD-DVD Atonement and it worked as described.

I've integrated a call into Clown_BD to your util.

It would be nicer to have a 'quiet' mode that didn't write so much to the console (at least not a new line every time) and perhaps a /log=file.txt type option on the CLI.