Demuxing with MKVMerge then Remuxing with MKVToolnix - Audio is out of sync

[VideoFanatic]

I've downloaded some YouTube videos as MKVs with YouTube-DL. Some are AVC and some are VP9. When I demux a VP9 video with MKVExtract then remux the video and audio files (original untouched AAC or converted to WAV) then the resulting video has VERY out of sync audio. MediaInfo doesn't report an audio delay on the source or the remux.

This seems to only happen on VP9 codec videos, NOT on AVC videos. Is there some way I'm supposed to remux VP9 codec videos so that the audio stays in sync?

I can't even use TSMuxer instead as it doesn't support VP9. The reason I'm demuxing the audio in the first place is so I can normalize the audio in Adobe Auditon as different videos have different volumes and all the videos will be used in a compilation video.

Short clip is attached.

[Ennio]

Hi, I demuxed the streams with gMKVExtract. Remuxed again with mkvtoolnix, and AV are in sync. Both with original and recoded audio.

[VideoFanatic]

How did you remux? I just dragged the h264 file and wav file into the MKVToolnix window and hit the button to do the mux. Is that what you did?

Do you think my issue could be because I don't have a graphics card in my PC at the moment?

[hello_hello]

Fox is certainly the Trump propaganda network.

It's variable frame rate, so if you specify a frame rate when remuxing it'll probably mess with the A/V sync. Without setting one it was fine for me.

By the way, according to an EBU R128 scan the audio in that one has a volume of -22.29dB and a peak level of -1.61dB, so it's pretty much industry standard volume for "soundtrack" audio (-23dB).

By the way, you can adjust the volume of MP3 and AAC audio without re-encoding so there's no quality loss. Mp3Gain can do it for both, but it needs raw MP3 files and AAC in an MP4 obtainer. There's instructions for making it work with AAC about halfway down this page. http://mp3gain.sourceforge.net/news.php

Foobar2000 will adjust MP3/AAC audio in common container types, even when they include video. There's no need to extract first.

Mp3Gain is more informative than foobar2000, unless like me, you spend time configuring it's GUI, but so you know, if you try it, the standard volume for music files is shown as 89dB at the top of the Mp3Gain GUI. It's a sound pressure level and fairly meaningless, but it translates to -18dB in human-speak. The industry standard volume of -23dB for soundtrack audio would therefore be 84dB, in ReplayGain-speak.

[Ennio]

How did you remux? I just dragged the h264 file and wav file into the MKVToolnix window and hit the button to do the mux. Is that what you did?

Do you think my issue could be because I don't have a graphics card in my PC at the moment?

Well, first, it's a *.ivf file, not h264.
Not dragged, but added streams with "Add source files" button. Suppose it wouldn't make a difference. Using latest version 51.0.0.

I can imagine certain things go lost when demuxing streams. What sometimes helps is importing the sourcefile and then add your wanted audiostream. Simply disable the tracks from the sourcefile you don't want and remux.


@ hello_hello: how did you know the video was vfr? MediaInfo doesn't state such?

[hello_hello]

Ennio,
You made me think I'd missed the obvious where VideoFanatic said "I just dragged the h264 file and wav file....", because extracting the video file would lose the VFR information, but when I extracted the video stream, it didn't.
Although normally I'd do it the way you do it. To re-encode the audio I'd only extract the audio, open the original MKV, add the re-encoded audio, de-select the old audio, and remux.

@ hello_hello: how did you know the video was vfr? MediaInfo doesn't state such?

It does for me. I'm using HTML view, but I think any view other than Basic should show it.
The original MKV:


[Attachment 55733 - Click to enlarge]

After remuxing with track statistic tags enabled (I normally disable them, but they're enabled by default). The frame rate shown is the average frame rate, as far as I know.


[Attachment 55734 - Click to enlarge]

I double checked by extracting the video timecodes file. They're usually rounded to the nearest millisecond for frame rates where frames don't display for a multiple of whole milliseconds, so a pattern of 33ms and 34ms wouldn't necessarily indicate a VFR.
I don't know why, but it appears some frames only display for 1ms in the sample MKV.

# timestamp format v2
0
33
34
67
100
133
167
200
234
267
300
334
367
400
434
435
467

It's the only explanation I can think of for the audio going out of sync though. Converting to a constant frame rate, that is....

[Ennio]

@ hello_hello: how did you know the video was vfr? MediaInfo doesn't state such?

It does for me. I'm using HTML view, but I think any view other than Basic should show it.

I stand corrected. MediaInfo does show variable framerate. My bad, sorry