Odd MKV muxer applications compatibility problems

[Inspector.Gadget]

I'm trying to isolate a problem or difference down to one or more factors in making incompatible Matroska filesfrom DVD VOBs. Here's the scenario:

I ripped a 16:9 NTSC DVD of the movie "Hard Candy" to my hard drive as one large VOB 4.19 GB. Two different, odd things happen with muxing to Matroska:

1) If I re-mux the VOB with the latest MKVMerge binary and its GUI, the resulting file plays fine if it is demuxed on playback by Haali's Matroska Splitter but crashes MPC (latest patched build) when I use the internal splitter. The file opens in MediaInfo's GUI and all the information looks accurate.

2) If I re-mux the VOB with Haali's GDSMux, it plays fine in Media Player Classic with both the internal splitter and Haali's splitter but crashes MediaInfo GUI.

The DVD is soft telecined, and Haali's GDSMuxer discards the 3:2 pulldown flag, (oddly) resulting in jerky playback of the re-muxed MKV. MKVMerge does not, and playback is smooth.

I suspect the frame rate to be the issue, but when I go to re-mux the MKVMerge-created MKV with GDSMux (in order to pass GDSMux the framerate value), GDSMux claims that there is only an AC3 stream in the original MKV, regardless of whether I specify a 4CC code in MKVMerge. Essentially, I can't re-mux the original MKV to even get to the framerate issue.

Where do I go from here to figure out where the bug is?

[KoD]

MPC's internal matrsoka splitter is outdated. Simply as that.

[Inspector.Gadget]

Thanks, KoD, but that doesn't explain the problems with (G)DSMux or Mediainfo.

[video_magic]

Only a quick suggestion. In the latest MKVMerge GUI under 'FILE' - 'OPTIONS' there is a 'Use Simple Blocks' which may or may not be ticked.

Hovering the mouse over that option says if it is enabled there won't be backwards compatibility. This might be relevant to your experiences.

[Inspector.Gadget]

Thanks video_magic, I'll play around with that when I get home. That could potentially solve the MediaInfo crash, and hopefully won't screw up MPC's splitter, but doesn't affect MKVMerge compatibility because presumably the options is only used on muxing the new MKV rather than demuxing the original. I'm also curious to see whether that fixes jerky playback by possibly writing information about the video stream differently (as you can see, I'm thinking about this in an abstract way and will need to look at the technical side of things more closely when I get a chance).

[KoD]

You're just avoiding a conclusion you don't like: mkvmerge is the only app that muxes the file properly, and Haali's splitter is the only splitter that demuxes it properly. What exactly makes MediaInfo or Gsdemux the standards by which everything else gets compared to ?

[Inspector.Gadget]

KoD, I think either I wasn't clear or you misread something I said: at the moment, it is unclear to me whether the problem(s) experienced in using the different software were in fact the same problem across them. I'm not interested in summarily concluding that X is broken and Y is fine: I'd much rather find out what the problem is in each case and figure out whether or not a workaround can be implemented at the time of (de)muxing. There's no indication that the problem in MediaInfo is the same as or even related to the problem in GDSMux, for example.