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

[laserfan]

Output still has "vertical jaggies" when converting to 720x480.

[0xdeadbeef]

It would be a miracle if the reduction of resolution wouldn't result in any drawbacks. We're talking of 1080 vs. 480 lines here or reduction to a 6th of the pixels.
Of course there are more complex filters that could improve the quality a little. Yet most of the complex resize filters are either aimed at upscaling or at photographic images. Palettized text with transparency and antialiasing in the source picture is not the typical scenario. Indeed filters like Bicubic Interpolation or Lanczos3 either have no benefit in this case or create artifacts like ringing.

[0xdeadbeef]

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


I've integrated a call into Clown_BD to your util.
A pretty sweet tool as well. If I hadn't decided to use EAC3TO directly from the console at some point, this would be my next choice.


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.
Why don't you just pipe the output to a file? And if you call Java via "javaw" no console window is opened at all.

[mrr19121970]

Why don't you just pipe the output to a file?


that's what I'm doing now, but my preferred method is to attach to the console (to show realtime progress). in atonement i got over 11K lines in the log, and this blew up the getconsole dll call.

here is a snapshot


Decoding frame 937/948 at offset 0x00c5c6a0
Decoding frame 938/948 at offset 0x00c5d004
Decoding frame 939/948 at offset 0x00c62742
Decoding frame 940/948 at offset 0x00c65d26
Decoding frame 941/948 at offset 0x00c68382
Decoding frame 942/948 at offset 0x00c6b41e
Decoding frame 943/948 at offset 0x00c6d754
Decoding frame 944/948 at offset 0x00c72c54
Decoding frame 945/948 at offset 0x00c79f70
Decoding frame 946/948 at offset 0x00c7dac8
Decoding frame 947/948 at offset 0x00c7fd62
Decoding frame 948/948 at offset 0x00c82364

Converting SUP(BD)

#1
DCSQ start ofs: 0x000011ad (00:00:59.393)
DCSQ stop ofs: 0x000015ce (00:01:01.589)
#2
DCSQ start ofs: 0x0000558c (00:01:49.109)
DCSQ stop ofs: 0x000059ad (00:01:50.543)
#3
DCSQ start ofs: 0x000096aa (00:02:15.969)
DCSQ start ofs: 0x000096b1 (00:02:15.969)
WARNING: DCSQ start ignored due to missing DCSQ stop
WARNING: Found faded alpha buffer -> alpha buffer skipped
WARNING: DCSQ stop missing.

the messages in red are good for the progress, and belong to the console, but not every message a new line.

I don't know JAVA, but I'm sure it's similar to this c# example


Console.SetCursorPosition(0,Console.CursorTop-1);
Console.WriteLine("Blah Blah");


the rest is good for a logfile

[0xdeadbeef]

the messages in red are good for the progress, and belong to the console, but not every message a new line.

I don't know JAVA, but I'm sure it's similar to this c# example


Console.SetCursorPosition(0,Console.CursorTop-1);
Console.WriteLine("Blah Blah");


the rest is good for a logfile

Unfortunately, there is no native support for terminal console output in Java. If there was, I would use it of course. However, the standard output is just a stream without the possibility to set the cursor position. Libraries like JCurses simulate a text terminal console in a graphic window, but this wouldn't help here. The only other way would be the use of a native code library. But this is a no-go for me.
If you want to show progress, why don't you pipe the console output to a file and periodically scan that file for changes. You could even filter these changes and create your own progress/status information from it.

[0xdeadbeef]

18.04.2009 3.3.1 -> 3.3.2

Fixed: exported PNGs had changed palette order (so palette entry 255 was not guaranteed to be transparent)

[laserfan]

It would be a miracle if the reduction of resolution wouldn't result in any drawbacks. We're talking of 1080 vs. 480 lines here or reduction to a 6th of the pixels.Of course--but as I posted in the other thread, BDSupEdit looks alot better (except for GZZ's red tinge).

[0xdeadbeef]

While I still think that for rescaling to 720p - which is probably the most common use case for scaling, more complex filters don't yield much better results, I agree that there's potential for scaling SUPs to PAL or NTSC. Not so much for VobSub though, as there are too few colors.
Still, the next version will offer various filters.

[0xdeadbeef]

Ok, here we go:

19.04.2009 3.3.2 -> 3.4.0

Changed: added miscellaneous scaling filter modes (amongst others: Bicubic, Lanczos3 and Mitchell)
Changed: improved quantizer to leave no multiple entries in the palette
Changed: rewrote PNG importer to use palette of image if that is possible
Fixed: added semaphore to synchronize GUI threads decoding captions (fixes crashes when quickly jumping through captions)

[kikker]

Thanks for your work on this project! Would you ever consider possibly implementing the capability to merge several SUPs into one IDX/SUB? As I'm sure you're well aware, VSRip rips the various sub streams from a DVD rip into one vobsub, and it would be very handy if yours did this as well, provided there was a way to have more than one SUP file as source of course. Thanks...

[0xdeadbeef]

Thanks for your work on this project! Would you ever consider possibly implementing the capability to merge several SUPs into one IDX/SUB? As I'm sure you're well aware, VSRip rips the various sub streams from a DVD rip into one vobsub, and it would be very handy if yours did this as well, provided there was a way to have more than one SUP file as source of course. Thanks...
I wonder if this makes sense at all for SUPs. A Demuxer like EAC3TO will extract the whole stream even for BDs using seamless branching. So for me this looks like a whole lot of effort for a very unlikely use case.

[laserfan]

Ok, here we go:

19.04.2009 3.3.2 -> 3.4.0

Changed: added miscellaneous scaling filter modes (amongst others: Bicubic, Lanczos3 and Mitchell)
Changed: improved quantizer to leave no multiple entries in the palette
Changed: rewrote PNG importer to use palette of image if that is possible
Fixed: added semaphore to synchronize GUI threads decoding captions (fixes crashes when quickly jumping through captions)
Thanks for the new version--my "vertical jaggies" issue in resizing 1080 to 480 is gone! :)

I especially like that selecting the filter mode (I think I prefer Lanczos3 in the little testing I've done so far) shows the result in the Preview window, although of course the proof is in the actual muxed output viewed on a TV.

Nice work, thanks again. :thanks:

[kikker]

I wonder if this makes sense at all for SUPs. A Demuxer like EAC3TO will extract the whole stream even for BDs using seamless branching. So for me this looks like a whole lot of effort for a very unlikely use case.

Thanks, but not sure if you know what I meant. If I have two (or more) SUPs (one in English and one in Spanish), I would like to have your app allow for the creation of one IDX/SUB combo, where the both languages can be read from the one vobsub with VSfilter. This is what VSRip does with DVDs, that is, it creates one IDX/SUB containing multiple languages. If you understood my request, then I'm not sure I understand your reply. In short, if it would be a relatively time consuming affair, then it may not be worth it for the subset of those who would like to see this feature.:thanks:

[0xdeadbeef]

Thanks, but not sure if you know what I meant. If I have two (or more) SUPs (one in English and one in Spanish), I would like to have your app allow for the creation of one IDX/SUB combo, where the both languages can be read from the one vobsub with VSfilter. This is what VSRip does with DVDs, that is, it creates one IDX/SUB containing multiple languages. If you understood my request, then I'm not sure I understand your reply.
I assumed you meant merging several pieces in serial. Then again, I still don't get the benefit of that request. What's wrong with exporting severals Vobsub files and then using them as input for an authoring tool/muxer/whatever? That's what I'm doing all the time.
Anyway: support for multiple input files at a time is very unlikely to happen.

[kikker]

Fair enough. I just like to archive the subs outside the container, and I can't think of anything else that might improve/enhance this app.

[saint-francis]

Fair enough. I just like to archive the subs outside the container, and I can't think of anything else that might improve/enhance this app.

Yeah, this tool is plain fantastic. It has worked perfectly for me for a while now. As far as I can see the only way to improve it would be to make it like vobsub in how vobsub doesn't need demuxed .sup's and can output multiple tracks in one set of sub/idx files like you say. These features are not necessary at all.

BDSup2Sub seems to be the final link in being able to work with the new format.

[Surf]

Hello,
As recent as version 3.2 I have not yet have a direct workable sub/idx when converting downward to 720x480 for DVD....
So far I have stumbled on this long roundabout way of achieving the muxable sup....

1st, using the SubToSup it and then load it to Dvdsubedit in which I need to adjust the blue color and de-emphasize to get the result.

Please, anyone who share a few pointers to get the sub/idx properly in one shot?

TIA.

[GZZ]

Tried your application 0xdeadbeef and it looks good, but the framerate conversion has a flaw or else I dont understand it correctly. If I load a sup file with a source framerate of 23.976 and set the target output to 25 fps then my input starttime on the first subtitle goes from 00:00:41.375 to 00:00:41.360, but if I in conversion settings click on "Change frame rate" and leave it at 23.976 fps (target fps is still 25fps), then my starttime goes from 00:00:41.375 to 00:00:39.680 like it should (from my own calculations).. Do I miss something here or is this a bug ?

Second when I load my first subtitle and set output resolution to 1920x1080 (same as input) then the coordinates calculated are:

Source:
Screen Size: 1920x1080
Image Size: 445x53
Pos: (737, 962) - (1182, 1015)

then the destination window shows:
Screen Size: 1920x1080
Image Size: 445x53
Pos: (737, 962) - (2657, 2042)

The resolution is the same, but how can it be the X, Y coordinate for the lower-right corner is set to a position which it out of the image resolution ?

[0xdeadbeef]

Tried your application 0xdeadbeef and it looks good, but the framerate conversion has a flaw or else I dont understand it correctly.
[...]
Do I miss something here or is this a bug ?

This is neither a flaw nor a bug and the behavior is explained in the online help.

In short: If you only set the output frame rate, the idea is firstly to patch a wrong frame rate to a correct value in the output stream (SUP/XML) without applying a speedup. Secondly this is meant to synchronize all time stamps to exact frame times. So even if the output frame frame equals the input frame rate, chances are that time stamps are slightly shifted by a few ms if the time stamps in the source files were not synchronized to the frame rate.

Only if the "convert frame rate" checkbox is activated, the frame times are really multiplicated by a speedup/speeddown factor that is derived from the given source and target frame rate. Of course the frames are synchronized to the output frame rate and the frame rate is written to the SUP/XML for this case as well.


Second when I load my first subtitle and set output resolution to 1920x1080 (same as input) then the coordinates calculated are:
[...]
The resolution is the same, but how can it be the X, Y coordinate for the lower-right corner is set to a position which it out of the image resolution ?
Thanks for reporting, yet this is just a dumb display bug. For the lower right coordinates, the screen width/height is added to the coordinates instead of the image width/height.
Will be fixed in the next release, but this doesn't affect the exported files in any way.

[GZZ]

In short: If you only set the output frame rate, the idea is firstly to patch a wrong frame rate to a correct value in the output stream (SUP/XML) without applying a speedup. Secondly this is meant to synchronize all time stamps to exact frame times. So even if the output frame frame equals the input frame rate, chances are that time stamps are slightly shifted by a few ms if the time stamps in the source files were not synchronized to the frame rate.

So if I get it right (from reading the help and what you are saying) you convert the last ms to frames and then round it to nearest integer frame.
Ex. 38 ms at 23.976 is 0,911 frame, its then rounded to 1 frame, which makes it 40 ms at 25 fps. Is there any benefits like better playback Compatibility ? Please explain. :)

If the above is correct, then why dosnt it apply if the input framerate match the output framerate ?

[0xdeadbeef]

So if I get it right (from reading the help and what you are saying) you convert the last ms to frames and then round it to nearest integer frame.
Ex. 38 ms at 23.976 is 0,911 frame, its then rounded to 1 frame, which makes it 40 ms at 25 fps.
Well, all times are handled internally in 90kHz resolution. This representation is rounded up/down to the nearest multiple of frame duration for all time stamps.

Is there any benefits like better playback Compatibility ? Please explain. :)
At least for VobSubs, a caption's display duration should always be a multiple of the frame duration.
Anyway, it simply doesn't make much sense to start or end a caption at any other time than a multiple of the frame duration. Indeed, for a display device running at the correct output frequency, it's plain impossible to display a caption "inbetween" frames.

So, while I'm not 100% sure that it helps for playback compatibility with BD-SUPs, it surely doesn't hurt. And the fact that BDN XML format is based on frames as well just goes to show that this approach is not completely senseless.

[GZZ]

So, while I'm not 100% sure that it helps for playback compatibility with BD-SUPs, it surely doesn't hurt. And the fact that BDN XML format is based on frames as well just goes to show that this approach is not completely senseless.

Thanks for explaning it.

[0xdeadbeef]

21.04.2009 3.4.0 -> 3.4.1

Fixed: scaling images from/to 1 pixel width/height led to division by zero/out of memory in scalers (happened with empty PNGs after cropping).
Now scaling from/to this small sizes is inhibited. Also bitmaps in the target are limited to a minimum of 2x2 pixels.
Fixed: lower right coordinates displayed for target were wrong, also the window offsets were displayed for the source instead of image offsets.

[alc0re]

0xdeadbeef

In regards to a few posts above this one...someone said he can't think of any other way to improve this great tool you have authored. I whole heartedly agree that this is an amazing tool that has saved me soooo much time having to ocr sup files. On that note I did think of something that would make this tool even better that I have been meaning to ask for but have forgotten to until now. I understand that you remove some of the special effects found in the .sup files because your original intent with this tool was converting to .sub format (or whatever the format is...the idx one.) But why remove those special effects when the target output format is bluray .sup? I think it would be the icing on the cake to leave those special effects intact when outputting to bluray .sup format, and would probably even improve the conversion from say a 1080p to 720p resize. As I understand it, having to remove some of those special effects can sometimes cause (as per your documentation) "unpredictable output." Anyways, just wanted to throw out that request. It might not be a very high priority for you and since I know nothing about programming, I really don't know how time consuming that would be.

Thanks again for your program.

[0xdeadbeef]

While this would be possible, there are quite a few problems with this feature. The main issue is that BDSup2Sub's whole design is based on the idea of plain captions (start, end, image). All the internal data structures are based on that idea and the parser is streamlined to simplify the SUPs during import.

Also, currently the lower window is a perfectly valid preview of the image stored in the output stream. Now for an animated caption that's updated every e.g. 40ms for dozens of times, what should I display? The idea of an animated preview gives me headaches for quite a couple or reasons. Then again, without animation, it would be impossible for the user to determine if using this "keep animations" feature would make sense at all.

There are lots of other issues though, e.g.:

I'd need to parse the input SUP differently depending on the output format.
Preserving palette animations would be extremely difficult if new palettes are created. Keeping the palette reduces the antialiasing quality though (at least if the original palette is lacking).
Calculating the correct PTS/DTS offsets for every element of a complex stream is quite a nightmare. Since there are still reports that BD-SUPs are not shown in PowerDVD and some standalones even for the extremely simple SUP format created by BDSup2Sub, I don't really expect I would get that to work in a reasonable amount of time.


Last but not least, I'd guess that about 1% of the SUPs on current BDs actually use palette or cropping animations. And I'd assume that in 90% of these few cases it's used for a simple alpha fade in/out. Now more or less rewriting the whole application to keep some alpha fading doesn't seem to be worthwhile.

[alc0re]

Yah I kinda figured that it would be a lot of work.

Oh well...if it gets implemented one day ok...if not the tool is still awesome.

Thanks

[GZZ]

I was coming to the same conclusion as 0xdeadbeef, also animated subtitles will be huge and I'm not sure the user will even detect the fade in/out as it only a 1-2 sec long, maybe it gives subtitles smoother preview, but when you have several subtitle after each other (because they speak alot and fast) animation would be almost nil. Been. I had one bluray once with a 1.2 GB sup file, all the subtitles was animated, sadly it was before I started working on BDSubEdit, so I dont have it anymore and cant remember the title. IHHHH!!!, but today I know why it was that big and still cant see the reason for it. Hopefully someone finds a bluray with a extreme subtitle file, could be fun to just see it in action, see if the animation gives the effect people are thinking about. But for BD5/BD9 keeping the subtitles to a minimum in size would be best. :)

[0xdeadbeef]

I was coming to the same conclusion as 0xdeadbeef, also animated subtitles will be huge and I'm not sure the user will even detect the fade in/out as it only a 1-2 sec long, maybe it gives subtitles smoother preview, but when you have several subtitle after each other (because they speak alot and fast) animation would be almost nil.
[...]
But for BD5/BD9 keeping the subtitles to a minimum in size would be best. :)
Well, this is a little simplified. Firstly, real bitmap animations are not removed by BDSup2Sub, only palette and cropping animations are. The space needed by cropping animations is more or less negligible, and palette animations can be rather small as well. While BD-SUPs can't redefine only the alpha channels (as HD-DVD SUPs can), BD-SUPs can use palette updates of only a few colors. E.g. If only 64 palette entries are faded out, this costs only 256 bytes per palette animation frame (not taking into account the size of the enclosing epoch frame etc.). So fading costs only a few kb per caption which is not too much compared with the typical size of the RLE buffer.

Also from my experience, very large SUPs are not blown up by palette animations, but by garbage which is really completely useless. Obviously the tools used for commercial authoring are pretty crappy. I saw SUPs were the RLE buffer of about each and every frame is repeated (byte identical) for 4 or 5 times. Apart from increasing the stream size, I can't seem to find any sense in this.

That being said: there is a small chance that some future version of BDSup2Sub might be able to keep/recreate cropping and palette animations. Then again, it's surely no high priority issue and currently I somewhat don't feel like messing around with the parser after it's finally working so good.

[alc0re]

Getting an error with the .sup from american gangster bluray.

Screen cap of error linked

http://www.mediafire.com/imageview.php?quickkey=tdynzjm2d2c&thumb=6

:thanks:

[GZZ]

you should upload the subtitle, so it can be tested.

[0xdeadbeef]

Yep, please upload the (zipped) SUP to a one click hoster and send me a PM. I'll have a look later - currently I have to earn my living (and we don't even have Java6 here) ;)

[pleinlesyeux]

Hi

I had a similar problem yesterday. The .sup would load, then when I specified the output res and click ok, got ugly java error messages I can't decipher at all.

I opened the .sup in supread, extract it to sup (yeah, doesn't make much sense to me)

Then BDsup2sub accepted it no problem. I'll test the backup today.

[0xdeadbeef]

Now really, what do you expect me to do with error descriptions like this???
Come on guys. How am I supposed to fix issues with SUPs if you don't give me the according SUPs???

Since obviously nobody reads it, let me quote the third paragraph of the initial posting in this thread:
To report problems with a SUP, please either post the SUP (if it is compliant with the forum rules) or upload it to a "one click hoster" and send me a PM with the link.

[0xdeadbeef]

24.04.2009 3.4.1 -> 3.4.2

Fixed: crash when the very last epoch was discarded because of missing ODS/PDS.

[Mtz]

Here is a m2ts sample from a HD camera: http://www.cstone.net/~dk/00009.m2ts
I extracted the streams, including subtitles with tsmuxer. When loading into BdSub2Sub, only 38 lines are processed. The PGS subtitle converted to SRT with SupRip resulted in 74 subtitles.
I saw in SRT, that in one second is displayed the same subtitle twice (0.5 sec.X2). In the BdSub2Sub processed SUP is one subtitle in one second, but not full 1 second, just half.
Requests:
- if is possible to export the same number of subtitles
- if is possible to move all subtitles to bottom-right corner. Now I can edit the frame, but the edited is not applyed to all. In move all captions I cant move X position, only Y.

Offtopic: strange is that the original m2ts played with no subtiles in MPC HC, but the remuxed m2ts with tsmuxer is showing the subtitles.

enjoy,
Mtz

[0xdeadbeef]

When loading into BdSub2Sub, only 38 lines are processed. The PGS subtitle converted to SRT with SupRip resulted in 74 subtitles.
Well, dunno what you were doing, but BDSup2Sub as well as as SupRip 1.14 both show 38 captions. Maybe you were using an older version of SupRip that processes multiple version of identical bitmaps differently.


I saw in SRT, that in one second is displayed the same subtitle twice (0.5 sec.X2). In the BdSub2Sub processed SUP is one subtitle in one second, but not full 1 second, just half.
Showing the captions twice is wrong, as replacing an image with the same image should be the same as keeping the image.
Therefore SupRip as well as BDSup2Sub keep the image and only update the end time.
Then again, it's true that SupRip creates longer display times (1s) than BDSup2Sub (0.5s) in this very special case. I'll have to take a closer look to see what's happening there, but I'd assume that this is probably a bug in BDSup2Sub.


Requests:
- if is possible to export the same number of subtitles

It is importing the same correct number as SupRip 1.14. Importing twice the captions would be wrong and for sure I won't consider to implement things that I know are wrong.


- if is possible to move all subtitles to bottom-right corner. Now I can edit the frame, but the edited is not applyed to all. In move all captions I cant move X position, only Y.

This is a very special use case and IMHO useless for movie captions. Dunno if I want invest time in stuff like this.


Offtopic: strange is that the original m2ts played with no subtiles in MPC HC, but the remuxed m2ts with tsmuxer is showing the subtitles.
The captions in the PGS are pretty uncommon. There's only one start epoch and then every new caption is appended as acquisition epoch. While this is allowed as far as I know, I have never seen this in a BD PG stream.
Also repeating the same ODS segment for every caption is useless at least and might lead to problems.
Tools creating SUPs usually create a simpler format that is easier to parse.

[0xdeadbeef]

26.04.2009 3.4.2 -> 3.4.3

Fixed: when merging equal captions inside an epoch, the end time was not always updated correctly.

[SquallMX]

26.04.2009 3.4.2 -> 3.4.3

Fixed: when merging equal captions inside an epoch, the end time was not always updated correctly.


Can you add to your ToDo list VobSub Input, please:o?, for people doing DVD2BD5 rips (You can put 2/3 480p movies in a single layer DVD with great quality) there is no way to keep subtitles unless you go the painful (and slow) "Vobsub-->OCR-->Spell Check-->TSMuxer" way. I now that DVD subtitles aren't that good looking because the 2-bit palette color but IMHO are better that OCR subs or no subs.

:thanks:

[0xdeadbeef]

If so, it would be really time for a new name. Who would guess that a tool that is called BDSup2Sub indeed converts Subs to BD-Sups ;) ?

[choyu]

@0xdeadbeef

Thanks for the great work.

Will it be possible later to add idx/sub(vobsub) input?

For me,I really hope that your great tool can convert idx/sub(vobsub) subtitles to BD sup,because I want to use this converted sup to mux with SD MPEG-2 video stream(720x480/576,VOB files) by tsMuxer and finally make it AVCHD playback in PS3 HDD.

Thanks again!

[0xdeadbeef]

Let's say I'm seriously considering it. Then again, don't expect anything to happen in the next days or so.

[kikker]

Would love the ability to input vobsubs as well and will wait patiently. Thanks, 0xdeadbeef

[Mtz]

That sample is from a HD cam and many people will buy HD cams. Some of them will want to keep their videos in HD format and want to see the date and time. Some of them will want to make a conversion including time code as subtitles.
Back ontopic:
SupRip 1.14 exported this srt because I unchecked "combine identical subtitles":
1
00:00:00,000 --> 00:00:00,565
MAR 11 2008 5:05:52PM

2
00:00:00,566 --> 00:00:01,065
MAR 11 2008 5:05:53PM

3
00:00:01,066 --> 00:00:01,566
MAR 11 2008 5:05:53PM

4
00:00:01,567 --> 00:00:02,066
MAR 11 2008 5:05:54PM

5
00:00:02,067 --> 00:00:02,567
MAR 11 2008 5:05:54PM

6
00:00:02,568 --> 00:00:03,067
MAR 11 2008 5:05:55PM

7
00:00:03,068 --> 00:00:03,568
MAR 11 2008 5:05:55PM

8
00:00:03,569 --> 00:00:04,068
MAR 11 2008 5:05:56PM

9
00:00:04,069 --> 00:00:04,569
MAR 11 2008 5:05:56PM

10
00:00:04,570 --> 00:00:05,069
MAR 11 2008 5:05:57PM

11
00:00:05,070 --> 00:00:05,570
MAR 11 2008 5:05:57PM

12
00:00:05,571 --> 00:00:06,070
MAR 11 2008 5:05:58PM

13
00:00:06,071 --> 00:00:06,571
MAR 11 2008 5:05:58PM

14
00:00:06,572 --> 00:00:07,071
MAR 11 2008 5:05:59PM

15
00:00:07,072 --> 00:00:07,572
MAR 11 2008 5:05:59PM

16
00:00:07,573 --> 00:00:08,072
MAR 11 2008 5:06:00PM

17
00:00:08,073 --> 00:00:08,573
MAR 11 2008 5:06:00PM

18
00:00:08,574 --> 00:00:09,073
MAR 11 2008 5:06:01PM

19
00:00:09,074 --> 00:00:09,574
MAR 11 2008 5:06:01PM

20
00:00:09,575 --> 00:00:10,074
MAR 11 2008 5:06:02PM

21
00:00:10,075 --> 00:00:10,575
MAR 11 2008 5:06:02PM

22
00:00:10,576 --> 00:00:11,075
MAR 11 2008 5:06:03PM

23
00:00:11,076 --> 00:00:11,576
MAR 11 2008 5:06:03PM

24
00:00:11,577 --> 00:00:12,076
MAR 11 2008 5:06:04PM

25
00:00:12,077 --> 00:00:12,577
MAR 11 2008 5:06:04PM

26
00:00:12,578 --> 00:00:13,077
MAR 11 2008 5:06:05PM

27
00:00:13,078 --> 00:00:13,578
MAR 11 2008 5:06:05PM

28
00:00:13,579 --> 00:00:14,078
MAR 11 2008 5:06:06PM

29
00:00:14,079 --> 00:00:14,579
MAR 11 2008 5:06:06PM

30
00:00:14,580 --> 00:00:15,079
MAR 11 2008 5:06:07PM

31
00:00:15,080 --> 00:00:15,580
MAR 11 2008 5:06:07PM

32
00:00:15,581 --> 00:00:16,080
MAR 11 2008 5:06:08PM

33
00:00:16,081 --> 00:00:16,581
MAR 11 2008 5:06:08PM

34
00:00:16,582 --> 00:00:17,081
MAR 11 2008 5:06:09PM

35
00:00:17,082 --> 00:00:17,582
MAR 11 2008 5:06:09PM

36
00:00:17,583 --> 00:00:18,082
MAR 11 2008 5:06:10PM

37
00:00:18,083 --> 00:00:18,583
MAR 11 2008 5:06:10PM

38
00:00:18,584 --> 00:00:19,083
MAR 11 2008 5:06:11PM

39
00:00:19,084 --> 00:00:19,584
MAR 11 2008 5:06:11PM

40
00:00:19,585 --> 00:00:20,084
MAR 11 2008 5:06:12PM

41
00:00:20,085 --> 00:00:20,585
MAR 11 2008 5:06:12PM

42
00:00:20,586 --> 00:00:21,085
MAR 11 2008 5:06:13PM

43
00:00:21,086 --> 00:00:21,586
MAR 11 2008 5:06:13PM

44
00:00:21,587 --> 00:00:22,086
MAR 11 2008 5:06:14PM

45
00:00:22,087 --> 00:00:22,587
MAR 11 2008 5:06:14PM

46
00:00:22,588 --> 00:00:23,087
MAR 11 2008 5:06:15PM

47
00:00:23,088 --> 00:00:23,588
MAR 11 2008 5:06:15PM

48
00:00:23,589 --> 00:00:24,088
MAR 11 2008 5:06:16PM

49
00:00:24,089 --> 00:00:24,589
MAR 11 2008 5:06:16PM

50
00:00:24,590 --> 00:00:25,089
MAR 11 2008 5:06:17PM

51
00:00:25,090 --> 00:00:25,590
MAR 11 2008 5:06:17PM

52
00:00:25,591 --> 00:00:26,090
MAR 11 2008 5:06:18PM

53
00:00:26,091 --> 00:00:26,591
MAR 11 2008 5:06:18PM

54
00:00:26,592 --> 00:00:27,091
MAR 11 2008 5:06:19PM

55
00:00:27,092 --> 00:00:27,592
MAR 11 2008 5:06:19PM

56
00:00:27,593 --> 00:00:28,092
MAR 11 2008 5:06:20PM

57
00:00:28,093 --> 00:00:28,593
MAR 11 2008 5:06:20PM

58
00:00:28,594 --> 00:00:29,093
MAR 11 2008 5:06:21PM

59
00:00:29,094 --> 00:00:29,594
MAR 11 2008 5:06:21PM

60
00:00:29,595 --> 00:00:30,094
MAR 11 2008 5:06:22PM

61
00:00:30,095 --> 00:00:30,595
MAR 11 2008 5:06:22PM

62
00:00:30,596 --> 00:00:31,095
MAR 11 2008 5:06:23PM

63
00:00:31,096 --> 00:00:31,596
MAR 11 2008 5:06:23PM

64
00:00:31,597 --> 00:00:32,096
MAR 11 2008 5:06:24PM

65
00:00:32,097 --> 00:00:32,597
MAR 11 2008 5:06:24PM

66
00:00:32,598 --> 00:00:33,097
MAR 11 2008 5:06:25PM

67
00:00:33,098 --> 00:00:33,598
MAR 11 2008 5:06:25PM

68
00:00:33,599 --> 00:00:34,098
MAR 11 2008 5:06:26PM

69
00:00:34,099 --> 00:00:34,599
MAR 11 2008 5:06:26PM

70
00:00:34,600 --> 00:00:35,099
MAR 11 2008 5:06:27PM

71
00:00:35,100 --> 00:00:35,600
MAR 11 2008 5:06:27PM

72
00:00:35,601 --> 00:00:36,100
MAR 11 2008 5:06:28PM

73
00:00:36,101 --> 00:00:36,601
MAR 11 2008 5:06:28PM

74
00:00:36,602 --> 00:00:00,-001
MAR 11 2008 5:06:29PM


http://img144.imageshack.us/img144/949/supripdate.th.jpg (http://img144.imageshack.us/my.php?image=supripdate.jpg)

The last line have the wrong time code and this is a known bug in SupRip. If not edited for example in 00:00:36,999, it will be skipped.
But the first time code is: 00:00:00,000 and this is very interesting because:
- if muxing the exported SRT with TSMuxer, in MPCHC the first subtitle will be this:
61
00:00:30,095 --> 00:00:30,595
MAR 11 2008 5:06:22PM

- if muxing the original MTS adding the exported subtitles by BDSup2Sub the first subtitle showed in MPC is:
MAR 11 2008 5:06:22PM
That is the same result as using SRT.

But if I edit the first line of SRT and put:
00:00:00,065 instead of 00:00:00,000, after remuxing with TSMuxer, all subtitles will be showed.

If muxing the original MTS with no changes the result will play all subtitles OK. And as I wrote, the original MTS played in MPCHC showed no subtitles, and I think TSMuxer is doing a good job.

I SupRipped the output subtitle from BDSup2Sub and the first time code was: 00:00:00,000 and maybe this is the reason why is not any subtitle showed until MAR 11 2008 5:06:22PM. But the question is: if the original SUP have the starting time code the same as BDSup2Sub export, why the original SUP from the exported TSmuxer M2TS is playing OK?

Also I saw some differences in the SupRip SRT file from the exported BDSup2Sub:
Original SRT:
1
00:00:00,065 --> 00:00:00,565
MAR 11 2008 5:05:52PM

2
00:00:00,566 --> 00:00:01,065
MAR 11 2008 5:05:53PM

3
00:00:01,066 --> 00:00:01,566
MAR 11 2008 5:05:53PM

BDSup2Sub SRT:
1
00:00:00,000 --> 00:00:00,541 (original is 565)
MAR 11 2008 5:05:52PM

2
00:00:00,583 --> 00:00:01,542
MAR 11 2008 5:05:53PM

3
00:00:01,584 --> 00:00:02,543 (original is 566)
MAR 11 2008 5:05:54PM

I see that 2 identical 500ms subtitles are intended to be "muxed" in 1000 ms subtiles by BDSup2Sub (but only 959ms achieved), but the interesting thing is that the 1 ms difference is in the starting AND finish timecodes as you can see on the red and blue marks.

Back to my requests, if is not possible to move all subtitles on the right corner, using BDSup2Sub for editing is useless, because original subtitles are displayed better than the actual output of BDSup2Sub. You can make a small test adding the exported BDSup2Sub subtitle with that file from my previous link and see:
- the position of timecode subtitles (personally I don't like that position, is a no brain position)
- not continuous play of the exported BDSup2Sub subtitle compared with the original. I agree is not correct to show twice the same subtitle but in HD cams example, the difference between 3 subpictures maybe to be 1ms to obtain a continuous play.

enjoy,
Mtz

[turbojet]

Another way for DVD to BD subs is to support dvd sup (http://www.sendspace.com/file/9u3dlo) input.

It saves a little time and quality over vobsub.

Outputting dvd sup format could be beneficial for BD to DVD conversions too.

[0xdeadbeef]

That sample is from a HD cam and many people will buy HD cams.
Which doesn't mean that all of them will create crappy PGS streams like this.


SupRip 1.14 exported this srt because I unchecked "combine identical subtitles":
Still, this doesn't make sense. If there's an update in an epoch and the ODS stays identical, there should be no gap visible. So merging the identical captions is correct.

But the first time code is: 00:00:00,000 and this is very interesting because:
- if muxing the exported SRT with TSMuxer, in MPCHC the first subtitle will be this:
61
00:00:30,095 --> 00:00:30,595
MAR 11 2008 5:06:22PM

Which is wrong.


- if muxing the original MTS adding the exported subtitles by BDSup2Sub the first subtitle showed in MPC is:
MAR 11 2008 5:06:22PM
That is the same result as using SRT.
Not surprising. Bug in either tsMuxer or MPC-HC. Who knows.


If muxing the original MTS with no changes the result will play all subtitles OK. And as I wrote, the original MTS played in MPCHC showed no subtitles, and I think TSMuxer is doing a good job.
Well, either tsMuxer or MPC-HC isn't.


I SupRipped the output subtitle from BDSup2Sub and the first time code was: 00:00:00,000
That's the first time stamp inside the original stream and it is preserved by either method.

But the question is: if the original SUP have the starting time code the same as BDSup2Sub export, why the original SUP from the exported TSmuxer M2TS is playing OK?
Hard to follow you here as you already claimed the opposite:

strange is that the original m2ts played with no subtiles in MPC HC, but the remuxed m2ts with tsmuxer is showing the subtitles.

Also I saw some differences in the SupRip SRT file from the exported BDSup2Sub:
If you read the online help, you'd knew that BDSup2Sub synchronizes time stamps to the output frame rate.


Back to my requests, if is not possible to move all subtitles on the right corner, using BDSup2Sub for editing is useless,

Then don't use it.

[shon3i]

Another way for DVD to BD subs is to support dvd sup (http://www.sendspace.com/file/9u3dlo) input.

It saves a little time and quality over vobsub.

Outputting dvd sup format could be beneficial for BD to DVD conversions too.
Outputing DVD sup will be ideal because all DVD mastering tools (IfoEdit, Muxman, etc) accept's only .SUP, to be hornest i newer saw any mastering DVD app that use SUB/IDX? correct me if i wrong, also since converting between SUP <-> IDX/SUB sometimes isn't possible, because only app can do this (SubtitleCreator) can properly open IDX/SUB files maded by BDSup2Sub.

[SquallMX]

Another way for DVD to BD subs is to support dvd sup (http://www.sendspace.com/file/9u3dlo) input.

It saves a little time and quality over vobsub.

Outputting dvd sup format could be beneficial for BD to DVD conversions too.

Second that:D!!!

[Mtz]

I wrote this:
the original MTS played in MPCHC showed no subtitles
and this:
the original SUP from the exported TSmuxer M2TS is playing OK
This mean that if only I open the M2TS in tsmuxer and just export it, it will play in MPCHC.

Even if the output framerate wasn't OK there is still a gap between subtitles:
2
00:00:00,583 --> 00:00:01,542
MAR 11 2008 5:05:53PM

3
00:00:01,584 --> 00:00:02,543
MAR 11 2008 5:05:54PM

But I found the good gap for the red and blue timings (1ms). Please check the reading/export timecodes in your program, because I think there is a bug.

Regarding the 00:00:00,000 problem, maybe you can add a hack that will put some value (for example 50ms) if the first subtitle start with 000 because will not hurt in any way the subtitles display.

I know in the first SRT example the FPS output was not correct but my observations are still valid even on a 29.970 FPS output regarding the red and blue. Same subtitles lines:
2
00:00:00,567 --> 00:00:01,533
MAR 11 2008 5:05:53PM

3
00:00:01,568 --> 00:00:02,534
MAR 11 2008 5:05:54PM

Correct timmings should be:
2
00:00:00,566 --> 00:00:01,566
MAR 11 2008 5:05:53PM

3
00:00:01,567 --> 00:00:02,567
MAR 11 2008 5:05:54PM

I hope at least to find the timming bugs and to implement the little 000 hack even if you don't want to make possible to move the subtitles on some corner. All I want is to help you with this nice application.

enjoy,
Mtz

[0xdeadbeef]

Even if the output framerate wasn't OK there is still a gap between subtitles:
Two captions can't be displayed at once. So when synchronizing the time stamps to the frame rate, one caption has to end one frame before the next one is displayed. That's not a gap as there's no frame without a caption.


I hope at least to find the timming bugs
AFAIK there are none.

[Mtz]

It seems that I can't explain better, sorry for my english. I will try again:
In the original SUP, these are the subtitles and the timmings:

2
00:00:00,566 --> 00:00:01,065
MAR 11 2008 5:05:53PM

3
00:00:01,066 --> 00:00:01,566
MAR 11 2008 5:05:53PM

4
00:00:01,567 --> 00:00:02,066
MAR 11 2008 5:05:54PM

5
00:00:02,067 --> 00:00:02,567
MAR 11 2008 5:05:54PM

Your program will join (which is correct) the 2 and 3 and of course, 4 and 5. But the resulted timmings must to be:

2
00:00:00,566 --> 00:00:01,566
MAR 11 2008 5:05:53PM

3
00:00:01,567 --> 00:00:02,567
MAR 11 2008 5:05:54PM

enjoy,
Mtz