Are AV synchronization issues a problem?

[dcoke22]

No, if the AV sync message appears at the beginning, it is not because of seamless branching, it is because the audio track and video track do not start "at the same time". I.e., the audio track starts a few ms before or after the video track.

To my understanding, MakeMKV does not always compensate for this in the resulting MKV (at least if these delays are below a specific threshold which I think is around 20ms) and thus the generated MKV has an AV delay as indicated in the message. If someone does not want this, he has to use another demuxer for such discs.

Interesting. I guess I haven't noticed a AV sync message at timestamp 00:00:00 before. Do you have an example where MakeMKV does not correctly account for this?

[karbre]

And does the fact that this only happens when the Atmos track is selected have anything to do with it?

It can happen with some tracks and not with others. I experienced it with both DTS and Dolby tracks.

When looking at the final mkv, with nvidia shield or zidoo z9x I don't notice anything but maybe with a more muscular installation (home cinema amplifier, atmos speaker etc ...) it gets along right?

Whether you notice existing delays or not does not really have anything to do with the quality of your equipment. It has to do with how much the audio is out-of-sync and your perception of the issue. Specific combinations of AVR and TV/projector can also introduce delays because the video processing can take "too long" and the video thus can be delayed, but that is a general setup issue (independent of individual movies) and can be corrected via an audio delay setting on the AVR.

What other demultiplexer do you recommend?

I generally do recommend MakeMKV, but other available tools are eac3to, DGDemux and domyd's mlp (for Dolby TrueHD / Atmos only and experimental). Note that for all those tools you still need MakeMKV for ripping and decrypting the disc. I tend to use one of them when the delay values logged by MakeMKV are too high for my taste.

eac3to is not actively developed anymore and should not be used with newer discs that combine Dolby Atmos and seamless branching, but it works well with all other discs. DGDemux is in active development and generally produces good results. mlp uses a special heuristic for Dolby TrueHD tracks with heavy seamless branching that aims to produce a "perfect" result. MakeMKV uses a similar heuristic since v1.15.4, although I do not know how similar it is since unfortunately MakeMKV is not open-source.

And how can you be sure that everything is in sync?

Generally if MakeMKV produces no AV sync messages, then everything is in-sync. Otherwise it tells you how much de-sync there is

[karbre]

Interesting. I guess I haven't noticed a AV sync message at timestamp 00:00:00 before. Do you have an example where MakeMKV does not correctly account for this?

Two examples I recently ripped were the US release of "From Hell" (2001) and the 2012 Remaster ("Filmmakers Signature Series") of "Wall Street" (1987), here especially the DD4.0 track.

For "From Hell", MakeMKV outputs:

Code: Select all

AV sync issue in stream 1 at 0:00:00 : 0 frame(s) dropped to reduce audio skew to +7.333ms
AV sync issue in stream 1 at 0:00:00 with duration of 7.333ms : encountered overlapping frame, audio skew is +7.333ms

eac3to outputs:

Code: Select all

A remaining delay of +2ms could not be fixed.

That means that the audio track produced by eac3to (eac3to is not a remuxer and thus produces individual track files and not a finished MKV) actually starts 2ms after the video. Thus, when you remux the eac3to output with mkvmerge and apply +2ms delay to the audio track in mkvmerge's options, you get a perfectly in-sync track (down to the millisecond).
When I think about it, it should also be possible to take the MKV generated by MakeMKV and remux it with mkvmerge and apply "-7.333ms" of delay to its audio track, that should produce the same result (although I have not tested that).

Now you may say that these delay values are so small and thus imperceptible, but why not correct it when it can be easily done. Also, for the other disc mentioned above ("Wall Street") MakeMKV outputs the exact same message but with 18ms instead of 7.333ms, which is too much for my liking.

[dcoke22]

A user posted a MakeMKV log in a different thread for a different problem… but in looking through it, I saw this:

Code: Select all

AV sync issues in //…/Back to the Future Part III-SEG_MainFeature_t00.mkv
AV sync in 3 at 0:00:00 (0ms) : 0 frame(s) dropped to reduce audio skew to +26ms
AV sync in 4 at 0:00:00 (0ms) : 0 frame(s) dropped to reduce audio skew to +26ms
AV sync in 3,4 at 0:00:00 (26ms) : encountered overlapping frame, audio skew is +26ms

The implication here is the audio starts 26ms later than the video? Assuming that's the case (hopefully Mike will chime in to confirm), it would be fair to assume the disk was authored that way and the delay isn't a bug in MakeMKV. The delayed audio could be intentional or it could be an error, right? What matters is that the audio is in sync with the video. It would not have to be the case that for the audio and the video to be in sync, they have to start at the same time. The audio & video starting at the same time is perhaps the most logical and it certainly makes things easiest, but is there any requirement that it is the case?

Asked a different way, in this example, how would one know that for perfect audio/video synchronization, the audio should be remuxed without the 26ms delay?


Also, in 24 frames per second video… a single frame lasts about 41ms. So a 26ms audio delay is still less than a single frame of film. I'm pretty sure I'm not sensitive enough to notice that.

[senpai92]

DGDemux is in active development and generally produces good results. mlp uses a special heuristic for Dolby TrueHD tracks with heavy seamless branching that aims to produce a "perfect" result

Domyd's mlp looks complicated to learn, I don't know what to install or not. I tested DGDemux, simpler, in my opinion, and I noticed at the end of the demux that the audio files were all written with the term delay 0ms. Can we deduce that the audio tracks are correct including Dolby TrueHD and that it is a makemkv bug in the end?
And why not use mkvmerge directly to create the mkv in this case? It doesn't change anything if I'm not mistaken?

it would be fair to assume the disk was authored that way and the delay isn't a bug in MakeMKV. The delayed audio could be intentional

Very good remark but if this was intentional, why the audio of any track (for example French in my case) would be "shifted" at the beginning of the synchronization with the video only when the Atmos track is selected and on the contrary everything is fine well when it is no longer?

[karbre]

A user posted a MakeMKV log in a different thread for a different problem… but in looking through it, I saw this:

Code: Select all

AV sync issues in //…/Back to the Future Part III-SEG_MainFeature_t00.mkv
AV sync in 3 at 0:00:00 (0ms) : 0 frame(s) dropped to reduce audio skew to +26ms
AV sync in 4 at 0:00:00 (0ms) : 0 frame(s) dropped to reduce audio skew to +26ms
AV sync in 3,4 at 0:00:00 (26ms) : encountered overlapping frame, audio skew is +26ms

The implication here is the audio starts 26ms later than the video?

To my understanding - I am more than happy if somebody with superior knowledge corrects me - the implication of the above log is the following: The Blu-ray is authored in a way that the audio track(s) contain 26ms of audio information BEFORE the video track starts. MakeMKV however does not alter the audio stream and aligns it with the video stream so that they start at the same time. Thus, when playing the resulting MKV file, the audio is 26ms "too late" (positive delay) compared to how it is intended by the Blu-ray authoring.

This knowledge is the result of me reading different forum threads, trying out different demuxing tools and comparing the result audio tracks with Audacity. Unfortunately there is no detailed documentation for the MakeMKV AV sync messages. I would be more than glad if Mike could say something about that.

Also, in 24 frames per second video… a single frame lasts about 41ms. So a 26ms audio delay is still less than a single frame of film. I'm pretty sure I'm not sensitive enough to notice that.

Yes I said before that some people say everything under 40ms is not noticeable. Your mileage may vary. You can take an AV sync test clip (e.g. https://www.youtube.com/watch?v=ucZl6vQ_8Uo) and alter the audio delay via your playback device to get a feel for how much delay you can notice.
However let me say that while video may usually be 24fps, your brain still recreates an "unlimited fps" video. If one frame is a ball rolling to a wall and the next frame comes after it has bounced off from the wall, your brain still has a feel for when exactly it touched the wall between the frames.
Also, as I said before: It may be noticeable or not. But if it can be fixed so cheaply (it doesn't cost storage nor noteworthy processing power if it's done right with the first mux operation), why not do it.

Domyd's mlp looks complicated to learn, I don't know what to install or not. I tested DGDemux, simpler, in my opinion, and I noticed at the end of the demux that the audio files were all written with the term delay 0ms. Can we deduce that the audio tracks are correct including Dolby TrueHD and that it is a makemkv bug in the end?

As I said, mlp is experimental and it is not being worked on. It is more a proof-of-concept. There are lengthy threads on both the MakeMKV and DGDemux forums where domy, the author, discusses what his tool does. Note btw that this tool is purely about seamless branching, I don't know how it handles cases like those we talk about where there are sync issues at file start.
DGDemux writes the filename with the delay value that the track is intended to be delayed in comparison to the video track (mkvmerge/MKVToolNix automatically parses this value and puts it as delay parameter for the specific track).
You can compare the audio tracks yourself with Audacity. You can use mkvextract to extract the audio track from the MakeMKV file, and load both audio tracks into one Audacity project (unfortunately Audacity does not import Dolby TrueHD tracks, you need to convert those to FLAC or another format before that. DTS-HD instead works out of the box). Then you can zoom in and measure yourself how many ms the tracks are apart.

And why not use mkvmerge directly to create the mkv in this case? It doesn't change anything if I'm not mistaken?

I have never used mkvmerge on M2TS files, I don't know how well it handles them.