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

Ryu77

6th April 2009, 00:02

SquallMX

6th April 2009, 04:49

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

6th April 2009, 11:22

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

6th April 2009, 11:46

0xdeadbeef

6th April 2009, 12:37

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

6th April 2009, 12:42

It's the exported .sup by BDSup2Sub

0xdeadbeef

6th April 2009, 13:28

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

6th April 2009, 19:22

0xdeadbeef

6th April 2009, 20:06

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

6th April 2009, 20:12

rizu

6th April 2009, 20:28

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

6th April 2009, 21:04

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

6th April 2009, 21:17

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

7th April 2009, 00:37

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

7th April 2009, 01:01

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

7th April 2009, 05:12

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

7th April 2009, 09:42

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

7th April 2009, 10:02

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

7th April 2009, 10:06

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

7th April 2009, 16:23

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

8th April 2009, 14:33

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

8th April 2009, 15:03

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

8th April 2009, 16:38

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

8th April 2009, 18:34

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

9th April 2009, 02:42

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

9th April 2009, 07:33

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

9th April 2009, 09:29

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

9th April 2009, 12:11

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

9th April 2009, 14:47

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

9th April 2009, 15:32

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

10th April 2009, 13:39

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

10th April 2009, 14:20

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

11th April 2009, 16:31

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

13th April 2009, 23:29

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

14th April 2009, 02:11

alc0re

14th April 2009, 04:18

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

14th April 2009, 11:46

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

14th April 2009, 11:54

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

16th April 2009, 08:29

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

16th April 2009, 17:17

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

17th April 2009, 06:52

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

17th April 2009, 10:20

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

17th April 2009, 10:41

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

17th April 2009, 10:57

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

17th April 2009, 11:26

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

18th April 2009, 11:51

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.