Audio/Video Out of Sync After Encoding with StaxRip

[Malonn]

I'm having trouble with DVD rips from MakeMKV. After I rip the DVD I encode them with x264 (StaxRip to be precise), but the audio and video are always out of sync. It only happens with DVD's (never Blu-ray) and only when ripped with MakeMKV (I resort to using DVDFab to copy the disc, but I don't want that software installed if I don't have to have it). The MKV from MakeMKV is fine, no syncing issues. But I like reducing file size and resizing the video as well. So I have to re-encode. It has something to do with the process of encoding it from MPEG-2 to MPEG-4. Something happens that throws off it's timing. I could probably step through with a media player and try to determine the exact delay and compensate for that while muxing, but I don't want to do that. I want to know why it's off to begin with. Anyone experienced this problem, or have some suggestions as to a fix?

[foxyshadis]

I'm going to guess that it's because Staxrip assumes mkv tracks are all lined up, whereas I know it'll compensate for delays in raw DVDs. I'll page Stax to the thread.

If you still have the original mkv, you can open it in MediaInfo and check the delay (might need to turn Debug->Advanced Mode on), then remux with the same delay value. It should be the same.

[stax76]

Looks like a bug somewhere, StaxRip should handle delay in any situation, from MediaInfo it reads Video_Delay and if null it also reads Source_Delay. There are different input modes like demuxing or not and there are countless audio processing options that were modified much lately and there are countless audio formats. If you post the log file to pastebin or send it per private message or email maybe I find the problem. In most recent MakeMKV rips I made MakeMKV did either not output a container delay or it was minimal I believe but it could also be my ripping method. I might have used another ripping program to copy the DVD structure to the hard drive and that program might have removed the delay. I tested it lately with some DVD structures that have a huge delay.

[Malonn]

Hey, thanks for the replies guys. I will get the StaxRip log to the author. I will try muxing in any video delay too. Troubleshooting yesterday, I manually stepped through the audio delay (it was actually a reverse delay -- the audio was behind the video, so I muxed with a negative delay) and compensated for it when muxing, but it grows over the length of the movie. So I managed to get it pretty synced for the first 1/2 or so, but then it went out of sync again later on. I don't know if that factors into your determination of what could be wrong or how to troubleshoot? Anyway, let me get to doing some of these things you guys recommend and request.

EDIT:
MediaInfo shows no delay on the MakeMKV rip for audio or video. Just to mention it, I recently copied a raw DVD with DVDFab. It was progressive but I didn't know, so I deinterlaced it (when I was encoding it, obviously). The deinterlacing caused the video and audio to be out of sync. I went back and re-encoded the video but without deinterlacing and the video and audio were fine. Something about that messed it up.

EDIT2:
I did some further troubleshooting and bypassed StaxRip. I just encoded with x264 -- basic settings -- and muxed up the results. The audio and video was still out of sync. I don't know what exactly StaxRip does besides operate x264, but it seems the problem is with x264 encoding and not anything StaxRip does. There may be some setting in x264 to fix this, but I don't know what it is. I can say (keep in mind I'm very much a noob at this stuff) that I demuxed and remuxed just the MakeMKV rip and the audio and video was in sync. I hope some of this helps.

EDIT3:
After doing some Googling, I'm thinking the problem is with the video dropping frames. I don't fully understand I-Frames and B-Frames and all that mess...I just want to fix it. Maybe it's something with MakeMKV and not x264. Maybe MakeMKV does something to MPEG-2 video (because I've never had an issue with MPEG-4) -- I've read about orphaned B-Frames and such -- that is exacerbated by x264. I don't know.

[stax76]

Maybe somebody has a idea if you post the log file to pastebin (http://pastebin.com/).

[hello_hello]

In the meantime, try remuxing an MKV with TSMuxer and re-encoding the TS or M2TS file instead (DGDecode/DGIndex for opening it).

For reasons I don't understand, sometimes after extracting the audio from a TS or M2TS file with DGIndex (created by remuxing an MKV) it writes a ridiculously large delay to the file name that should be ignored.
Something like this: VTS_01_1 PID 1100 3_2ch 448Kbps DELAY -4200000ms.ac3
Although I think if you open an M2TS file with StaxRip it extracts the audio with eac3to and that's not a problem.

[Malonn]

In the meantime, try remuxing an MKV with TSMuxer and re-encoding the TS or M2TS file instead (DGDecode/DGIndex for opening it).

For reasons I don't understand, sometimes after extracting the audio from a TS or M2TS file with DGIndex (created by remuxing an MKV) it writes a ridiculously large delay to the file name that should be ignored.
Something like this: VTS_01_1 PID 1100 3_2ch 448Kbps DELAY -4200000ms.ac3
Although I think if you open an M2TS file with StaxRip it extracts the audio with eac3to and that's not a problem.

I don't think I understand you. The video file from the MKV created by MakeMKV is ".mpg" I mux it with MKVMerge (GUI) When I mux it, it is ".264". I've only dealt with m2ts files when extracting from a raw DVD rip using PGCExtract. I haven't been using DGIndex. I've actually tried to take StaxRip out of the equation as much as possible for troubleshooting purposes. I'm dense though, so maybe I'm misunderstanding you.

But I'll encode with StaxRip and get a log to Pastebin.

[hello_hello]

Yes the MKVs created by MakeMKV contain the original mpeg2 video. If you open one with TSMuxer you can remux it as a TS or M2TS file, still containing the original mpeg2 video. When opening TS or M2TS files containing mpeg2 video, I'm pretty sure StaxRip would use DGIndex to index and decode. If not by default, I'm sure you could tell it to. DGIndex can't open MKVs which is why you need to remux as TS or M2TS first.

If you open an MKV created by MakeMKV with MKVMergeGUI you can mux it as a new MKV but it'll still contain the original mpeg2 video, so I'm not sure what you mean by "when I mux it, it is ".264"". I assume you're referring to the re-encoded version?

Anyway, if the original MKV is okay (the one created by MakeMKV) but after encoding the audio sync is out, and if it's gradually losing sync as described, then it's possible the current decoding method (probably ffms2/FFVideoSource) is getting something wrong. Maybe the frame rate is a little out. I don't know, but my idea is simply to put the mpeg2 into a different container (ts or m2ts) so it can be indexed and decoded etc using a different method to see if the problem goes away.

I don't use StaxRip myself so I'm only vaguely familiar with it, but it probably wouldn't hurt to post the log file here also. Something in it may be obvious to someone.

If you're keeping the original audio you can re-encode the video, open the output file with MKVMergeGUI, add the original MKV created by MakeMKV, deselect the original mpeg2 video stream, and then remux. That'll give you a new MKV containing the encoded video instead of the original but everything else should remain exactly the same, including the audio sync. If the audio's out of sync then the video probably wasn't encoded correctly.
(One exception is if the video stream, rather than the audio stream, has a delay. You'd need to adjust for that manually, but it's not very common)

PS. When you open vob files directly with DGIndex (or a program that uses DGIndex) and extract the audio, it writes any audio delay to the file name.
Something like "video 3_2ch 448Kbps DELAY -24ms.ac3". Most muxing programs will pick up the delay from there and apply it when muxing so the audio sync doesn't change. Sometimes after remuxing a MKV containing mpeg2 video as a TS or M2TS file, DGIndex writes a ridiculous delay value to the file name. I don't know exactly why, but I thought I'd point it out in my previous post so if it does happen, you'll know to ignore it. Other than that, using DGIndex to open TS/M2TS files containing mpeg2 video should work fine.

[Malonn]

Yes the MKVs created by MakeMKV contain the original mpeg2 video. If you open one with TSMuxer you can remux it as a TS or M2TS file, still containing the original mpeg2 video. When opening TS or M2TS files containing mpeg2 video, I'm pretty sure StaxRip would use DGIndex to index and decode. If not by default, I'm sure you could tell it to. DGIndex can't open MKVs which is why you need to remux as TS or M2TS first.

If you open an MKV created by MakeMKV with MKVMergeGUI you can mux it as a new MKV but it'll still contain the original mpeg2 video, so I'm not sure what you mean by "when I mux it, it is ".264"". I assume you're referring to the re-encoded version?

Anyway, if the original MKV is okay (the one created by MakeMKV) but after encoding the audio sync is out, and if it's gradually losing sync as described, then it's possible the current decoding method (probably ffms2/FFVideoSource) is getting something wrong. Maybe the frame rate is a little out. I don't know, but my idea is simply to put the mpeg2 into a different container (ts or m2ts) so it can be indexed and decoded etc using a different method to see if the problem goes away.

I don't use StaxRip myself so I'm only vaguely familiar with it, but it probably wouldn't hurt to post the log file here also. Something in it may be obvious to someone.

If you're keeping the original audio you can re-encode the video, open the output file with MKVMergeGUI, add the original MKV created by MakeMKV, deselect the original mpeg2 video stream, and then remux. That'll give you a new MKV containing the encoded video instead of the original but everything else should remain exactly the same, including the audio sync. If the audio's out of sync then the video probably wasn't encoded correctly.
(One exception is if the video stream, rather than the audio stream, has a delay. You'd need to adjust for that manually, but it's not very common)

PS. When you open vob files directly with DGIndex (or a program that uses DGIndex) and extract the audio, it writes any audio delay to the file name.
Something like "video 3_2ch 448Kbps DELAY -24ms.ac3". Most muxing programs will pick up the delay from there and apply it when muxing so the audio sync doesn't change. Sometimes after remuxing a MKV containing mpeg2 video as a TS or M2TS file, DGIndex writes a ridiculous delay value to the file name. I don't know exactly why, but I thought I'd point it out in my previous post so if it does happen, you'll know to ignore it. Other than that, using DGIndex to open TS/M2TS files containing mpeg2 video should work fine.

Thanks for the clarification, hello_hello. I understand you now. I'll try both of your suggestions. My hunch is that for some reason frames are getting dropped during the encoding process, which is why audio syncing gets worse as the movie goes on. There is roughly a 1.2 second delay right from the get-go, so I don't know why that would be unless frames are missing right off the bat. Or I could be completely wrong. If I'm right, is it MakeMKV? I don't know. But a movie encoded from a raw DVD rip does not have syncing problems. If it's MakeMKV, why isn't it out of sync right from it's rip? Questions questions.

Anywho, thanks for the suggestions and let me get to trying them.

[stax76]

Any chance I can take a look at a log file? If you don't want to post it public you can always mail me or write a private message. Delay is a common cause of problems and I have a special interest to understand and fix delay problems.

[Malonn]

Any chance I can take a look at a log file? If you don't want to post it public you can always mail me or write a private message. Delay is a common cause of problems and I have a special interest to understand and fix delay problems.

Sure StaxRip author. Let me re-encode (I deleted the old log) with StaxRip and get that to Pastebin (I don't care who looks at it. The more the merrier).

I tried all of hello_hello's suggestions, and none fixed the syncing problem. So it MUST be the encode. My question is does the problem start with MakeMKV (If it does I'll post there too) or is it h.264 (I doubt it). No issues with raw DVD rips.

[Malonn]

Here ya go, Stax76:

http://pastebin.com/tTRGEnud

[stax76]

Thanks, I try to find a similar disc in order to reproduce it, mine are all PAL.

[stax76]

What you can try is to double-click on the source filter and remove the AssumeFPS line.

[Malonn]

I didn't have the AssumeFPS filter included in that encode. I have had it, but not that time.

[stax76]

In the main dialog when you right-click the source file and choose Media Info there is a media info GUI, what does it show when you enter Video_Delay in the search field?

[Malonn]

0. There is no delay for video or audio.

[stax76]

I guess the problem is related to ffms2 and NTSC, still you could test a PAL DVD if you have one, I'll ask in the ffms2 thread.

[tebasuna51]

Problems with Delay's can be easy detected => async constant along all the movie.

Problems with fps or drop frames => async change from begin to end of movie.

- Maybe the problem s related to drop video frames because:

...
encoded 170889 frames, 374.07 fps, 1096.84 kb/s
and end with a video duration (correct for 170889 frames at 23.976 fps):
DURATION : 01:58:47.495000000
The audio, without changes, have:
DURATION : 01:58:49.984000000

Do you have an async of 2 seconds (audio after the video) at end of movie?

If so the problem can't be related with fps, because the fps needed to play 170889 frames with a duration 01:58:49.984 is:
fps = frames/duration = 170889 / 7129,984 = 23,9676555

less than the standard 23,976024, and a DVD can't have this fps.
You need 170948 frames to have a duration of 01:58:49.984 at fps 23,976024, and you have 59 frames less.

- If the drop video frames problem was in MakeMKV and "F:\title00.mkv" play fine can be only because audio timestamps correct the problem.
Extract the audio timestamps from "F:\title00.mkv" and apply them to "F:\title00_new.mkv"
If now "F:\title00_new.mkv" plays fine the async problem is solved.

- If the drop video frames was in decoder FFVideoSource("F:\title00.mkv", cachefile="F:\title00 temp files\title00.ffindex") maybe you can try another decoder.

[Malonn]

Okay, tebasuna51. Thanks for the info and suggestions. But please bear in mind that I'm a total noob to this stuff. How do I extract timestamps and apply them to a new encode. I have no idea how to do that.

EDIT:

Nevermind, tebasuna51. I hit up Google and found out how to extract timecodes. I'm going to try both audio and video. Video first. I think that's where the problem is.

[stax76]

@Malonn

I'm sorry that I can't help much atm. but tomorrow I get 2 NTSC DVDs to test, I made a code change passing 6 decimal digits to applications instead of 3 for frame rates and added frame rate, frame count and playtime with milliseconds to the log file.

[tebasuna51]

Please answer my question:
"Do you have an async of 2 seconds (audio after the video) at end of movie?"


1) You can use mkvextract with this syntax (replace the path where you have mkvextract.exe) to obtain the Timecodes:

"D:\Programa\megui\tools\mkvmerge\mkvextract.exe" timecodes_v2 "F:\title00.mkv" 1:"F:\Timecodes.txt"

2) Load "F:\title00_new.mkv" in MKVMergeGUI (mmg.exe), select the audio track, load "F:\Timecodes.txt" in last box of General Options tab. Remux to a new mkv.

Check now if the async is solved.

[Malonn]

tebasuna51, I have this desire to ask you to marry me. The timecodes fixed it. PROBLEM SOLVED! I extracted the timecodes for the video from the MakeMKV rip, and when I went to mux with MKVMerge, I just fed it the codes. BAM! Audio/video in sync all the way through the movie. Somebody buy tebasuna51 a beer.

EDIT:

Damn. My dumb ass didn't see this page. I figured it out with Google. But yeah, that fixed it. All is good now.

[stax76]

Can anybody confirm that MakeMKV creates timestamps only for NTSC files and not for PAL?

[tebasuna51]

I think is not related with NTSC or PAL DVD
All video/audio tracks in mkv have Timecodes.

For instance with this sample:

VOB, 1 video track, 1 audio track, 0:00:29
1: MPEG2, 480x480 60i /1.001 (16:9)
2: AC3, 2.0 channels, 448kbps, 48kHz, 83ms

converted to mkv with MakeMKV, the ac3 track Timecodes extracted from the mkv are:

# timecode format v2
83
115
147
...
29139
29171
The values are in ms, and the first one is the time to play the first AC3 frame: the initial delay.

If all is ok each frame must be played 32 ms (AC3 frame duration) after.

Like the AC3 have 909 frames, the last value must match with:

909 x 32 + 83 = 29171

But when there are problems (drop video frames for problems reading the DVD source like seems hapen here) the Timecodes must correct the audio/video sync.

With the Malonn mkv the problem was in the video Timecodes, in some points the frames must be played more time to compensate the 59 frames less to match the audio duration. If all are together we have a static image with more than 2 seconds.

[stax76]

Thanks for the info, I have to find a way how to handle this mess in StaxRip, for PAL DVDs I've never seen a problem, for NTSC discs if I understand correctly the problems are more likely the video, if mkvextract can output m2v, I'll just extract to m2v and handle it with good old DGMPGDec.