audio delay after encoding, but not after ripping the DVD

[codemaster]

I used StaxRip to encode two episodes from DVD9, and it encoded both episodes into one mkv file, but the second episode had ~200ms audio delay.

Then I ripped the two episodes into two mkv files, with MakeMKV, and they both have 0 ms audio delay.

The problem is, after I encoded the second mkv (second episode ripped from dvd9 with makemkv), the resulted mkv (the one encoded in x264 and aac by StaxRip), has a huge audio delay. I don't understand why, since the source audio is perfectly in sync with the source video.

This DVD9 structure is weird, both episodes are located in the same VTS. I think MakeMKV has to split ac3 and mpeg2 streams, but it seems that it splits them correctly, because the two mkv's do not have audio delay.

[hech54]

The just use a DVD ripper like DVDFabDecrypter to rip the disc.

[codemaster]

I tried ripping with DVDFab HD Decrypter, it made a perfect rip (no audio delay, exact same duration, etc), but after encoding that rip with StaxRip, the audio+video duration somehow magically increased by 3 seconds, but the worst part is that after 60-70% of the episode, there is audio delay of 500-1000 ms (far smaller than previously encoded rip made by MakeMKV).

How can I fix this ?

And even ChapterGrabber reads the episode duration with great precision, it's only after encoding with StaxRip that sync problems and added seconds from nothing occur.

[hech54]

I have NO idea why you keep talking about MakeMKV making "rips"......do you?

[codemaster]

because I saw on StaxRip manual that MakeMKV is a DVD ripping tool:

Recommended rippers

In order to copy DVDs and Blu-rays to the hard drive the following rippers are recommended:

• MakeMKV: DVD free, Blu-ray shareware
• DVDFab HD Decrypter: DVD only free

----------------------------------------------------------------------
Ripping means copying the DVD or Blu-ray content to the hard drive and decrypting everything.
Ripping using MakeMKV

MakeMKV is a newer application able to rip DVD and Blu-ray discs to MKV...

But I'm saying that the dvd rips I made with MakeMKV and DVDFab HD Decrypter are ok, but not after encoding. If I encode the rip outputed by MakeMKV, I get an audio delay of over 10 seconds. if I encode the rip outputed by DVDFab HD Decrypter, I get an audio delay of 500-1000 miliseconds after 60% of the duration (0ms at the beginning), and an increase in audio+video duration by 3 seconds. And those 3 seconds doesn't exist in the rip. Somehow StaxRip created 3 second out of nothing...

[codemaster]

this is so weird; I'm gonna try to explain the problem in more detail:

below is the source dvd9. It contains two episodes, and as you can observe, they are both included in the same VTS:



and this is the episode that I ripped. It has a duration of 01:01:11



this is the ripped episode outputted by DVDfab...



... and this is it's duration:



and it's audio is perfectly synchronized

but after encoding this rip with StaxRip, the resulted mkv file has a different duration than that of the rip:



not only that the encoded mkv has 3 seconds more that the source, but look at how messed up the audio becomes:
- at 00:14:34 audio delay is 0ms
- at 00:37:31 audio delay is 0ms
- at 00:40:23 audio delay is -300ms
- at 00:41:36 audio delay is -600ms
- at 00:52:29 audio delay is -1000ms (btw, this values are not exact, just guesses when I checked the mkv to see where the audio is delayed)


Is there any method to fix this? I can't understand how it is possible to have such differences between a rip and an encode... Why can't the encode have the same duration and sync as it's source?

[codemaster]

I've encoded with AutoGK instead of StaxRip, and it has the same audio delay

[Baldrick]

Try handbrake and xvid4psp. Be sure to open dvd and not the vob.

But I guess you will get same problem.

[codemaster]

I did that with AutoGK already, I opened the IFO file instead of the first VOB

but even if I open the vobs in staxrip, the dvd structure is so weird that, not only both episodes wil be encoded as one file, one a/v stream, but the audio will be delayed in the second episode. Not the first episode, that one is fine. Always the second episode from the same VTS, will have audio delay, only after encoding, but not after ripping with dvdfab. The encode is always different than the source. I've never encountered such weirdness, as I've never encountered dvd's with two episodes in the same VTS.

if the source dvd has no delay, nor the ripped episode, how can it be that the encode of that rip does not have the same sync, duration, frames, etc...

[manono]

There's nothing strange about the structure. It's not uncommon to have 2 episodes as part of the same title (if that's what you have). Nor is it uncommon to have the second episode show up with a delay. There are a bunch of ways to deal with this but, not having the DVD myself, I can't tell for sure what will work and what won't.

My first suggestion is to run the complete VOBs as decrypted to the hard drive through FixVTS. It will remove any unreferenced cells which, I would guess, are responsible for the out-of-synch audio in the middle of the second episode. Next, I would open the IFO in PGCDemux and tick 'By VOB ID'. Then check if there are two VOB IDs, one for each episode. If so 'Create a PGC VOB' for each episode (it's under 'Options'), and then run the Vobs for each episode through AutoGK or whatever other program you want to use.

Another way is to decrypt the 2 episodes separately using DVD Decrypter set up in IFO Mode (selecting the correct number of chapters for each, if necessary). Run the results through FixVTS and then send either the IFOs or VOBs to your conversion program.

The fact that the source DVD plays in synch means nothing and tells you nothing about whether or not the converted episodes will also be in synch.

[codemaster]

how is this possible ?

[manono]

Did you already run the DVD through FixVTS? That's a problem, alright, but not one caused by 'strange DVD structure', and not something you mentioned earlier as what was strange about it.

You were saying what was strange about it that it had 2 episodes in the same VTS, which isn't strange at all. You didn't even tell us if there were 2 titles in that VTS, each corresponding to an episode, or if both episodes were part of the same title.

Episodic DVDs don't generally have advanced copy protection. Did you try DVD Decrypter already to decrypt it, perhaps followed by running the VOBs through FixVTS. Even better is to use RipIt4Me which uses both DVD Decrypter and FixVTS.

[codemaster]

FixVTS will get rid of that PgcDemux "unsinchronized" error, but after encoding, there's still audio delay after 40 mins.

So far, I found only one way of fixing this delay issue. I asked someone who encoded the same episode form the same source, without getting a mkv with delayed audio, and he said that the tool he used is DivX Plus Converter, and he encoded directly from dvd9 to mkv. That is the only tool I know that recognizes the correct audio synchronization of the source dvd. I can't explain why, of all the other tools I've tried, not one of them is able to "maintain" proper audio sync

[codemaster]

I give up, it took me several days trying to fix this. I'm going to decode the ac3 to wav and manually sync it in Premiere

[manono]

Actually, since we last spoke I ran into the same problem myself. I've probably seen this problem about half a dozen times in my encoding career. I make DVDs so it's easier to fix. I got the unsynchronized error using PGCDemux so I demuxed the audio using DGIndex. After reencoding and reauthoring, there came this one spot where all of a sudden the audio went out of synch by 300 ms. I split the AC3 audio at that spot (I use HeadAC3he for such things), fixed the delay in the second part (using DelayCut), and rejoined the 2 AC3 files when authoring for DVD (Muxman). I also had to adjust the subs at that same point but that was even easier.

You could do the same, I suppose, when starting out since you know where and how much it goes out of synch when you're all done. You would also have to remux the 2 pieces of AC3 audio with the M2V using Muxman before then feeding the VOBs into whatever program you're using..

[codemaster]

I'm trying to avoid demuxing of .m2v streams (for delay issue reasons), so I fixed it in a different way (since I want to encode the audio to aac anyway):

1. opened the vobs in StaxRip to automatically demux the ac3 stream and to encode only the video to 320x240/x264 with "superfast" preset/mp4 container, an it took only 17mins, but I've encoded it in such low quality just to have something on wich to sync the audio, in Premiere

2. using HeadAC3he I've decoded the ac3 stream to lossless wav

3. in Premiere's timeline, I noticed that the mp4 (video only) is 15 frames longer than the wav. I've identified that after 00:40:20, audio is out of sync by about 500ms, where I made a "non-destructive" cut to split the wav audio clip into two parts. I moved the second part, forward by 15 frames, until it's end got aligned with the end of the video clip. Then, after the cut and till the end of the episode, the audio was in perfect sync

4. at the small audio gap that resulted from cutting and moving the second part by 15 frames, I've added 4 keyframes, two at the end of first part, and two at the beginning of second part, to fade the volume to silence, eliminating abrupt changes during the gap

5. exported the edited (synchronized) audio from Premiere, as AAC, and mux it to mkv with that "video only mp4 fast encoded" file, just to test if they are in sync, and they are.

6. now I just have to export the edited audio from Premiere, as Uncompressed WAV, and use it in StaxRip when I'll encode the video to high quality/resolution in x264/mkv, wich will take 5 or 6 hours. From now on, I'll make fast encodes first, to test if audio is synchronized, rather than directly encode in high quality for hours

I guess, this is what we get for encoding something that wasn't "designed" for this purpose in the first place.

But after this, I made an observation. Just before that audio delay at 00:40:20, in this encoded mp4, there is a clip in this documentary, that lasts longer than it does in the original dvd. About 500ms longer. Now I'm trying something better, I'm doing a test, I added "Trim(0,72540) + Trim(72555,110135)" in avisynth to skip those last 15 frames of that particular clip, this should eliminate all the intermediary steps for fixing the audio (and the resulted gap). This can be easily done in StaxRip, it has a built-in linear editor.

I also noticed that, PGCDemux with "by VOB id" checked, will not be a good way to extract episodes from certain episodic dvd's, because some of them contain a second part of the credits at the end (about the studio that did the remastering, for example), wich have it's own VOB id, and plays in both episodes.

[codemaster]

test results positive. Trimming the last 15 frames of that clip in avisynth worked. Audio no longer needs interventions.

problem solved !

[manono]

I also noticed that, PGCDemux with "by VOB id" checked, will not be a good way to extract episodes from certain episodic dvd's, because some of them contain a second part of the credits at the end (about the studio that did the remastering, for example), wich have it's own VOB id, and plays in both episodes.

Yes, but it's not uncommon for audio to go out of synch when there are multiple VOB IDs. Rather than the second one having a delay of it's own, which is perhaps more common, in your case the video for one was longer by 15 frames (half a second?) than was the audio. The DVD will play just fine with everything in synch, but when you demux the entire PGC, or just load the VOBs into a program, the audio for that second VOB ID 'slides up' against the audio at the end of the first VOB ID, not taking into account that short period of no audio, and it throws off the audio synch for everything after. Your solution of removing those 15 frames with no audio was a good one.

If there's any crap at the end you don't want (the logo you mentioned), it's easy enough to just cut it out. And if it has its own VOB ID, and you're demuxing by VOB ID, just don't get it.

[codemaster]

on another episode I had to use PGCDemux (by VOB id), because DVDfab placed the end vob id at the beginning of the episode id, thus delaying the sound of the whole episode by 200ms. After I extracted the episode id, the sound was perfectly synchronized. DGIndex named the ac3 with 0ms delay. I'll use Subtitle Workshop to convert frames from "Celltimes.txt" to a format like this: "00:14:01.6680000", for mkv xml chapters.