www.makemkv.com

I think that your (great) software has a bug when creating MKV from (most) NTSC discs.

The background: I’m converting a lot of DVD’s to x264 using RibBot264; prior to using MakeMKV for ripping, I was using other tools for that, e.g. DVD Shrink, but that was too painful (had to manually extract the subtitles, manually override stream languages, deal with audio sync issues, etc); with MakeMKV it’s a breeze: RipBot264 will correctly import the created MPEG2 MKV with none of the mentioned issues.

That is, until I started converting some NTSC DVD’s. While the MPEG2 mkv files created by MakeMKV seem to play fine, when I import them into RipBot264, the video seems to run faster and audio is out of sync, especially when you seek to random points.

I think that’s due to incorrect frame rate reported across IFO and VOB files: media info reports 30000/1001 fps on IFO/1st VOB file, but reports 24000/1001 fps on next VOB’s! Allmost 50% of my NTSC DVD’s display this issue. I’ve made a sample; please download it from here (http://www.4shared.com/file/RmeNcZUR/ma ... ample.html), password is “makemkv_sample”.

Since I cannot use RipBot264 to directly import the DVD (causes all the mentioned issues), and cannot use MakeMKV, I’m lost on how to convert these NTSC DVD’s…

MakeMKV puts video data from DVD pretty much as is. What you're describing looks like an issue in ripbot. Try to use mediainfo (an excellent freeware tool) on produced MKV file to see the real frame rate and override it in ripbot.

Thanks for replying.

I do use Media Info, that's how I gathered the info I posted.

I've now figured out what's going on: I understand that MakeMKV will copy video as is on source, the problem is that the frame rate reported on MKV header seems to be copied from source's IFO file, which according to Media Info it's 30000/1001, while the actual frame rate of source's VOB file is 24000/1001. The strangest thing is that this MKV plays just fine; not being an expert on MPEG2, I'm guessing that the media player gets the actual frame rate not from the MKV header but from the MPEG2 frames.

When importing this MKV into RipBot, video will decode at 30000/1001 fps (as stated on MKV header), which is wrong. I managed to correct the problem on RipBot by doing this:

1. Set output speed to "Assume 23.976 FPS" [this will make video speed correct, but audio will be out of sync]
2. Manually editing the video script and commenting out the "audio=TimeStretch()" instruction under "#Tempo" section.

With these modifications, I managed to convert the files, but I would much rater prefer that MakeMKV would set correct frame rate when creating the MKV. MakeMKV could detect that inconsistent frame rates are reported on IFO and VOB files and give the user the option to set the frame rate on MKV header as one or the other...

Anyway, do you know of any tool that allows editing the frame rate parameter on a MKV header? MKVmerge GUI has a header editor, but I cannot change frame rate with it...

toullaf wrote:Anyway, do you know of any tool that allows editing the frame rate parameter on a MKV header? MKVmerge GUI has a header editor, but I cannot change frame rate with it...

You can. It's there and called "default duration" under main video track. The value is a time between frames in nanoseconds, you will need to use calculator to convert it to FPS and vise versa

Thanks for the info.

Unfortunately, when I change the value of "default duration" to 41708333 (24000/1001 fps) with the header editor, the MKV header somehow gets corrupted because "Media Info" no longer displays video/audio segments info neither RipBot sees the audio track! Changing back to previous value does nothing. There must be a (serious) bug on that header editor...

PS: I am using mkvmerge GUI v4.2.0, which is the latest at this time...

Using an HEX editor did the trick: I replaced "01 FD 22 8A" with "02 7C 6B 2D" effectively changing the frame rate from 30000/1001 to 24000/1001. The modified MPEG2 MKV plays just fine. After importing it into RipBot264, the video source is 24000/1001 and preview plays fine. After encoding it, I'll post results here...