idx/sub demuxed from mkv conversion to srt?

[Yell]

I've demuxed the idx/sub stream from a .mkv file (with mkvextract from mkvtoolnix 1.4.1) but except from muxing them to another .mkv I cant do enything with the idx/sub files.
I want to convert them to .srt for example but subrip dows not recognize the these idx/sub files. Neither vobsub or media player classic does not load them for view...
Subrip gives me the "Bad Packet Header an LBA: ..." error.
Is there any way to convert them? :confused:
I've lost the original idx/sub files that I've muxed to the .mkvs, and I want to convert them to srt/ssa/ass... :(

[jff1625]

Try "Subrip"

J

[unskinnyboy]

Few things -

1) Do you have DirectVobSub installed?

2) Do you have the .idx/.sub filenames the -exact- same as the .avi filename? Else it won't autoload.

3) If you have tried 1 & 2, but no go and want .idx/.sub->.srt still, use subresync.exe bundled with your VobSub installation to do the conversion. Just open .idx/.sub and 'Save As' .srt.

[JoeBG]

Originally posted by unskinnyboy
... use subresync.exe bundled with your VobSub installation to do the conversion. Just open .idx/.sub and 'Save As' .srt.

Does this work correct? Are all characters readable?

[unskinnyboy]

You would have to input the characters like you do for SubRip. But unfortunately you cannot save the character matrix like you can for SubRip.

[Yell]

It is not a problem with loading the subtitle but the idx/sub stream saved by mkvextract is not recognized as an valid idx/sub stream...

The vobsub (I tried different versions) sometimes gives an error at loading, and in all cases does not display nothing, but is loading the stream... also the Media Player Classic gives an internal error when is loading the idx/sub stream :(
Subrip in best case recognize only the first line in idx/sub files, after that only gives the error: "Bad Packet Header an LBA: ..."
The subresync dispalys only the timing but it does not regognize the set of characters - the subtitle is blank. Subresync shows at CellID and VobID columns olny "Unknown".

[Yell]

Here are some test files, if you want to test and see my problem:
ftp://forum:forum@gvieriu.cs.tuiasi.ro
ftp://forum:forum@gvieriu.cs.tuiasi.ro/Test_File.mkv (20mb)
ftp://forum:forum@gvieriu.cs.tuiasi.ro/Track3.idx
ftp://forum:forum@gvieriu.cs.tuiasi.ro/Track3.sub

[niamh]

I can't seem to be able to connect

[Yell]

Alternative links:
http://eureka.cs.tuiasi.ro/~gvieriu/Test_File.mkv (20mb)
http://eureka.cs.tuiasi.ro/~gvieriu/Track3.idx
http://eureka.cs.tuiasi.ro/~gvieriu/Track3.sub

[niamh]

Hmmm not that it was necessary, as AFAIK mkvextract does not support extraction of idx/sub and never did :)

[Yell]

It does support the idx/sub stream extraction beggining with version 1.4.0 ...
The "Track3.idx", "Track3.sub" are extracted from "Test_File.mkv" from the files posted above with mvkextract from mkvtoolnix 1.4.1 package.
(command line: mkvextract tracks "Test_File.mkv" 3:Track3.idx)
The files "Track3.idx" and "Track3.sub" are the extracted streams and not the original ones.

[niamh]

Well the documentation hasn't been updated then :)

[unskinnyboy]

Looks like we have run up against a wall then. idx/sub in mkv does not work with VirtualDubMod or AVI-Mux GUI. And the ones you extracted crashes my Subresync.

How did you manage to put these inside the mkv in the first place?

[niamh]

Originally posted by unskinnyboy

How did you manage to put these inside the mkv in the first place?

mkvmerge has no problem with that at all

[niamh]

I have a couple of mkv with vosubs in them and I just tried it on them ( I tried yours myself and get the same error).. it works perfectly. So the error is in your subtitle file. There's something wrong with it.
Meaning, I don't think you can do anything about it.

[poutre]

Hello,

I have exactly the same problem, but a guy explained me why:

During the Matroska muxing process, Vobsub subtitles are modified and compressed in such a way that it causes a loss of informations in the subpicture stream and that it's impossible to convert them using OCR afterwards. There must have a slight decompression of some kind during the reading of the mkv which allows DirectVobSub to use the subtitles.
In brief, once muxed, Vobsub subtitles can only be displayed through the mkv. Of course, the problem is that mkvextract demuxes them in their raw form, which is unreadable.

To verify this, I created my own mkv with valid idx/sub files, then extracted them immediately after using mkvextract(GUI). The result is clear: both idx/sub are different from the original ones (their size have decreased), and neither Vobsub nor Subrip can reuse them. A quick look at the .idx shows that there have been some alterations (according to the Matroska procedure described here (http://www.matroska.org/technical/specs/subtitles/images.html)), yet it still seems reliable. As for the .sub file, I'm afraid there's nothing we can do about it.

From here, one can legitimely ask the question: what's the use of adding "Vobsub support" to mkvextract if you get files that not even Vobsub can read?

Now,
Originally posted by niamh
I have a couple of mkv with vosubs in them and I just tried it on them ( I tried yours myself and get the same error).. it works perfectly
Either the rule developed above is false (then what about my confirmation test?),
or your idx/sub files have something special,
or you're mistaken.
To know about this, I suggest that you create a mkv containing only a vobsub track with your valid idx/sub files, and that you upload it (size=light). Can you do this niamh, plz?

Sorry if I've made english linguistic errors.

[Yell]

But the question is: "If vobsub recognize the idx/sub stream in matroska files why can't the stream be converted to a .bmb files sequention?". The subrip accepts OCR from bmp files...
I will try to see if I can convert the .sub file demuxed to BMPs files...

[Yell]

You say that in mkv files some data is missing then why the vobsub loads the idx/sub stream from matroska and not from idx/sub files demuxed from a mkv file? Seems illogical...

[niamh]

@ poutre:
Well that's an interesting post, shame we had to wait 5 days for it :)
What you said makes sense, and I thought it was something like that, until it worked for me. I'll do as you say and post the file somewhere, as indeed it could be a fluke.

PS: your english is very good and clear ;)

[poutre]

Originally posted by Yell
You say that in mkv files some data is missing then why the vobsub loads the idx/sub stream from matroska and not from idx/sub files demuxed from a mkv file? Seems illogical...
Because, as I said, there must be a decompression of some kind that allows the subtitles to be read by Vobsub, and this decompression only happens during the reading of the mkv. There cannot be another reason. For me, the problem lies in their extraction, which is, I figure, incomplete.
As you said, the only thing we can do with demuxed idx/sub files is reuse them in another mkv.

[niamh]

Originally posted by poutre
Because, as I said, there must be a decompression of some kind that allows the subtitles to be read by Vobsub, and this decompression only happens during the reading of the mkv. There cannot be another reason. For me, the problem lies in their extraction, which is, I figure, incomplete.
As you said, the only thing we can do with demuxed idx/sub files is reuse them in another mkv.

Entirely agreed.

As for my extracted sub, as it turns out, only one language came out fine and OCRable, the others have been wiped out. I never checked :rolleyes:. So it was a fluke. But better than nothing to be able to extract them so as to remux them, as it used to be entirely impossible.

[poutre]

Originally posted by niamh
As for my extracted sub, as it turns out, only one language came out fine and OCRable, the others have been wiped out.
That's quite interesting. Which language is it? Maybe it has to do with the charset used in some foreign languages (just wondering, because all my subtitle tracks are french) :sly:.

[niamh]

the french one was saved :) I think it was the first one in the streams list, nothing to do with the actual language. I'll have to try another one and see

[poutre]

Ok, as you wish. Thanks for your help.

[niamh]

Well it can't be a special charset on an image file anyway. I've tried a few other streams, and nothing came out properly, only this particular stream, which was a funny coincidence.

[jjseth]

Since 1.4.0 MKVtoolnix with mkvextract can demux S_VOBSUB subtitles.
Mkvextract demux a couple of .idx/.sub files per language, if you muxed an .idx/.sub with three language you'll demux three .idx and three .sub.
This files can't be read with subrip or vobsub for conversion but if you remux one of this .idx/.sub demuxed in a new Matroska container VSFilter can read it without any problem....

For an easily Matroska demux you can use MKVextractGUI 1.5.3 (http://rapidshare.de/files/1219848/MKVextractGUI_1.5.3.7z.html) with Mosu's MKVtoolnix.

[miztadux]

I'm digging this old thread as I stumbled upon this very problem some days ago...

I wanna ask if there's anything new about this, can we properly extract vobsub from mkv now ?

I tried with mkvtoolnix 2.0.2 but the output is still mangled.

Thanks.

[LeMoi]

OCR works fine (at least with SubRip) but still with lot of overlapped subs. Mosu didn't find the problem so the bug is still present until now :/

[miztadux]

Ok, thanks for your reply fellow frenchman ! (maybe you're the only one who could understand my english accent ;))

In my experience with this problem, OCR with subrip is almost OK: most of the subpics can be OCR'd (except some frames that'll bring the "fill this manually" dialog and some others that "looks" interlaced and thus can't be parsed with a regular charmatrix) .
But, and this is where it bugs me, the timestamps are messed up: hence the massive overlapping.

PS:
On the timestamp issue, I figured out the original timestamps from the idx weren't kept in the ripped srt.
So this morning I tried to hack a little perl script that would take the timestamps from the idx and put them back in the srt (based on the occurrence number, using the idx timestamps as the begin time of the srt and figuring out the ending time as "timestamp + srt sub length")...
It works well with the first "direct ripped" sample idx/sub i had nearby but couldn't "fix" the problematic idx/sub i extracted from mkv, so more worked is needed here...

[miztadux]

In case someone has any interest in this, I uploaded the samples I worked on this morning.
(interstingly enough, the first handy idx/sub sample I found here was in a post from LeMoi (http://forum.doom9.org/showthread.php?p=951481#post951481)).
Here it is:
http://www.megaupload.com/?d=HD7N7X70

In the .zip you'll find these files:
- eng.idx/sub: the original sample
- eng.srt: the result of Subrip OCR on eng.idx/sub (using a done-in-2-secs matrix)
- eng.mks: a basic matroska file containing eng.idx/sub (built with mkvtoolnix 2.0.2)
- Track1.idx/sub: the vobsub extracted from eng.mks using mkvextract
(note: as explained in mkvmerge doc, the idx is the same without the comments. But the .sub has changed beyond my understanding)
- Track.srt: result from subrip OCR on Track.idx/sub
(note: comparing it with eng.srt, you can see the timestamps are all messed up at some point)
- out.txt: my attempt to fix the timestamps in Track1.srt using the method described above
(note: comparing it with eng.srt, you can see that every timestamp is now ok, except from the ending time on the one just after the first "skipped item" (n° 292) and the 2 last ones)

+

[miztadux]

I may have found a cause to this problem, at least for the sample idx/sub I talked about in the previous post.

A peculiar type of PES packets in the original .sub is modified by mkvmerge/mkvextract

I don't know where those packets come from but:
- MPEGPSUtils.exe (the tool i used to read packet headers) crashes on them
- idx/sub tools don't care about them (I mean they handle them well)
- it seems mkvmerge/mkvextract try to "fix" them.
- the mkv "fixed" packets make subrip go crazy

Some background:
In my (2 hours old, don't be too picky ;)) understanding of the .sub format, every PS packet contains at least a PES packet with a "00 00 01 BD" header which contains part or all the subpicture.
After the $BD PES there's a $BE PES packet that contains padding data (FF FF...).
The format of this $BE packet is really simple: "00 00 01 BE ?? ?? FF FF FF FF FF..." where ?? ?? is the 2 byte length of the padding data.

The problematic Packet:
"00 00 01 BE 00 00"
It doesn't contain any data, so the length is "00 00".
You will spot it in "straight-from-the-dvd" .sub files, when the empty space in the sector after the $BD PES packet is exactly 6 bytes (meaning the $BD packet length is exactly 2022=07 E6).

The problem:
In the .sub extracted from a mkv file, these packets are replaced with some other data, and a second PS packet/sector is added to the subtitle (so that the following "filepos" in the .idx changes too...).
The new packet contains what seems to be correct subtitle info, but that is not present in the original .sub.
(The next subtitle is then OK, there's just this extra packet in the middle)

An example:
Here is a screenshot from subtitle n°32 from the example I posted above.
Left side is the original (from eng.sub) right side is the one from the mkv (Track1.sub)
You can see how the mistery PES packet was replaced by a whole new PS packet...
http://img256.imageshack.us/img256/278/000001be0000ea0.th.png (http://img256.imageshack.us/my.php?image=000001be0000ea0.png)

The solution TODO:
I tried replacing the (2) broken packets of this kind I found in the example with the infamous "00 00 01 BE 00 00" bit, and this "fixed-by-hand" sub had no error at all in SubRip.
But i still need to find how to identify these "mkv-fixed" packets WITHOUT access to the original .sub to build a fix...

EDIT: I found where the new packet comes from...it's, as i sould've know, the subpic data from the next packet with a different header...
Here is a comparison of the "bad" packet (left side) with the folowing packet (right side):
http://img516.imageshack.us/img516/9008/dupehc4.th.png (http://img516.imageshack.us/my.php?image=dupehc4.png)

[LeMoi]

Maybe we could tell Mosu to have a look at this topic to see if he can help us, and see your explanation of te problem so that he can maybe fix the PS packet modifications :)

[miztadux]

I went way over my head with this...perhaps i shouldn't have look into this after all the drinks i had...

Anyway I didn't want to bring this matter into the mkvtoolnix thread as it felt it had more to do with vobsub/subrip than mkvmerge...

In the evening following my previous post I tried to investigate the problem using idx/sub ripped from off-the-shelf dvds with vobsub or vsrip...everything went fine. So it defenitly seems the cause is bad subs.

...

This morning I tried another spin, I quickly hacked a script that checks the "block size" headers from the PES packets and the sub packets. This way I could discard any subpic that didn't seem correct. (the "pes size" should be "data size" + headers/control)

Using this script on the various mkv-extracted faulty idx/sub files I had, I was able to get a "purged" file with some subpics stripped but correct timestamps. They can all be OCR'd fine.

That's enough for what I wanted to do (get the sync from the subs in the mkv files) so i guess that's it for me...

PS: Apart from the '01be000' bug I talked about earlier, the 2 other types of faulty pes packets i found had a PES_packet_size of either "1" or "65535"...it can't be good (overflow ?)

PPS: I attached a ugly perl script that does what's described here, it can salvage some vobsub files...

[multicone]

Someone with a good understanding should report this bug in mkvextract to Mosu. mosu AT matroska DOT org . Volunteers ?

[KoD]

miztadux said this is not a "bug in mkvtoolnix" but bad subtitles with incorrect info in the PES packets.

[LeMoi]

But original subtitles are fine, extracted one are bad -> it's a bug in extraction, so it's a bug from mkvtoolnix... :p

[Mosu]

Sounds like a bug in mkvextract from what I can see. I've created a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=245), but as I don't spend a lot time coding at the moment this has a pretty low priority for me.

[mahsah]

I have done this with subrip no problem.

[daxab]

@miztadux

You perl script is a life saver. I have used is successfully on several MKV-extracted idx/sub subtitle streams. It sometimes does nothing, it sometimes removes 1 or 2 subs.

However, I have one subtitle stream which, even when processed by fix_vobsub.pl, still fails when I try to use it (e.g. try to mux it back into an AVI with DivXMux).

Too bad mkvextract is still broken after a year...

[Mosu]

I've spent a couple of hours today on this problem. I've found out that there's a problem in mkvmerge, not in mkvextract, which causes one frame to contain more than one SPU packet. This is what miztadux saw when he wrote "In the .sub extracted from a mkv file, these packets are replaced with some other data, and a second PS packet/sector is added to the subtitle".

As this is a bug during the muxing phase there's nothing that mkvextract can do to correct such files.

I'd appreciate it if someone tested the whole process (merging, extracting, running VSRip or whatever other tool you want to use). Here's a new binary: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080819-1.rar

[ezb]

I'd appreciate it if someone tested the whole process (merging, extracting, running VSRip or whatever other tool you want to use).


Hello,

Thanks a lot for fixing this bug! I verified that one can mux the idx/sub, then demux them successfully (mmg 2.3). The resulting idx/sub plays with vsfilter and can be muxed again into Matroska.

However, there is a problem when trying to merge a set of demultiplexed subtitles (to generate a single idx and a single sub from several tracks, in case of demuxing several languages). I tried VobsubMuxer, but it rejects them. The documentation says that the application is picky, as to what it accepts. Would it be possible to have mkvextract merge them into a single idx/single sub pair instead of mutiple pairs?

Thanks again!

Eduardo

[Mosu]

Thanks for testing.

Actually mkvextract can already do that. You just have to give it the same file name for multiple vobsub tracks, e.g.

mkvextract tracks source.mkv 2:extracted.idx 3:extracted.idx 4:extracted.idx

This only works for a few container formats/track types, but VobSub is one of them. If two track types cannot be put into the same file (e.g. two text subtitle tracks into a single SRT file) then mkvextract will complain.

[ezb]

Thanks again!

I tried the mkvextract suggestion, worked fine. My standalone player chokes on idx/sub that are too large (over 30M), and I hope that this will fix it.

Best regards,

Eduardo