www.makemkv.com

Hello mike admin,

In the new 1.7.3 version you fixed an annoying bug where audioframes were incorrectly dropped at the beginning of an BD movie. Especially BD movies that were preprocessed with TSMuxeR were affected by that bug. This is fixed now. Thanks alot for that!

But I think the very same bug (if it is a bug!?) is still present when processing DVDs.

I tried serveral DVD movies I once did with DVD Shrink and with lots of them I get the same errors:

MakeMKV v1.7.3 win(x64-release) started
Opening files on harddrive at J:/Some Movie (2005)/VIDEO_TS/
Title #0 was added (37 cell(s), 2:02:06)
Operation successfully completed
Saving 1 titles into directory H:/
AV synchronization issues were found in file 'H:///Some Movie (2005)_t00.mkv' (title #1)
AV sync issue in stream 2 at 0:00:00.002 with duration of 10.666ms : 1 early frame(s) dropped at start
AV sync issue in stream 1,3 at 0:00:00.024 with duration of 32ms : 1 early frame(s) dropped at start
AV sync issue in stream 1,3 at 1:03:13.040 with duration of 24ms : short audio gap was removed, audio skew is -24ms
AV sync issue in stream 2 at 1:03:13.040 with duration of 2.666ms : short audio gap was removed, audio skew is -2.666ms
1 titles saved

MediaInfo shows a big delay for the audiotracks afterwards:

Track 1: Delay relative to video : -56ms
Track 2: Delay relative to video : -77ms

This happens to a lot of movies that have been preprocessed with DVD Shrink. Only the ms values change, sometimes there are up to 8 frames (!) dropped.

Here's another example:

MakeMKV v1.7.3 win(x64-release) started
Opening files on harddrive at J:/Some Other Movie (2003)/VIDEO_TS/
Calculated BUP offset for VTS #0 does not match one in IFO header.
Title #0 was added (40 cell(s), 1:51:23)
Operation successfully completed
Saving 1 titles into directory H:/
AV synchronization issues were found in file 'H://title00.mkv' (title #1)
AV sync issue in stream 1 at 0:00:00.019 with duration of 32ms : 1 early frame(s) dropped at start
AV sync issue in stream 1 at 0:50:55.105 with duration of 14.733ms : short audio gap was removed, audio skew is -14.733ms
1 titles saved

And another example:

Opening files on harddrive at J:/A Third Movie (1971)/VIDEO_TS/
Title #0 was added (21 cell(s), 1:36:41)
Operation successfully completed
Saving 1 titles into directory H:/
AV synchronization issues were found in file 'H://title00.mkv' (title #1)
AV sync issue in stream 1,2 at 0:00:00.025 with duration of 128ms : 4 early frame(s) dropped at start

All examples were done with DVD Shrink straight from the original disk. I think the sync issues after about 1 hour may come from the layer break handling. But the issues at the beginning (X early frame(s) dropped at start) look identical to the just-fixed BD bug, right? So, mike, if you want to investigate this behaviour, please don't hesitate to contact me via PM.

A general question regarding "dropped frames":

If MakeMKV is dropping those frames, does that mean that the initial AV sync problem is completely corrected in the resulting MKV afterwards? Or do I now rely on my hardware- or software-player to obey the set "Audio delay relative to video" value in the MKV file and correct the sync accordingly?

Thanks again, S.

samtoy wrote: If MakeMKV is dropping those frames, does that mean that the initial AV sync problem is completely corrected in the resulting MKV afterwards? Or do I now rely on my hardware- or software-player to obey the set "Audio delay relative to video" value in the MKV file and correct the sync accordingly?

Well, the "standard" behavior is that no audio frame should appear before first video frame. In a lot of cases audio frames are far beyond first video frame (so-called audio delay). Because of that, MakeMKV drops all audio frames that have their timecode earlier than first video frame. However, it turned out that a lot of muxers have bugs and put incorrect timecodes. The change in 1.7.3 added following logic - if audio starts earlier than video (negative audio delay) but the "negative delay" is less than 1 millisecond, then small audio delay is added instead of frame being dropped.

MakeMKV tries to preserve continuous audio, with the only exception when there is a long gap in source - then you'll see a message like "audio gap - x ms". In all your examples you should have continuous audio.

Thanks for explaining the "logic" behind that.

But still: IF an audio delay of -56ms is set by MakeMKV, do I have to rely on my player now to obey the "Audio delay relative to video" value and correct the sync accordingly? Will the movie be out of sync if my hardware MKV player ignores that flag/value?

Example from an just made MKV:

..
Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 2h 3mn
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -56ms <-- !!!
Stream size : 396 MiB (7%)
Title : 3/2+1
Language : English
Default : Yes
Forced : No
..

Thanks again, S.

56 milliseconds = 0.056 seconds

You'll never be able to see it even if your media player doesn't obey the instruction to add the delay.

MakeMKV never puts a "negative" delay. It tries to avoid putting any delay, so audio starts at start, but if it's impossible then it puts a positive audio delay. If your player ignores it, you'll get your audio early.