Audio desync; "Delay relative to video" field wrong?

[Starburst]

I'm trying to backup my entire PAL DVD collection to x264 before I put it all in storage, and I keep running into weirdness with audio sync. Occasionally, it seems like the "Delay relative to video" amount reported on the audio track is not correct, because when I use it and mux things back together, it looks out of sync. The desync is constant, not gradual, so I could fix it by checking everything individually and trying a few different numbers, but I have a LOT of DVDs (many of them TV shows with individual episodes to encode) to rip, and checking each one manually sounds like a nightmare. Not to mention I sometimes can't tell whether it's perfectly in sync or not.

Here's my entire process in case I'm doing something extraordinarily stupid along the way.


1. Rip with MakeMKV, making sure to include any audio commentaries, subtitles, and other special features.
1a. If the DVD contains episodes which were all contained in the same title track, use MKVMerge GUI to split them (this isn't causing my audio problems afaik, some of the videos I'm having trouble with weren't split like this.)

2. Use MKVExtractGUI2 to demux it all (video, audio, subtitles, and chapter info).

3. The resulting video file is .mpg. Use DGIndex to make a .d2v project file while also checking if the footage is interlaced (it usually is).

4, Use AviSynth to load the d2v project file and deinterlace it, crop any black bars, and resize for square pixels.

My usual script:
MPEG2Source("01.d2v")
TDeint(mode=2, type=3)
Crop(8, 8, -4, -4)
LanczosResize(752, 564)

5. Make sure the script output looks okay, then load it directly into MeGUI and encode to x264 with 2-pass encoding.

6. Use MeGUI or MKVMerge GUI to mux the video back together with the audio tracks, subtitles, and chapters (I don't bother reencoding the audio; it saves time and the audio usually isn't too large).

I make sure I've set a delay (in ms) for each audio track, and I get this number by looking at the Mediainfo for the original MKV rip created by MakeMKV.

Sometimes this ends up looking right, but sometimes it looks a little off. There's one interview special feature in particular that definitely looks wrong with the audio delay included, but if I leave it out completely it looks right. Yet when I look at the original MKV, it looks right even with the audio delay. Is the audio delay perhaps being misreported by Mediainfo? Or is something in the video encoding process chopping out a few frames, thus causing the constant desync?

I've checked the original DVD multiple times to compare with the MKV rip, and they always seem to match up, so I'm a bit lost. It's always a very minor desync (a fraction of a second), but it's enough to distract.

Is there any surefire way to get the audio desync right? Or am I going to need to double-check and experiment with everything, episode by episode? I feel like I'm missing something really obvious.

[fvisagie]

I make sure I've set a delay (in ms) for each audio track, and I get this number by looking at the Mediainfo for the original MKV rip created by MakeMKV.

What results do you get without adding this delay? To some extent depending on how you demux in step 2, there is the possibility that the timestamps needed to maintain sync are retained in the video and audio streams created, and that explicitly adding this (additional) delay is actually creating the problem.

[Starburst]

What results do you get without adding this delay? To some extent depending on how you demux in step 2, there is the possibility that the timestamps needed to maintain sync are retained in the video and audio streams created, and that explicitly adding this (additional) delay is actually creating the problem.

This... makes sense actually. I was originally using MeGUI to extract the streams before switching to MKVExtractGUI2. I tried muxing without the delay but it's very difficult to tell whether it's correct or not as most of my rips are animation so far.

I've been trying to Google MKVExtractGUI2 and I can't find information on how it handles audio delay. There's no settings in the program either. Does anyone have experience with it and can they confirm if it adds the delay to the files themselves?

[hello_hello]

I'd try not ripping with MakeMKV. Unless the DVDs have a copy protection DVDShrink can't handle, use it instead. Just set it's default output size to DVD9 or something larger so it won't try to "shrink" anything. You can use DVDShrink's re-author mode to rip just the movie, or as individual episodes etc (a set of vob files per episode). Open the vob files with MeGUI/DGIndex and index/extract. Any delay will be written to the extracted audio's file name.
MeGUI has utilities under the Tools menu for extracting chapters and subtitles.

Or.... extract with gMKVExtractGUI (http://forum.doom9.org/showthread.php?t=170249) instead. It'll show any delays and write the delay values to the extracted streams. The same way DGIndex does it. I didn't create the program, but I'll take credit for suggesting (http://forum.doom9.org/showthread.php?p=1672874#post1672874) the feature. ;) No need to check with MediaInfo. If there's a video delay, it should take it into account when writing the delay to the extracted audio.

Or.... don't extract the video/audio from the MKV after ripping. Open the MKV with TSMuxer, remux it as a ts file, then index the ts file with DGIndex and let it extract the audio. Any audio delay should be written to the file name.

Or.... don't set a delay. Don't extract anything if you don't need to. After you've re-encoded the video, open the encoded version with MKVMergeGUI. "Add" the original MKV (or TS file). De-select the original mpeg2 video, leave the required streams selected. Remux. Any audio/subtitle delays should remain the same and the chapters will be retained.

I've been trying to Google MKVExtractGUI2 and I can't find information on how it handles audio delay. There's no settings in the program either. Does anyone have experience with it and can they confirm if it adds the delay to the files themselves?

As far as I know it simply extracts. Delays are ignored. The only program I'm aware of which tries to "fix" delays is eac3to. By "fix", I mean it removes or adds audio at the beginning if necessary so there is no delay. You can extract the audio from the MKVs with the HD Streams Extractor (under MeGUI's Tools menu). It uses eac3to to do the work. It saves a log file which will mention any audio delay and/or attempt to fix it.

There's no negative delays for MKV. If MediaInfo shows a negative audio delay it's really a positive video delay. The end result should be the same, I think, but I thought I'd mention it.
If MeGUI extracts the audio from an MKV it'll write the appropriate audio delay to the file name and it should be correct, unless the video has a delay also. MeGUI doesn't take that into account. It's not very common for the video to have a delay in an MKV, but ideally MeGUI should apply it to the audio when it's extracted..... I've mentioned it before (http://forum.doom9.org/showthread.php?p=1688865) but it seems nobody cares :(

If still in doubt.....
Open the original video with MPC-HC (in MPC-HC's options, you might need to set it to "open a new player for each media file"). Run MPC-HC a second time, opening the encoded version. Play them together. Stop and start each as required until the audio is in sync. When it is, you'll no longer hear an "echo", you'll hear a "phasing" effect. Now watch the video for scene changes. If they happen at the same time the audio/video sync is the same for each file. If they don't, it's not. Visually, that way, you can get the audio/video sync to match within around 10ms. The plus and minus keys on the numeric keypad change the audio delay while MPC-HC is playing video.
By default, MPC-HC is set to go in and out of full screen mode by double clicking on the video. A single click stops and starts playback. I change the fullscreen option to middle click. That way, you can stop and start the video quickly by clicking on it (to match the audio sync between players) without the player jumping in and out of fullscreen mode.

Sometimes the audio sync ends up different after re-encoding the video for no apparent reason. At least not one apparent to me. I've given up banging my head on the desk trying to work out why. It only happens very occasionally, so I use the above method to work out the correct delay and manually fix it.

[fvisagie]

it's very difficult to tell whether it's correct or not as most of my rips are animation so far.

In addition to the suggestion from hello_hello, you can also look for any sudden event like a hand-clap to visualise and compare video/audio offsets before and after encoding. Use something like VirtualDub's Audio display, Avisynth's Waveform() or ViewAudio(), or even Aegisub can help visualise video/audio offsets. Unfortunately I don't know of a quick way to do this in MPC-HC. Given the extent to which it supports audio resyncing, it's somewhat surprising that it does not seem to provide a waveform display.