The widely used tools DVD2AVI and MPEG2DEC suffer from a fundamental deficiency: they do not deliver all the coded frames from the input stream. Put simply, they lose frames.

This can cause serious problems with audio sync and authoring with some tools. Not only that, but random frame access is not handled correctly and incorrect frames can be returned when navigating on the timeline via MPEG2DEC (and its clones).

Additionally, the original DVD2AVI project was not updated in some time, and it stood in need of some fixes and upgrades. My version addresses a lot of the irritating features of the original project, as well as adds many new and useful features.

Notable is support for MPEG1, PVA, and transport streams.

There are three causes for the frame loss in the faulty versions.

1. DVD2AVI fails to flush out the final frame's digit to the D2V file before writing the 9 and closing. This causes one frame to to be lost at the end.
2. MPEG2DEC cuts two frames from the frame count as a workaround for 3 below. This is a kludgy hack that should not be necessary. Thus, thanks to this and 1 above, 3 frames will always be lost. They are lost at the end.
3. If the opening GOP has B frames before the first P frame (IBBPBBP...), then DVD2AVI generates an incorrect D2V file, in which the first digits for the orphaned B frames and some remaining digits are written out of place. Also, MPEG2DEC cannot decode the B frames prior to the first P frame, and so discards them. A number of frames will be lost equal to the number of B frames prior to the first P frame. They are lost at the beginning.
So, for example, if you process a VOB that has an IBBPBBP... opening GOP, you will lose a total of 5 frames, with 2 lost at the start and 3 lost at the end.

In addition to the lost frames, MPEG2DEC does not implement random frame access correctly. In fact, it always throws away the first B frames in the GOP prior to the first P frame. If they are (say) frames 12 and 13 (in display order) and you try to seek to 12, MPEG2DEC will toss them and return frame 14 to you, without any warning or indication about it.

Finally, when 3 above applies the TFF/RFF flags in the D2V file are misaligned to the frames.

I have created fixed versions of DVD2AVI and MPEG2DEC3 that solve these problems, as well as provide a lot of very useful new features. To avoid confusion, these are renamed as DGIndex and DGDecode respectively.

I engineered DGIndex to create fully correct D2V files containing all the input frames. I engineered DGDecode to not truncate B frames prior to the first P frame and to not unconditionally reduce the frame count by two. I rewrote the decoding and random access code to work correctly with the D2V files generated by the fixed DGIndex.

For DGIndex, if your input stream starts with an open GOP, a message box will pop up warning you that the first few frames may not be decoded properly, but the frames will be retained (they are output as copies of the first decodable frame so as not to output corrupted frames). To avoid this problem, always cut your VOBs on cell boundaries. Do not make arbitrary VOB cuts with a binary splitter (such as VOBSplit).