Log in

View Full Version : Bounty for dgindex Patch to Demux DVD Subtitles


CarlEdman
4th October 2010, 18:49
I am offering a $100 bounty (to be paid via PayPal or other convenient means) for a patch to dgindex that extracts DVD subtitles in addition to the audio and video streams it currently demuxes.

The subtitles should be extracted in .idx/.sub format similar to that currently generated by VobSub, but without using that buggy, non-portable, frequently incorrectly timed, always annoying program.

.idx/.sub is an image format, so OCR or the like would be required.

The generated idx/sub file should have timing information to match .d2v video index and audio files. So, if only a subset of a VOB file is being indexed, the idx/sub file should still match up.

The end results must be acceptable for re-muxing with mp4box (the minor requirements for which I'd be happy to explain).

Any patch would be put in the public domain (or licensed under an appropriate open software license) and submitted for inclusion in the main dgindex version, though that is of course not within the control of the author (or me).

An additional bounty is available if the program also extracts closed captions.

Please contact me via PM if you have any questions, want to verify my identity or have a proposal for something similar that doesn't exactly fit the bill, but might meet my needs anyway.

setarip_old
4th October 2010, 22:53
Hi!

Logically, I think you'd want to contact the author, "neuron2"...

CarlEdman
4th October 2010, 23:04
That's true, setarip_old, but the source code to dgindex is freely available from neuron2, http://neuron2.net/dgmpgdec/dgmpgdec.html, anybody could write the patch.

Neuron2 would of course be in the best position to do it himself and I think that likely would offer the best results, but from reading many of his posts in these forums, he does not appear to be all that eager in adding features (rather than fixing bugs) to dgindex which are of interest only to others. Should I have gotten the wrong impression, I'd be delighted to see him do it and get the small financial incentive.

The Scientist
5th October 2010, 01:14
Probably not what you were after but maybe for now my little utility I made some time ago may be of help?

Load in a file, or folder (can do hundreds of files), and it will make sure they all get 'indexed', you can also get it to extract subtitles and CC.
index.NET (http://forum.doom9.org/showthread.php?p=1378241#post1378241)

stax76
5th October 2010, 01:34
I gave up those old tools, default handling in StaxRip is MakeMKV > mkvextract > ffms2/DGDecNV, there are many DVDs with weird structure where old tools fail and new tools work. Adding such things to DGMPGDec and make it work with weird DVD structures like Casino Royal and many other weird DVDs would probably not be easy and not be too useful since new tools like MakeMKV work very well.

The Scientist
5th October 2010, 01:51
I gave up those old tools - there are many DVDs with weird structure where old tools failYou referring to 'index.NET'? It's not an old tool? It doesn't fail?

setarip_old
5th October 2010, 01:54
@CarlEdman

Should I have gotten the wrong impression, I'd be delighted to see him do it and get the small financial incentive. I'd suggest you PM him...

stax76
5th October 2010, 02:03
You referring to 'index.NET'? It's not an old tool? It doesn't fail?

I was referring mostly to DGMPGDec, VSRip/VobSub but also DVD Decrypter and PGCDemux and many others, development is stopped and there are bugs and limitations, sometimes they are still useful but most of the times there are newer/better/different tools like MakeMKV and mkvtoolnix that are still in active development and have various advantages. StaxRip supports old and new methods but the new ways mostly using MKV are usually better, MKV has highest priority in StaxRip and I think this is true in more or less all GUIs.

CarlEdman
5th October 2010, 14:57
Thanks for all the advice.

I should explain that a couple years ago I wrote my own Python front-end (dubbed 'makemp4') for x264, avisynth, a bunch of filters, neroaac, dgindex, VobSub, ccsubwin, DVD Decrypter, and a bunch of other tools which automatically converted my DVD collection for storage on my NAS/DLNA server in mp4 format complete with all the meta-data embedded in the files. Makemp4 just grinds away at whatever files it has available at low priority. It has no user interface, but allows for tweaking parameters in a variety of automatically generated config files. I've been very happy with the results which seem at least on par--and often superior--to anything I've seen elsewhere.

The only one of these tools with which I am seriously unhappy, for reasons stated above, is VobSub. Hence the bounty for a patch to dgindex (which has served me very well even with my most recent DVD purchases). As dgindex must already handle all the complications of DVD structure in order to extract its usual flawless video and audio, it seems that extracting one more set of streams, subtitles, would be a doable project.

Hence, index.net doesn't really help me. It adds a user interface for something I already do--in a way more convenient to me--automatically. I'd still use it manually for cases in which VobSub fails, but as index.net seems to be just another VobSub front-end, that is unlikely to help.

As for MakeMKV, I might give it a shot had I not long-ago standardized on mp4, rather than mkv. While each of these two modern and capable formats has its advantages, for now I'll stick with mp4, not just out of inertia, but also to have the movies readily play on my iDevices and to be able to use iTunes as a semi-decent juke box. If that ever changes, I believe it should be possible to losslessly convert from mp4 to mkv container without re-encoding or losing any meta-data.

By the way, how does MakeMKV extract subtitles? Is it just another VobSub frontend?

stax76
5th October 2010, 16:06
As dgindex must already handle all the complications of DVD structure in order to extract its usual flawless video and audio

It don't, you probably use IFO mode in DVD Decrypter ripping the movie title, that works most of the time, for some DVDs both DGMPGDec as well as VSRip/VobSub will produce sync issues.

By the way, how does MakeMKV extract subtitles? Is it just another VobSub frontend?

It rips each title as MKV, mkvextract can then demux audio and subtitles and ffms2 or DGDecodeNV can open the MKV file in AviSynth. If you have sync issues with VobSub you could also demux the VOB files with ProjectX, it has a option to demux VobSub subtitles.

CarlEdman
5th October 2010, 16:26
It don't, you probably use IFO mode in DVD Decrypter ripping the movie title, that works most of the time, for some DVDs both DGMPGDec as well as VSRip/VobSub will produce sync issues.
Fair enough. But, of course, the same is true with respect to the subtitles. Dgindex produces flawlessly synced audio and video for me (only rarely requiring manual cropping on an initial few black frames). VobSub routinely gets syncing wrong.
It rips each title as MKV, mkvextract can then demux audio and subtitles and ffms2 or DGDecodeNV can open the MKV file in AviSynth.
Yes, but how does MakeMKV extract the subtitles from the VOB? I've spent many many hours examining a dozen available subtitle extractors and have found that all fall into two categories: (1) VobSub front-ends; (2) alternative code which is broken even worse than VobSub. Does MakeMKV have its own code and is it better than VobSub's?

stax76
5th October 2010, 17:18
Overall I find the old method too troublesome because you never know when audio or subtitles will cause problems, the latest StaxRip version has various Preview options so it's easy to to verify, in the Subtitle tab there is a preview button to open a player to verify if everything (video/audio/subtitles) is synced properly.

MakeMKV creates MKV files, mkvextract demuxes so the vobsub subtitles are demuxed by mkvextract, I recommend MakeMKV as starting point for StaxRip, I have a huge sample collection for StaxRip development and this method didn't fail with any of my weird DVDs in my sample collection that cause various problems with other methods.

Chetwood
14th October 2010, 15:17
.idx/.sub is an image format, so OCR or the like would be required.
You meant, is not required, right?

But, of course, the same is true with respect to the subtitles. Dgindex produces flawlessly synced audio and video for me (only rarely requiring manual cropping on an initial few black frames). VobSub routinely gets syncing wrong.
From my own rippings I can tell you that those errors likely stem from cells left over from incomplete removal of current copy protections. Fengtao e.g. said that the only way to be sure all protections are removed with DVDfab is to rip main movie only. Since I'm doing that I've had no sync problems when encoding with AutoGK or extracting Vobsubs with VSrip. Funny thing is that when riping from Blu-ray to MKV this tool extracts all sub streams to an external idx/sub.

Yes, but how does MakeMKV extract the subtitles from the VOB?
Dunno but messages like "MakeMKV should process discs with most sophisticated protections without help of any 3rd party decryption software. In addition MakeMKV works faster and more reliably when it decrypts data by itself" I got when translating the GUI to German suggest it uses it's own routines.

Overall I find the old method too troublesome because you never know when audio or subtitles will cause problems
Well, as mentioned above I'm quite ok with Vobsub though I hate the batch functionality which never really works for me and I'm also still waiting for a tool that combines the features of Vobsubmuxer and Vobsubstrip.

CarlEdman
14th October 2010, 15:28
You meant, is not required, right?
Exactly. Thanks for the correction.
From my own rippings I can tell you that those errors likely stem from cells left over from incomplete removal of current copy protections. Fengtao e.g. said that the only way to be sure all protections are removed with DVDfab is to rip main movie only. Since I'm doing that I've had no sync problems when encoding with AutoGK or extracting Vobsubs with VSrip.
Interesting. Due to its cumbersome interface, lack of chapter extraction, and non-dumping of stream descriptions, I only use DVDFab when DVD Decrypter fails. Perhaps using DVDFab would be better, but unfortunately I usually only notice the broken subtitles at the end of the process, when restarting would be a pain. Also I'm not sure that it is a copy protection issue--more than half of my anime DVDs have the subtitle sync problem, but almost no others do.
Dunno but messages like "MakeMKV should process discs with most sophisticated protections without help of any 3rd party decryption software. In addition MakeMKV works faster and more reliably when it decrypts data by itself" I got when translating the GUI to German suggest it uses it's own routines.
Yes, and it does not include VobSub (or any other standard tool) in any obvious way. I look forward to giving it a try the next time I get some new DVDs.
Well, as mentioned above I'm quite ok with Vobsub though I hate the batch functionality which never really works for me and I'm also still waiting for a tool that combines the features of Vobsubmuxer and Vobsubstrip.
I've gotten the VobSub batch functionality to work 99% of the time. However, 1% of the time VobSub batch mode doesn't terminate when done, but waits for the user to click ok. It is always annoying to see that in the morning, when the computer should have been running x264 all night.

Chetwood
15th October 2010, 06:30
Due to its cumbersome interface, lack of chapter extraction, and non-dumping of stream descriptions, I only use DVDFab when DVD Decrypter fails.
You might use the split function for chapters in any case I'd give the latest version a try.

Also I'm not sure that it is a copy protection issue--more than half of my anime DVDs have the subtitle sync problem, but almost no others do.
Curiously enough DVDs ripped to VOBs were in sync. Only when using those as source for AVI encodes (and Vobsub in the process) the problems begin. Maybe it's only natural since standalones also usually ignore the garbage introduced by copy protections.

I've gotten the VobSub batch functionality to work 99% of the time.
I take it you haven't written your own tool but utilized

usage: rundll32 vobsub.dll,Configure <paramfile>

with a working parameter file?


EDIT: Concerning MakeMKVs possible releations to Vobsub, I just discovered this when opening an MakeMKV idx:


# VobSub index file, v7 (do not modify this line!)
#
# This index block was generated by MakeMKV v1.6.0 win(x86-release)
# which has no relation to VobSub software. The first
# line above is present for compatibility reasons.
#

CarlEdman
15th October 2010, 14:09
You might use the split function for chapters in any case I'd give the latest version a try.
I don't really want to split the file by chapters--just preserve the chapter markers for re-muxing at the end.
I take it you haven't written your own tool but utilized
usage: rundll32 vobsub.dll,Configure <paramfile>
with a working parameter file?
That's right.
EDIT: Concerning MakeMKVs possible releations to Vobsub, I just discovered this when opening an MakeMKV idx.
Excellent news! Can't wait to try it.

Chetwood
15th October 2010, 14:30
I don't really want to split the file by chapters--just preserve the chapter markers for re-muxing at the end.
Ripping main title or series episode in "main movie mode" will preserve chapter markers too in DVDfab.

CarlEdman
15th October 2010, 14:49
Ripping main title or series episode in "main movie mode" will preserve chapter markers too in DVDfab.
Interesting--I use the latest DVDFab Beta in main movie mode all the time. But where are the chapter markers stored? DVD Decrypter extracts them to a separate txt file which is easy to remux at the end.

Chetwood
15th October 2010, 17:32
Sorry, I forgot your method seems to include a bit more legwork. What I meant was that on playback of the ripped movie chapters can be selected (and maybe extracted as a text file with PgcEdit). If you were not set on MP4 a one-step-process with MakeMKV would save you lots of time ;)

Inspector.Gadget
15th October 2010, 19:11
DVD Decrypter extracts them to a separate txt file which is easy to remux at the end.

FYI, MakeMKV muxes a chapter file directly to the title MKV. The chapter times can be read by MediaInfo or MKVMerge (or in MPC-HC). I'm not sure whether MP4 muxers like mp4box accept chapter listings in OGG format (DVD Decrypter, MakeMKV, etc.), but it's trivial to make OGG chapters into plain text chapters with find-and-replace in your favorite text editor. I'm sure there's also some dedicated utility for this...

Inspector.Gadget
15th October 2010, 19:15
DVD Decrypter extracts them to a separate txt file which is easy to remux at the end.

FYI, MakeMKV muxes a chapter file directly to the title MKV. The chapter times can be read by MediaInfo or MKVMerge (or in MPC-HC). I'm not sure whether MP4 muxers like mp4box accept chapter listings in OGG format (DVD Decrypter, MakeMKV, etc.), but it's trivial to make OGG chapters into plain text chapters with find-and-replace in your favorite text editor. I'm sure there's also some dedicated utility for this...

CarlEdman
15th October 2010, 19:39
Thanks for the MakeMKV info, Inspector.Gadget and Chetwood. It does sound like a very impressive tool and re-muxing between MP4 and MKV is something I know how to do.

I take it MakeMKV just re-muxes all PGCs on a DVD above a threshold length into separate MKV containers without transcoding the audio or video? The transcoding process is something I like to keep more control over than any one-click tool I've seen allows. Also, does MakeMKV allow you to extract multiple DVDs at the same time using multiple DVD drives?

Inspector.Gadget
15th October 2010, 20:09
I take it MakeMKV just re-muxes all PGCs on a DVD above a threshold length into separate MKV containers without transcoding the audio or video?

Yes. You can control which titles are selected by setting a minimum title length threshold. As far as transcoding goes, FFMPEGSource() in Avisynth handles most things in MKV well. You'd have to check the FFMS thread to learn more about pulldown flag handling for DVD MPEG-2 content. If you've got DGIndexNV already, that will handle MPEG2-and-audio-in-MKV for indexing and pass it to Avisynth as usual (Force Film works too). Regular DGIndex requires you demux the MPEG-2 ES. I don't fully know the capabilities of x264's built-in LAVF input, but you may even be able to go directly from MPEG2+audio+vobsub in MKV to x264+audio+vobsub in MKV with x264 and mkvmerge.

Also, does MakeMKV allow you to extract multiple DVDs at the same time using multiple DVD drives?

I don't have the hardware set-up to do this, but given the design of the MakeMKV GUI, I imagine you'd have to run multiple instances of it (possible, I just checked) to accomplish this. Of course, you should check and make sure nothing gets fouled up on your first double/etc. rip.

CarlEdman
18th October 2010, 13:16
Thanks again to Inspector Gadget, Chetwood, stax76, and anybody else who recommended MakeMKV.

Now that I've tried it, I found MakeMKV to be a very solid piece of software. It does work on multiple DVD drives in parallel, it does create good MKV files, and--best of all--it actually creates correctly-timed idx/sub subtitles from DVDs too borked for VobSub and anything else! It even appears to get the chapter timing exactly right (where DVD Decrypter appears to drift off by a few seconds over the course of a 2-hour movie). Its interface seems a little clumsy in spots and its handling of DVDs with structure errors used for copy protection appears to be not quite as strong as DVD Fab Decrypter, but happily it works fine on the output of DVD Fab Decrypter.

Now I just have to rewrite my python tools to automatically demux the MKVs, re-encode the MPEG-2 and AC-3 streams, and then remux the bunch into MP4s. Fun, fun, fun!

PS: Does mkvextract have an option to just dump out all tracks in their native format or do you have to parse mkvinfo to construct a command line to do that?

Chetwood
18th October 2010, 14:36
Why re-encode streams?

Inspector.Gadget
18th October 2010, 15:05
MKVExtract does not, I believe, but eac3to does.

CarlEdman
18th October 2010, 15:56
Why re-encode streams?
For the MPG2 video streams extracted from DVDs, because x264 and appropriate filters will produce a result which is smaller by a factor of 5 to 10 and can look better than the original.

For the AC-3 audio streams, because AAC streams can be substantially smaller at same quality and many MP4 players do not accept AC-3 audio streams.

Chetwood
19th October 2010, 06:38
I doubt that a re-encode can look better than the original but I get what you mean. I've decided to stick with AVI for SD material but when it comes to HD my money is on MKV.

CarlEdman
19th October 2010, 11:34
I doubt that a re-encode can look better than the original but I get what you mean.It is of course true that the re-encode can't contain more information or detail than was somehow present in the original, but the filter I use on most material does greatly reduce digital noise and make the end-product look better (to my eye) than the original.SetMTMode(2,0)
...
Interleaved2Planar()
super = MSuper(planar=true)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
bv3 = MAnalyse(super, isb = true, delta = 3, overlap=4)
fv3 = MAnalyse(super, isb = false, delta = 3, overlap=4)
MDegrain3(super,bv1,fv1,bv2,fv2,bv3,fv3,thSAD=400,planar=true)
Planar2Interleaved()
Distributor()In principle, you could of course run this filter at display-time, but they are much too slow to do in real-time on almost all current display devices. And by filtering the noise before encoding, file-size is greatly reduced even at very low (i.e., high-quality) x264 crf settings.

Chetwood
20th October 2010, 05:51
Speaking of applying filters in real-time, anybody already seen this (http://www.youtube.com/watch?v=FgTq-AgYlTE)?

jpsdr
20th October 2010, 08:41
What is this Distributor() command ?

CarlEdman
21st October 2010, 15:04
What is this Distributor() command ?
It was a command necessary to enable multi-threading in avisynth inside x264 some time ago. I do not know if it is still necessary (or ever was in avs2yuv which is what I'm using these days with the 64-bit x264), but it does no harm, so I have not bothered removing it from my default scripts.

TheFluff
23rd October 2010, 01:35
Late to the party, but I think it's good you found an alternative solution, because trying to add things to DGIndex is not really a good idea if you want to stay sane. I'm not sure how much of the codebase actually is neuron2's doing and how much comes from its heathen Chinese DVD2AVI origins, but the entire thing is a gigantic mess full of thedailywtf.com-worthy things like

unsigned char stream[2500000];
Declaring a 2.5MB array on the stack surely is a good idea, right?


start = timeGetTime();
for (;;)
{
// ts header detection code...

// Don't loop forever. If we don't get data
// in a reasonable time (5 secs) we exit.
time = timeGetTime();
if (time - start > 5000)
{
MessageBox(hWnd, "Cannot find audio or video data. Ensure that your PIDs\nare set correctly in the Stream menu. Refer to the\nUsers Manual for details.",
NULL, MB_OK | MB_ICONERROR);
ThreadKill(MISC_KILL);
}

// more ts parsing code...
}

Wait, what? What happens if your harddrive was idle and stalls for 5 seconds spinning up when you're trying to open a file? Was it really that hard to count the number of bytes read?

There are also lots of random global variables, common functions implemented as preprocessor macros and Win32 GUI calls scattered at random, even in deep loops. The functions "Next_Transport_Packet()" and "Next_Packet()", which do a big part of the actual parsing work (for MPEG TS and MPEG PS respectively) are almost 1000 lines long each in the original source code; when preprocessed they're a lot longer because of the frequent use of those preprocessor macro "functions". There's also a lot of very similar copypasted code all over the place.

TL;DR: it'd be better to write something new from scratch.

MatLz
23rd October 2010, 02:12
On vob, dgindex is frame accurate when ffmpegsource isn't.
Can we also call ffmpegsource 'a mess' ? :rolleyes:

CarlEdman
23rd October 2010, 14:22
On vob, dgindex is frame accurate when ffmpegsource isn't. Can we also call ffmpegsource 'a mess' ? :rolleyes:

I'm not a big fan of ffmpegsource output as part of a processing chain either (it seems ok for a all-in-one file-to-display solution), while dgindex always has been reliable for me.

But TheFluff's code examples from dgindex are pretty messed up (and funny!).

TheFluff
23rd October 2010, 14:53
On vob, dgindex is frame accurate when ffmpegsource isn't.
Can we also call ffmpegsource 'a mess' ? :rolleyes:

I'm not saying it doesn't work, because it clearly does. I'm just saying that its codebase is an unmaintainable mess, which is probably one of the reasons neuron2 is so hesitant to adding new features to it.

You're also free to call ffmpegsource whatever bad names you want if you are so inclined, I don't really mind; it's far from a perfect codebase either.

MatLz
23rd October 2010, 15:36
Hum...I've no reason to call ffmpegsource with bad names.
Actually I use it more often than dgindex and I'm happy with it.
That was just a question...
I'm just a user who know nothing about source code so I just can point out usage bugs.
If the frame accuracy would be fixed, I would use ffmpegsource for dvd because it's a lot faster.

Groucho2004
25th October 2010, 00:04
but the entire thing is a gigantic mess full of thedailywtf.com-worthy things

Wow, you're right, never really looked at the code closely.

Also, I counted 47 "goto" in the DGIndex code. :scared::scared::scared:

MatLz
25th October 2010, 06:21
Also, I counted 47 "goto" in the DGIndex code. :scared::scared::scared:
If it is so bad, so I'm now scared to use x264...
I found 45 'goto' in the source (well, only in r1376 as I can't find direct downloadable recent sources)

Must I worry for my encodes ? Or it is just a common ugly shortcut with no danger ? :confused:

Chetwood
25th October 2010, 08:14
The work gets done so who cares if the code is messy? If you'd care about that you could never use Windows in the first place.

Groucho2004
25th October 2010, 22:36
If it is so bad, so I'm now scared to use x264...
I found 45 'goto' in the source (well, only in r1376 as I can't find direct downloadable recent sources)

Must I worry for my encodes ? Or it is just a common ugly shortcut with no danger ? :confused:

It's not "bad". For example, sometimes it's a really easy way out of a deeply nested "for"/"if-else" construct.

I personally avoid it because in my opinion it belongs in batch files, not C/C++ code.

It's basically a question of coding style. If you google a bit you'll find countless discussions about this.

As a side note - When you are writing assembly code you have to use direct or conditional jumps.

Nexin
30th October 2010, 04:16
Projectx the newer versions that is, not the older versions that have known problems with the subs. It's cli commandable maybe, since shows the cli when run the program for having the user interface.