Possible to use DGIndex on MKV files from MakeMKV?

[SaurusX]

One thing that's been lacking with DGIndex is the ability to pull separate titles and the chapters and subtitles with it. My workaround had been to use DGIndex to index VOB files and then mux the final encoded x264 video with the mkv files created by MakeMKV. It's almost perfect except that anything not title00 (the very first episode on a disc) is going to have the subtitles and chapters off by a fraction of a second. Yes, I know this is usually not even noticeable. Is it possible, though, to use DGIndex on the remuxed mkv's created by MakeMKV and have perfectly timed chapters and subs?

[manono]

You shouldn't use DGIndex at all on MKVs with MPEG2 video. It screws up. Keep doing it the way you are now.

[hello_hello]

I don't use MakeMKV so I'm curious... why are the subtitles and chapters off by a fraction of a second?

One option might be to remux the video from MKVs created by MakeMKV as TS files with TS Muxer. DGIndex can open and index TS files so as long as there's no video delay to account for, you should be able to replace the mpeg2 video in the MKVs with the encoded video without effecting the sync of the other streams.

Although if you're indexing the vob files you must also be ripping them. You can rip DVDs as individual titles with programs such as DVD Decryptor or DVD Shrink (for the latter make sure you disable it's compression so it only rips) so you can extract the subtitles and chapters with something else and bypass MakeMKV completely. MeGUI includes Vobsubber as one of the utilities under it's Tools Menu. There' also a Chapters Creator that'll extract DVD chapters (you need the IFO files as well as the VOB files for both). If you don't use MeGUI there's stand-alone versions.

I haven't used them much for mpeg2 video and would tend to trust DGIndex more.... but you can index the MKVs containing mpeg2 video with ffms2 or LSmash. By default they both ignore pulldown flags which can result in all sorts of unpleasantness (if an NTSC source contains combinations of "film" and "video" they'd output the average frame rate). They both have options similar to "field operation" for DGIndex, but disabled by default. For LSmash you need to use repeat=true and for ffms2 it's rffmode=0, and then they should behave like DGIndex (without Force Film enabled).

[SaurusX]

I don't use MakeMKV so I'm curious... why are the subtitles and chapters off by a fraction of a second?

The way DGIndex operates is that it can only cut on I frames. My assumption is that these do not always occur at the very beginning of every title track on a DVD. I'm very careful to snip the VOB segments at cell changes, which seem to be close indicators of title starts/ends. Hence you're left with the video being milliseconds off of the tracks being ripped by MakeMKV as MakeMKV doesn't seem to care what type of frame it starts on.

One option might be to remux the video from MKVs created by MakeMKV as TS files with TS Muxer. DGIndex can open and index TS files so as long as there's no video delay to account for, you should be able to replace the mpeg2 video in the MKVs with the encoded video without effecting the sync of the other streams.

This is something I'll definitely try in the future.

Although if you're indexing the vob files you must also be ripping them. You can rip DVDs as individual titles with programs such as DVD Decryptor or DVD Shrink (for the latter make sure you disable it's compression so it only rips) so you can extract the subtitles and chapters with something else and bypass MakeMKV completely. MeGUI includes Vobsubber as one of the utilities under it's Tools Menu. There' also a Chapters Creator that'll extract DVD chapters (you need the IFO files as well as the VOB files for both). If you don't use MeGUI there's stand-alone versions.

You're describing almost the exact process that I'm currently doing only using different programs. I DO use MeGUI for encoding the video, but the problem would still remain of the subtitles and chapters being off just a tiny bit as the directly ripped titles wouldn't identically match the indexed d2v files from DGIndex.

I haven't used them much for mpeg2 video and would tend to trust DGIndex more.... but you can index the MKVs containing mpeg2 video with ffms2 or LSmash. By default they both ignore pulldown flags which can result in all sorts of unpleasantness (if an NTSC source contains combinations of "film" and "video" they'd output the average frame rate). They both have options similar to "field operation" for DGIndex, but disabled by default. For LSmash you need to use repeat=true and for ffms2 it's rffmode=0, and then they should behave like DGIndex (without Force Film enabled).

With FFMS2 I've discovered the issues about the frame rate getting confused due to 3:2 pulldown not always being applied to all of the video (i.e. a mix of progressive and telecined material). However, I did not know about the rffmode flag with FFMS2. Using that so pulldown is always applied should alleviate the frame rate issues in theory. Though I do know that DGIndex is considered to be the gold standard of frame serving.

[hello_hello]

Doesn't DGIndex provide information regarding the status of the first gop? It's not really something I've had to think about before but accordingly the changelog for version 1.5.0:

15. The infamous GOP warning popup has been removed. The D2V Parse log now shows the open/closed status of the GOPs, so if you need to know if your opening GOP is open, look there.

I couldn't seen any mention of gops in the parse log. Maybe they're only included in the log when there's open gops. Someone else may know.

Would the "log timestamps" option help?. It appears as though it might give you information you need to set a video delay when muxing if need be, but I don't understand much of what it contains. The very beginning of the timestamps file I created as a test when indexing looks like this. Maybe someone who understands it can explain it to me.

DGIndex Timestamps Dump

frame rate = 29.970030
leading B frames = 0
SCR 0, [0ms]
SCR 43886, [1ms]
V PTS 25257 [280ms]
V DTS 22254 [247ms]
GOP start
Decode picture: temporal reference 0[I]
SCR 87772, [3ms]
SCR 131658, [4ms]
SCR 175544, [6ms]
Decode picture: temporal reference 2[P]
SCR 219430, [8ms]
Decode picture: temporal reference 1[B]
Decode picture: temporal reference 5[P]
Decode picture: temporal reference 3[B]
Decode picture: temporal reference 4[B]
Decode picture: temporal reference 8[P]
Decode picture: temporal reference 6[B]
SCR 263316, [9ms]
Decode picture: temporal reference 7[B]