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

[eTiMaGo]

OK, well I got VobSub Configure working (started it from the command line), so will try with the IDX method first since this seems the more "correct" way to do it :)

[r0lZ]

Also, the video attributes like width and height are also in the IFO file or is there also a way to get it out of the DVD SUP file, too?
A DVD subtitle is always 720 pix wide (less a few pixels), regardless of the resolution of the video. However, its height can change (576 or 480). I don't know if you can retrieve the correct height in the SUP, but again, you can probably assume that if there are no subtitles below 480, then it's NTSC stuff.

[SassBot]

That's nice, but perhaps you could add an option to assume that the SUP file comes from a DVD, even without an IFO. It is possible to fix the colours in the program anyway.

I'll tweak the prompt it so that the user is asked the file format rather than assuming anything.

BTW, in the IFO, it will not be easy to retrieve the correct palette. An IFO can have many PGCs, and a different palette in all of them.

That's why BDSup2Sub just reads the palette info from the first PGC.

[SassBot]

So looking deeper, it seems BDSup2Sub does not need an IFO file as just like with HD DVD SUPs, the width/height and palette info are in the SUP, too, and it actually reads this info for printing out when it is reading the DVD SUP file. I guess some programs don't read the info out such as Subtitle Creator which is why I assume it gives you the funky result it does, but I can't be sure without looking at it's code.

So what I will do is this: If a solitary SUP file is opened it will check to see if a corresponding IFO file with a matching file name exists. If one doesn't the user will be prompted asking if this is a DVD SUP file. If they say yes, it will prompt for an IFO to load (which can be canceled and it will just read the info from the SUP). If you say no, it assumes HD DVD SUP.

[eTiMaGo]

Success!!!!!

Maybe I got the procedur wrong for VobSUb but it gave me an invalid timecode error when loading the files into BDSup2Sub

But copying the IFO file (and renaming it to match the sup), worked! Those weird background parts are actually in bold :D

Soooo It looks like my firstborn will be named SassBot r0lz, I already pity him/her :D

Thanks ever so much guys, now I can enjoy my series in high def and my gf her subtitles in Thai, best of both worlds :)

[eTiMaGo]

Sassbot, I am uploading the IFO file from this particular title too:

http://dl.dropbox.com/u/1600280/Ep01.IFO

It might be useful to you for testing/debugging.

[SassBot]

Can you post the IDX/SUB files if you still have them? I'm interested to look into that. But I'm glad you fixed your problem.

[eTiMaGo]

Can you post the IDX/SUB files if you still have them? I'm interested to look into that. But I'm glad you fixed your problem.

LOL at your command:

http://dl.dropbox.com/u/1600280/VTS_01_0.idx
http://dl.dropbox.com/u/1600280/VTS_01_0.sub

[SassBot]

Thanks. If nothing else it will help make the program more error robust.

[SassBot]

Well the problem with that IDX/SUB pair is that the timestamps in the IDX file are all negative. According to a post in this thread (https://forum.doom9.org/showthread.php?t=57711) it's an old bug with Vobsub 2.23. I presume that's the version you used?

This post (https://forum.doom9.org/showpost.php?p=587277&postcount=10) also has a workaround to what causes the issue.

I don't think there's really anything I can do other than it just errors out. Unless the sub file has the run time length so that the negative timestamps can be offset.

[eTiMaGo]

Yep, is there a newer one? couldn't seem to find it

[SassBot]

No, the person who pointed it out said either to use an older version like 2.06 or you just use that other post's advice and see if you have a tiny blank cell and you want to uncheck it.

[SassBot]

Hmmm, interestingly enough it can read the IDX/SUB just fine even with the negative timestamps just by getting rid of the timestamp can't be less than 0 check. It will then even write out the IDX file with the proper positive timestamps when you export. So it looks like that error check wasn't correct.

Edit to add: Scratch that it wasn't outputting the timestamps correctly. It was just adding 5 seconds each time to give it positive timestamps.

[DoctorM]

A DVD subtitle is always 720 pix wide (less a few pixels), regardless of the resolution of the video. However, its height can change (576 or 480). I don't know if you can retrieve the correct height in the SUP, but again, you can probably assume that if there are no subtitles below 480, then it's NTSC stuff.

DVDs format specs-

NTSC:
720 x 480 pixels MPEG2 (Called Full-D1)
704 x 480 pixels MPEG2
352 x 480 pixels MPEG2 (Called Half-D1, same as the CVD Standard)
352 x 240 pixels MPEG2
352 x 240 pixels MPEG1 (Same as the VCD Standard)

PAL:
720 x 576 pixels MPEG2 (Called Full-D1)
704 x 576 pixels MPEG2
352 x 576 pixels MPEG2 (Called Half-D1, same as the CVD Standard)
352 x 288 pixels MPEG2
352 x 288 pixels MPEG1 (Same as the VCD Standard)

[SassBot]

Another question just to address the negative timestamp issue. I'm wondering if instead of error out if I should just let it read the IDX and then pop up a dialog warning the user that the timestamps are negative and they need to apply a delay to correct the issue. Does that seem okay? The file is valid other than the timestamps just need to be offset by the movie length.

[r0lZ]

@DoctorM: You gave the video resolutions. The subpics are totally different. It's why there are several subpictures for the 16:9 format (wide, letterbox, pan & scan). The subpic are applied by the player after the resize of the video to 720x480/576, and are therefore not related to the original resolution.

@SassBot: Good idea.

[SassBot]

Ok, so I've finished the fixes for the problems brought up yesterday. It no longer crashes on that original bad IDX/SUB pair, it will prompt you to apply a delay for the case of negative timestamps (and will error if you try to exit the conversion settings without setting one that makes the timestamps positive), and when it comes to loading a SUP with no file have a matching IFO name it will first try to load it as a DVD SUP and if that fails it will load it as an HD DVD SUP.

There will be issues with having no IFO to go with the SUP in the case of DVD SUP files. It will automatically assume 720x576 resolution and 25fps and the palette will use the default palette. The reason I can not reliably detect whether it's PAL or NTSC is that SUP files exported by BDSup2Sub (even if you apply no changes) have subpictures that are not the same size as the original subpictures. In what I'm guessing was a way to optimize output, BDSup2Sub only outputs a cropped version of the original subpicture and just modifies the X, Y position when creating the SUP frame so that it doesn't appear upon playback that the subpicture has changed. This means that SUP files straight from a DVD can be detected okay, but those that have already been run through BDSup2Sub will have wildly varying frame size info.

This means that if you load a DVD SUP file with no IFO and it's not PAL, you need to make sure in the conversion settings that you at least set the source and target frame rates to the proper NTSC values otherwise you'll get subtitles with a timing shift. You will also need to tell it the proper output resolution in case you do want NTSC output. Also, you will probably need to modify the imported DVD palette since there is no palette info without the IFO and the default palette will most likely yield results you won't like.

Lastly, I fixed a bug in the dialogs for editing the default/imported palettes that was causing the color icons to not properly update (they were invisible) if you imported a saved palette file.

New version to test is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

[r0lZ]

The reason I can not reliably detect whether it's PAL or NTSC is that SUP files exported by BDSup2Sub (even if you apply no changes) have subpictures that are not the same size as the original subpictures. In what I'm guessing was a way to optimize output, BDSup2Sub only outputs a cropped version of the original subpicture and just modifies the X, Y position when creating the SUP frame so that it doesn't appear upon playback that the subpicture has changed. This means that SUP files straight from a DVD can be detected okay, but those that have already been run through BDSup2Sub will have wildly varying frame size info.
Note that cropped subpictures can also be present in the original DVD. Although most commercial DVDs have full-size subpictures, cropped subpics are also common.

IMO, BDSup2Sub crops them because it's necessary if the user wants to move the subpic up or to the left, as the offsets cannot be negative. (Moving a full-size subpic down or to the right is OK, even if a part of the background is outside the viewable area, but of course, without cropping it, it is difficult to know if it will be entirely visible.)
BTW, DVDSubEdit has also an option to crop the subpics, for the same reason.

Perhaps you could try to determine if a DVD stream is PAL or NTSC by adding the height of the cropped subpic to the Y offset. If the bottom border of at least one subpic is below 480, then you can safely assume PAL. Unfortunately, it will never be certain that a subpic comes really from a NTSC DVD, if, for example, all subpics are on the top of the screen.

Anyway, the possibility to specify manually the video standard is important. (Not sure you did it already, but that option must be also available from the command line.)

[SassBot]

For now I'm just going to leave it up to the user to set the values since any detection code seems to be more prone to error than it will be worth to write. And, yes, all those values for resolution, fps, palette file are available by switches and have been from as far back as I've used the program.

[SassBot]

I just realized I forgot to put in the dialog to ask for the IFO file if a SUP file is loaded. Also, I've added in a warning that will show up in the GUI log and on the CLI telling the user that it is assuming 720x576 and 25fps when no IFO is specified to go with the input SUP file.

New version is here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

[r0lZ]

Error 404. Link broken?

[SassBot]

Try again.

[r0lZ]

Thanks!

I've just noticed a bug in the Edit Colours dialogue (of the java and ++ versions). Only the first 15 colours are present in the left pane. The last colour of the palette is missing.

[SassBot]

That's because 0xdeadbeef only had 15 colors defined for the default DVD Palette dialog list. The imported DVD palette dialog has all 16 colors (0-15) shown. I'll fix that and I have a version with a few other minor fixes too. For one thing, the IFO dialog was opening even when you loaded a BD SUP which was wrong so I've fixed that. There was also a drawing bug for the source/target image areas as well.

[r0lZ]

Thanks.

I have currently always "offset out of bounds" error messages with the java version, when importing a DVD SUP file extracted with PgcDemux. But your ++ version doesn't have that problem. Is it magic? ;-)
SubtitleCreator doesn't complain.
I don't understand the problem, as it's a DVD I use since yesterday to do my tests, and I have never had that problem before. Could it be caused by an option of the INI file?
What does that message mean exactly?

BTW, there is also a little cosmetic bug in the CLI output of the java version. Not checked yet with the ++ version.
When an error message is printed (beginning with "ERROR:"), the \n character is missing at the end of the line, and the "There was N errors" message is concatenated. No big deal...

Example:

#1
ERROR: Offset 3163498 out of bounds for file E:\TEMP\Subpictures_22.supThere was 1 error

[SassBot]

New version here: here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z) to address the things from the previous post. Last things I want to resolve before pushing the 1.0.0 release is getting the new CLI parsing in, the functionality to move from the original x/y positions from the CLI as r0lz asked for (the GUI allows this right now), and try to fix the outstanding issue that was in the original BDSup2Sub from here (https://github.com/mjuhasz/BDSup2Sub/issues/5).

[SassBot]

That would be because he forgot to add a new line character where as mine should properly newline every log output. Also, can you post the SUP you are talking about? The issue you may be seeing is that the Java version may be trying to read your SUP file as an HD DVD SUP. If you don't open the DVD SUP through the IFO file it defaults to reading it as an HD DVD SUP since it can't tell them apart by header. Mine doesn't fail because it first loads it first as a DVD SUP and if any exceptions happen it then tests it as an HD DVD SUP.

[r0lZ]

Also, can you post the SUP you are talking about?
Here it is: Subpictures_22_2.7z (http://download.videohelp.com/r0lZ/tmp/Subpictures_22.7z)

The issue you may be seeing is that the Java version may be trying to read your SUP file as an HD DVD SUP.I don't think so, as I gave him the /res:pal and /fps:25,25 options (but no IFO).

[EDIT] Previous link did not work. Updated with a correct URL.
I mean /res:pal /fps:25,25

[SassBot]

Can you post it somewhere that doesn't require a signup, please? :) But I can guarantee you the issue is that it's loading it as HD DVD SUP. It will only assume the SUP is a DVD SUP if you loaded the file via an IFO file of matching name. Specifying those parameters won't change that.

[SassBot]

To add the relevant code that choose how it reads the file is as so from the Java version:


if (xml || sid == Core.StreamID.XML)
runType = RunType.READXML;
else if (idx || sid == Core.StreamID.DVDSUB || sid == Core.StreamID.IDX)
runType = RunType.READVOBSUB;
else if (ifo || sid == Core.StreamID.IFO)
runType = RunType.READSUPIFO;
else
runType = RunType.READSUP;


Since it didn't have an IFO extension it is neither "ifo" nor of StreamID "IFO". Hence it chooses the "READSUP" path which branches between BDSUP and HD DVD SUP and since it will have the same header as an HD DVD SUP it will read it as the incorrect format.

[r0lZ]

OK, thanks. I'll have a look tomorrow.

[r0lZ]

Sorry. They have recently changed the rules at 4shared, and apparently, it is not possible any more to share a file!
I've uploaded the SUP here (http://download.videohelp.com/r0lZ/tmp/Subpictures_22.7z).

[SassBot]

Thanks. Yep, Java version is reading it as an HD DVD SUP.

[r0lZ]

OK, I'll play with IFOs tomorrow...

[r0lZ]

Just tried with the original IFO in the direcrory, but I can't get it to work. The java version still errors out.
Is it really sufficient to copy the IFO in the same dir and with the same filename (Subpictures_22.IFO in my example)? I've also tried to rename the files to VTS_02_0.sup and VTS_02_0.IFO, but still with no luck.

I think I'll definitively abandon the java version and stick with your much better ++ version. :-)

[EDIT] Got it! In fact, you have to load the IFO, not the SUP. In that case, the java version works fine. (The doc is very unclear on that point.)

[SassBot]

Yes, the Java version requires you to open the IFO file with a name matching your SUP file for it to be read as a DVD SUP. My version is smarter. :p

[SassBot]

So while fixing the issue from the original BDSup2Sub here (https://github.com/mjuhasz/BDSup2Sub/issues/5) I noticed a subtle bug I introduced in the YCbCr to RGB code within the palette class that caused the SUP's palette to be decoded incorrectly. So once again refreshing the test version with this new fixed one here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z). This just leaves the CLI parsing and r0lz's request and that should be enough for me to push the 1.0.0 final release unless any other bugs can be uncovered. ;)

[r0lZ]

Yes, the Java version requires you to open the IFO file with a name matching your SUP file for it to be read as a DVD SUP.
BTW, can you confirm that the arguments passed via the command line (and especially /pal: argument) take precedence over the IFO? (I need to give the correct palette, as otherwise BDSup2Sub uses the palette of the first Title PGC, not always correct.)

[SassBot]

Well the CLI help says "load palette file <s> - default: use builtin palette". I assume that means it would override but I will check to confirm it now.

[mjuhasz]

Yes, the Java version requires you to open the IFO file with a name matching your SUP file for it to be read as a DVD SUP.

The (Java) development version already has a fix for this (issue #9 (https://github.com/mjuhasz/BDSup2Sub/pull/9)). It will be released once I'm done with the CLI update and the outstanding issues in the GitHub tracker. One of them is actually a more robust way to load sup files (issue #4 (https://github.com/mjuhasz/BDSup2Sub/issues/4)) I agree that the documentation is not very clear on this. It should "just work" so instead of just improving the documentation I'll make it magically work...
BTW, the snapshot version is downloadable from GitHub. While I keep the development version stable it's still mainly for testers.

[SassBot]

The way I'm handling it now is that if it's not a BD SUP, open a dialog to ask the user for the IFO to go along with it. If they choose one then load the file as a DVD SUP. If they don't then first try to load it as a DVD SUP. If it's not a DVD SUP it will throw an exception and then I tell it to try it as an HD DVD SUP.

[DoctorM]

Something said had me thinking. That jitter that I was talking about earlier in the thread could be overcome if there was an option to not crop.

At the moment it's done to all subtitles whether it is needed or not. The ability to disable it would be useful since cropping is only needed for x/y changes. Simple resizing, retiming, format changes, etc. can all be done regardless of cropping (or the original size).
Just a thought.

Heck, even better would be on-the-fly detection/cropping. In other words, no cropping occurs unless a title is moved beyond the target frame size. And then perhaps just the minimum amount of cropping needed to make the move.

[SassBot]

Actually ignore that r0lz. Just giving it the palette to load seems sufficient. I misreading the code.

[SassBot]

Something said had me thinking. That jitter that I was talking about earlier in the thread could be overcome if there was an option to not crop.

At the moment it's done to all subtitles whether it is needed or not. The ability to disable it would be useful since cropping is only needed for x/y changes. Simple resizing, retiming, format changes, etc. can all be done regardless of cropping (or the original size).
Just a thought.

Heck, even better would be on-the-fly detection/cropping. In other words, no cropping occurs unless a title is moved beyond the target frame size. And then perhaps just the minimum amount of cropping needed to make the move.

Thank you for reminding me about that. Actually I believe the jitter is more likely due to it cropping certain subtitles by odd amounts. I'm going to put in a change that makes any cropping have to be a multiple of 2 that you can then try to see if that fixes your jitter problem.

[DoctorM]

Thank you for reminding me about that. Actually I believe the jitter is more likely due to it cropping certain subtitles by odd amounts. I'm going to put in a change that makes any cropping have to be a multiple of 2 that you can then try to see if that fixes your jitter problem.

Thank you. I will give it a go as soon as you make the change and report back.

[SassBot]

Once again, another refresh for a couple of other bugs I uncovered. Download here (https://github.com/downloads/amichaelt/BDSup2SubPlusPlus/bdsup2sub++.7z).

[Chetwood]

Note that cropped subpictures can also be present in the original DVD. Although most commercial DVDs have full-size subpictures, cropped subpics are also common.
Still, I'd prefer having an option to not crop the subs in case of some old standalones having issues with them. Another thing: in some cases BDSUP2SUB fixes "corrupt" Vobsubs automatically by opening and saving them. Is there a switch for the command-line that would open and save all subs from a certain folder so this could be done as a batch? Thx.

[SassBot]

Just pass in wildcard for input and output and specify no other options. That should give you what you want.

[Selur]

will bdsup2sub++ get or does it have some command line options?

[r0lZ]

Same as the java version. (Perhaps more in the future.) ;)