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

[Palmnut]

I'm trying to use the tool to convert .sup subtitles written by ProjectX from a UK DVB-T transport stream (25 fps). The program seems to work well for the vast majority of the subs, except where it detects that the end time for a subtitle overruns the start time for the following subtitle.

As a specific example:
Frame 41 starts at 00:03:42.470 and ends at 00:03:46.884.
Frame 42 starts at 00:03:46.880 and ends at 00:03:51.101.
Frame 43 starts at 00:03:51.100 and ends at 00:03:55.503.
Frame 44 starts at 00:03:55.500 and ends at 00:03:57.388.

Now in this case I would expect the tool to simply shift the end-time of 42 to 0.001s earlier (or 43 later). What I actually get is:
Frame 41 ok, with slight tweaks after the decimal points.
The start time of Frame 42 changes to 00:03:51.080 (near-enough the original start time of Frame 43), the end time of 42 changes to 00:03:51.120 (i.e. a duration of one video frame).
The start time of Frame 43 changes to 00:03:55.480 (near-enough the original start time of Frame 44), the end time of 43 changes to 00:03:55.520 (i.e. a duration of one video frame).

WTF? This means that I don't get to see Frame 42 or 43 at all - in fact this effect seems to ripple down the entire sequence until we get a long break in the titles.

Methinks you might have two variable muddled up when you try to solve this case, as it seems that the start time of the subsequent frame is being written in as the start time of the current frame.

Peter

[0xdeadbeef]

The root cause of such a problem is usually not really visible by just looking at the times. This is probably a combination of several issues, e.g. missing end times and missing start times. So as always, a sample is mandatory to have a look.

Anyway, keep in mind that BDSup2Sub's main purpose is not to fix broken subtitles. For a correct conversion it needs to have consistent timing, but this is not necessarily the same as correct timing. Therefore it outputs a warning for any fix that is done and leaves it to you to do a manual check/correction.

[DivxBr]

Hi, I was trying to find a simple and quick tool to convert '.sup' subtitles (DVD extracted with pgcdemux) to '.sub/.idx' to mux into a mkv container. But everytime I try the bdsup2sub to load the sup file, I get an error message like this: 'Offset 1091309618 out of bounds for file 'xxxxxxxx.sup'.
Maybe its a pgcdemux problem, or I'm doing something wrong?

[0xdeadbeef]

If I may quote the integrated help on this:

Notes on SUP/IFO
The SUP/IFO format as defined by IfoEdit/VobEdit is supported since version 3.9.0 due to public demand. Internally (e.g. regarding RLE encoding, palette definitions etc.) it's virtually the same as SUB/IDX. Note that there are some limitations to this format though. Firstly, the palette and the screen size are stored inside an IFO file. BDSup2Sub needs a valid IFO file for each SUP file and both have to share the same file name (except the extension of course). If you e.g. exported a file "english.sup" from a "VTS_02_1.VOB" and the according IFO is "VTS_02_0.IFO", then you need to copy the IFO and rename it to "english.ifo" to make BDSup2Sub accept it as input. Note that BDSup2Sub recognizes the extension "IFO" for SUP/IFO, but not "SUP". The reason is that BDSup2Sub can differ between BD-SUP and HD-DVD-SUP during import only because both format have different packet identifiers. Unfortunately, HD-DVD-SUP and DVD-SUP use the same (outer) package structure so they can only be distinguished between during parsing of the command buffer. At this time, BDSup2Sub already decided to treat a SUP with that package header as "HD-DVD-SUP" and will throw an error. When exporting, you should be aware that there are only PAL and NTSC resolutions defined in the DVD format (and therefore in the IFO).Thus hires or cropped formats will lead to major problems, even when importing these files back in BDSup2Sub. I'd strongly suggest to use VobSub in such cases.

If you don't have an IFO, you can use more or less any IFO as dummy replacement. Note though that the palette is loaded from the IFO.

[makmalimak]

I cannot see Turkish characters. What should I do?

[0xdeadbeef]

I'm undecided if this is a very strange posting by a human or an actually nearly brilliant posting by a spambot.
Anyway, I'm left puzzled.

[DivxBr]

Originally Posted by 0xdeadbeef

If I may quote the integrated help on this:



If you don't have an IFO, you can use more or less any IFO as dummy replacement. Note though that the palette is loaded from the IFO.

Thanks very much!

One more question: the ifo file has only one palette or there's one for each pgc or one for each subtitle? IF it has more than one, which one bdsup2sub uses?

[0xdeadbeef]

Originally Posted by DivxBr

One more question: the ifo file has only one palette or there's one for each pgc or one for each subtitle? IF it has more than one, which one bdsup2sub uses?

Well, this was a quick hack, but as far as I remember, there's one palette per PGC and BDSup2Sub uses the palette of the very first PGC. The dummy IFOs it creates are more or less empty apart from this one palette and some video attributes for PAL/NTSC.
As a quick way to get an IFO, you can load an SUB/IDX, edit the palette as you wish and store it as SUP/IFO. Then you can use this IFO as base for further palette edits.

[MadMonkey57]

Hi,

I am converting idx/sub to BD sup files:

- via GUI:
--> checking "Convert resolution to 1280x720"
--> change framerate from 25fps to 23.976
--> choosing "Mitchell" filter

...and it works fine.


via CLI: /res:720 /fps:25p:24p /filter:mitchell

OPTION: set resolution to 720p (1280x720)
OPTION: convert framerate from 25fps to 23.976fps
OPTION: set scaling filter to: Mitchell          

Converting SUP(BD)

Loading FR_FORCED.idx
# 1                  
# 2                  
# 3                  
...       
# 11                 

Detected 0 forced captions.

Writing FR_FORCED_CMD.sup
Decoding frame 1/11 at offset 0x00000000
Decoding frame 2/11 at offset 0x00001000
...
Decoding frame 11/11 at offset 0x00009800

... and fps seem to be NOT OK, still 25fps

Am I missing anything ?

Thanks

[0xdeadbeef]

Originally Posted by MadMonkey57

via CLI: /res:720 /fps:25p:24p /filter:mitchell

... and fps seem to be NOT OK, still 25fps

Am I missing anything ?

I fear you got me on this one. Indeed the source fps value given via command line is obviously overwritten later when the input stream is read. I guess I already found the problem and a solution, yet I want to fix this only after a little more investigation.
So probably no fix before the weekend.

[MadMonkey57]

Originally Posted by 0xdeadbeef

I fear you got me on this one. Indeed the source fps value given via command line is obviously overwritten later when the input stream is read. I guess I already found the problem and a solution, yet I want to fix this only after a little more investigation.
So probably no fix before the weekend.

Looking forward to testing it.

[0xdeadbeef]

15.11.2009: 3.9.8 -> 3.9.9

• Changed: added "auto" option for CLI switch "/fps:<x>,<y>", e.g. "/fps:auto,24p"
• Changed: added "/forceall" CLI switch to set/clear all forced flags
• Changed: reworked conversion dialog to allow setting/clearing all forced flags via GUI
• Changed: added an application icon to get rid of that coffee cup (note: ICO and ICNS files are included in the JAR)
• Fixed: source FPS given via CLI was overwritten by FPS read from stream
• Fixed: source FPS detection for SUB/IDX and SUP/IFO was buggy and (nearly) always resulted in 24p

[MadMonkey57]

Thanks for this update. Especially...

Originally Posted by 0xdeadbeef

15.11.2009: 3.9.8 -> 3.9.9

• Fixed: source FPS given via CLI was overwritten by FPS read from stream

..is working fine now.

[avivahl]

1st run (no ini file in dir), Settings->Conversion Settings->Nothing happens. Do I need to open a subtitle first? Bug?

[0xdeadbeef]

Hm, the dialog should open without a stream loaded. If it doesn't show without an ini file, this might indeed be caused by a missing INI file. Did you try that from the command line to see exceptions thrown? I'll have a look at it this evening.

Then again it's discussible whether this behavior makes sense or not. After all there's nothing to convert yet and after loading a stream, the conversion dialog will be shown anyway. Indeed I already thought about disabling the dialog before a stream is loaded.

So if this is a bug, it's pretty unimportant one and I'll only fix it with the next release but won't create a release just for this.

[EDIT]
OK, definitely a reference to uninitialized object. However since it happens in the (initialization of the) dialog, the exception is lost somewhere in the Swing jungle. As a side note, the existence of the ini file is not the factor that avoids the access to the object, but the setting of the "convertResolution" entry in the ini. If the entry is true, then the object is not accessed and the dialog is shown. If it is false (which is also the default setting when there's no ini or the entry is missing in the ini), the object is accessed, the exception is thrown and the dialog is not shown.
Anyway, it's already fixed locally, so it will be corrected in 4.0.0 but when this version is released is another question.

[avivahl]

Alright then. Thx.
Any planned "big features" for 4.0?

[0xdeadbeef]

Not at all. My "not so well thought out" version numbering now forces me to call the next version 4.0.0 for whatever reason I need to update.
However, currently there are only two minor bugs to fix and to call that 4.0.0 is a little too pathetic even by my standards.

[Sharc]

Problem with subtitles positioning (using the GUI):
- Extracting subtitles from DVD
- Converting to 720p SUP (BD)
=> Works ok so far.
However when I continue
- Move all captions => 'move inside bounds' => Move all
- Save/Export
the subsequent subtitles are all moved to the top left corner of the active picture instead of center bottom.
Do I miss something?

[0xdeadbeef]

Hm, can't seem to follow you here. Tried loading a PAL SUB/IDX, scaled it up to 720p, moved inside bounds, saved it -> Everything looks fine. Now it gets a little vague ... what does "subsequent" mean exactly here? I tried to "move all" repeatedly, I loaded the same SUB/IDX or PAL SUP/IFO, then moved it and so on. Whatever I tried, everything looked ok.

So, sorry, can't reproduce this. Either this is an issue with your subtitle (then I need it) or the instructions to reproduce the issue are not detailed enough (then I need more detailed instructions) or I'm just too stupid to understand this problem (then I might need some sleep).

At a 2nd thought, I could imagine a scenario were the extracted subtitles are all full screen either due to bad authoring or a bad extraction tool. Maybe cropping, scaling and moving at the same time is a scenario I haven't really tested. I'd need the subs then.

[0xdeadbeef]

Update: in the meantime I found a SUB/IDX with too large bitmaps that are cropped to the visible part by BDSup2Sub. With this stream I could reproduce the problem. Indeed there are two issues:

1) When applying the "move all" command to a stream with subtitles that are cropped due to oversized images, all subtitles are misplaced that were not (decoded and) shown before.

2) The "move all" setting partly survives loading another subtitle (indeed it should, but not this way). So when loading such a problematic stream with oversized images after "move all" was used, all cropped subtitles but the very first (which is automatically decoded and displayed) are misplaced without even using "move all" again.

Though I haven't actually found the bug (or even started looking for it), I'm pretty sure where to look. Unfortunately this is the most unpleasant part of the whole code, so fixing it will be probably slightly annoying. Then again, this will be fixed in the 4.0.0 release of course. Dunno if I'll manage to do it this weekend though, but I'll try.

Until then I can provide a temporary workaround: load the problematic stream into a freshly started instance of BDSup2Sub, then save it and load the saved stream. Moving should work ok now. Note that cropping itself works fine and when you save the stream before applying the move command, the cropped subtitles are saved with correct positions. Now if you load this fixed stream, the problem doesn't occur any more.