dcoke22 wrote: ↑Mon Jul 19, 2021 3:22 pm
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.
dcoke22 wrote: ↑Mon Jul 19, 2021 3:22 pm
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.
senpai92 wrote: ↑Mon Jul 19, 2021 5:32 pm
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.
senpai92 wrote: ↑Mon Jul 19, 2021 5:32 pm
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.