DVD's audio delay problem in demux & remux

[dashali]

In a DVD I demux dvd with
PgcDemux and it show DVD's audio has
467 delay.
Then I remux it with ifoedit and enter
delay=467 after it, remuxed dvd's audio still has delay but original dvd's audio is ok. I try it with DVD-Lab Pro and it was same.
Why? and what solution?

[yetanotherid]

Are you entering the correct value? It can be negative as well as positive.

[r0lZ]

Try DelayCut (http://jsoto.posunplugged.com/audiotools.htm) and remux with Muxman (http://www.mpucoder.com/Muxman/versions.shtml) instead of IfoEdit.

[dashali]

I perfom it with delaycut delay=467 & muxman but still there is delay in comparision of original dvd.It is very strange!

[Ghitulescu]

If you performed search on muxman you'd noticed that muxman has a limit of imposing delay, so use r0IZ's advice.

[dashali]

i know that and i told i used dalaycut, then muxman

[manono]

Then find out the real delay and fix it in DelayCut before using Muxman.

[Ghitulescu]

To my knowledge, most DVDs have 0ms delay, some come with up to 0.1s. 400-500ms are more usual to DVB transmissions.

[yetanotherid]

To my knowledge, most DVDs have 0ms delay, some come with up to 0.1s. 400-500ms are more usual to DVB transmissions.

The amount of DVD audio delay varies all over the place. In fact I'd be tempted to guess an audio delay of 0ms would be the less usual circumstance.
I've encoded plenty of episodic DVDs where the audio delay is different for each episode.

[Ghitulescu]

I don't spend my time "archiving my DVD collection", rather occasionally (99.99% to add missing subtitles for my part of the family that doesn't understand the movie language). I think I met once or twice DVDs that had an audio delay <> 0ms, so for me <>0ms is rather an exception and even then it was below 100ms. On the other hand I process lots of DVB (mainly dokus that would probably never reach the DVD distribution) and due to technicalities of DVB there will always be a delay, to compensate for the different path lengths.

Use manono's advice, find the real delay - on heavily protected DVDs most PGCs start and end with tiny cells with no audio tracks. Remove them (vobblanker, fixvts etc.) before de/remux.

[r0lZ]

I agree with Ghitulescu. Properly authored DVDs should have a null delay.

When they have been butchered by ARccOS or RipGuard, it's another story. There are tiny cells at the beginning of the movie that are intentionally totally illegal. Remove them. If your movie begins with the first real cell (with video content), the delay should be 0 again, or at least < 100ms (or > -100ms).

[yetanotherid]

I don't spend my time "archiving my DVD collection", rather occasionally (99.99% to add missing subtitles for my part of the family that doesn't understand the movie language). I think I met once or twice DVDs that had an audio delay <> 0ms, so for me <>0ms is rather an exception and even then it was below 100ms.

I've got a large collection of AVIs converted from DVDs. After demuxing, most conversion programs write the amount of delay as part of the audio track's name, and that delay amount is then used when remuxing the video. If you manually load an audio track to be muxed into an MeGUI encode, for example, and the audio track includes a delay time in it's name, MeGUI will automatically use that delay value for the audio delay.
Whatever the reasons for the audio delay, be it a positive or negative value, I'm fairly certain a delay of zero wouldn't be the most common value when it comes to commercial DVDs, and that's after running fixvts on the ripped files before demuxing (which I always do).

[manono]

Whatever the reasons for the audio delay, be it a positive or negative value, I'm fairly certain a delay of zero wouldn't be the most common value when it comes to commercial DVDs, and that's after running fixvts on the ripped files before demuxing (which I always do).
Of the several thousand retail DVDs with which I've worked, probably over 95% had delays of 0ms. It may be as high as 98% or so. I rarely see anything except 0ms delays. If you're demuxing with DVD Decrypter, be aware that its delays are wrong.

[yetanotherid]

I didn't even know you could demux with DVD Decrypter.
I'm just going by the number of times I've seen an audio delay written into the name of the audio track after AutoGK has demuxed it (I assume it uses DGIndex for the job?). I still swear I've seen an audio delay with a value other than zero, more often than not.

I just happened to have a DVD ripped to my hard drive waiting for conversion (Undisputed 3). AutoGK was busy doing something else, so I used MeGUI to index/demux it just to see what the audio track would look like. It was ripped with RipIt4Me which then cleaned it of unreferenced video etc.
VTS_01_1 T80 3_2ch 384Kbps DELAY -8ms.ac3
Not a huge amount of delay obviously, but still not zero. It makes me wonder what the odds are of my just happening to have a DVD ripped to my hard drive with an audio delay which falls into the 2% category.... well I guess the odds would be about 1 in 50.
Unless of course I'm completely misunderstanding the concept of what constitutes an audio delay here....
But while this example has a delay which is so close to zero you'd not notice it anyway, I've seen plenty of examples where the delay might be 12ms, or 48ms, or 124ms, or 248ms etc.... Thinking about it, more often than not the delay is probably a negative value which effectively means the video is delayed compared to the audio. Now if the audio needs to be delayed due to unreferenced cells etc, it'd be a positive delay, but how could something like that cause a negative audio delay value? Just curious....

http://i10.photobucket.com/albums/a142/dashpb1/delay.gif?t=1305721796

[r0lZ]

I wonder why there would be a non-zero delay if the original streams have been prepared correctly to build the DVD. I think we can assume that the audio and video are originally perfectly synchronized, so when they are encoded (and unless a strange encoder adds or removes some frames), they should be in perfect sync in the final DVD with a delay of 0.

BTW, use PgcDemux to verify the audio delay. It's an excellent demuxer, and you don't need to demux to see the delay. It is 0 for most commercial DVDs I've demuxed so far.

[yetanotherid]

I wonder why there would be a non-zero delay if the original streams have been prepared correctly to build the DVD. I think we can assume that the audio and video are originally perfectly synchronized, so when they are encoded (and unless a strange encoder adds or removes some frames), they should be in perfect sync in the final DVD with a delay of 0.

I don't know the answer but all I can tell you is that after encoding, most encoder GUIs automatically use the delay written to the demuxed audio file as the audio delay when muxing the encoded video, and it's very, very rare that I have to correct it manually. If the demuxed audio file includes a delay of -156ms (for example), then -156ms is used as the audio delay when muxing the AVI/MP4/MKV etc and it's pretty much always in sync.

BTW, use PgcDemux to verify the audio delay. It's an excellent demuxer, and you don't need to demux to see the delay. It is 0 for most commercial DVDs I've demuxed so far.

Well, you forced me to download PgcDemux and use it to open the DVD rip I used as an example in my first post. Thanks for that! ;)

http://i10.photobucket.com/albums/a142/dashpb1/delay2.gif?t=1305727327

I don't know why you generally experience a delay of 0ms while I generally experience a delay of something that isn't, but I promise you I'm not making it up. :)

I've not got any other DVDs ripped to my hard drive at the moment and it'll probably be a few days before I can do so to see what audio delays they'll have, but I'll try to rip a few more at some stage soon.

[yetanotherid]

Here's a quick bit of fun. I just opened my ripped DVD with DVD Shrink. I then re-authored it, removing the first couple of chapters and the last few, leaving me with the section of the middle of the movie about 25 minutes long. I then backed up that 25 minute re-authored movie as a new DVD.
Once it was saved to my drive, I opened it with PgcDemux. PgcDemux reports the newly re-authored DVD as now having an audio delay of -24ms instead of the original -8ms. Don't ask me why..... but maybe it's my re-authoring with DVD Shrink before encoding which has me experiencing the audio delays the rest of you don't?

[r0lZ]

That's normal. The delay changes at each cell (and therefore also at chapter points), and it changes also if you cut a chapter in the middle. It's because the audio and video frames do not have the same duration. When you cut a movie, the audio stream is cut at the nearest frame, but it will usually not match exactly a video frame. Hence the delay.

The discussion above concerns the original delay of non-ARccOS/RipGuard protected DVDs, at the first cell.

BTW, for the same reason, there might also be delays at the first cell of a title when that title is not the first title in the VOBs (ie when its first cell is not cell 1/1), but I'm not sure.

[manono]

VTS_01_1 T80 3_2ch 384Kbps DELAY -8ms.ac3
Not a huge amount of delay obviously, but still not zero. It makes me wonder what the odds are of my just happening to have a DVD ripped to my hard drive with an audio delay which falls into the 2% category
It makes me wonder how you're preparing the VOBs for encoding. You mentioned DVD Shrink. I don't use that for anything. Nor do I ever cut anything from the beginning. Of course, if you're cutting from the beginning then all bets are off. That PGCDemux pic, for example, what happens when you take an older DVD movie (one with no advanced copy protection), just do a normal decrypt using DVD Decrypter, and then check using PGCDemux?

[yetanotherid]

The discussion above concerns the original delay of non-ARccOS/RipGuard protected DVDs, at the first cell.

Are you sure? I didn't know we were specifically discussing non-ARccOS/RipGuard protected DVDs.

[yetanotherid]

It makes me wonder how you're preparing the VOBs for encoding. You mentioned DVD Shrink. I don't use that for anything. Nor do I ever cut anything from the beginning. Of course, if you're cutting from the beginning then all bets are off. That PGCDemux pic, for example, what happens when you take an older DVD movie (one with no advanced copy protection), just do a normal decrypt using DVD Decrypter, and then check using PGCDemux?

Generally, I'll rip a DVD with RipIt4Me in movie-only mode. I assume there's potential there for vobs to be cut. If it's an episodic DVD I'll re-author it with DVD shrink. Sometimes I also use DVD Shrink to remove the studio promos from the beginning of the movie before encoding. I guess all of that could be introducing audio delays.
I won't get a chance for a day or so, but when I do I'll rip some DVDs in full-DVD mode and check them for audio delays before I do any re-authoring.
Maybe you guys are correct and the audio delays I'm seeing are due to the way I've always ripped and prepared DVDs for encoding.

[manono]

Are you sure? I didn't know we were specifically discussing non-ARccOS/RipGuard protected DVDs.
I think r0lZ meant in the paragraph above, within his same post.

I might mention that most of the DVDs with which I work don't have advanced copy protection, I almost always use DVDDecrypter without any 'post-processing' and then check the delay, either when demuxing with DGIndex or (much more commonly) demuxing using PGCDemux. But I don't really see why those with ARccOS or RipGuard, if prepared properly, would turn out to have delays. Your process is slightly different. I don't really see how FixVTS could be responsible for it, so maybe it's DVD Shrink if you use it on most DVDs. And, of course, any cutting will almost always result in a delay.

[Ghitulescu]

Every cut of two or more compressed streams would inherently induce a delay (of max. a frame) per cut. Most people don't perceive delays under 40ms (I've seen however people who couldn't even perceive 1 second of delay).
Tiny cells of 1-2-3-4-5 frames with no audio will induce a 1-5 * frame_duration delay at the beginning.
Due to the internal PS structure, the delays won't affect the DVD playback, however edited streams are separately processed then remuxed and the timing info is lost and recreated.

[r0lZ]

Are you sure? I didn't know we were specifically discussing non-ARccOS/RipGuard protected DVDs.

As I said:
I agree with Ghitulescu. Properly authored DVDs should have a null delay.

When they have been butchered by ARccOS or RipGuard, it's another story. There are tiny cells at the beginning of the movie that are intentionally totally illegal. Remove them. If your movie begins with the first real cell (with video content), the delay should be 0 again, or at least < 100ms (or > -100ms).

[mpucoder]

I would add that properly demuxed DVDs have no delay. I once wrote a paper about the audio delay myth, if a DVD's audio is in sync during playback then there is no delay. The problem is to demux both the audio and video streams and keep them in sync using the same timecodes as a DVD (or any mpeg) player. Due to the nature of mpeg you can not simply extract the streams at an arbitray point and expect them to be in sync, that only happens at the start of a non-seamless VOB with no silence. Anywhere else you usually have to discard the audio packets that belong to the preceeding video, and then you are left with a delay caused, as rolz mentioned, by the disparity between video framerates and audio packet rates.
Copy protection adding in silent sections doesn't confuse a DVD player because of timecodes, demuxers and/or rippers need to do the same. Again, you can not just extract the two streams without checking the timecodes.

[dashali]

Sorry for my Delay. This thread is about unreasonable delays and myself have it!
Very Thnx from all. For my problem I don't find reason, and manually fix delay.

use PgcDemux to verify the audio delay. It's an excellent demuxer, and you don't need to demux to see the delay.
I believe it and always use it.Also VobEdit is very Excellent. But, in my experience, in such cases, VobEdit is preciser than PgcDemux; in cases that Ifo & Vob isn't completely match...
But about display available delays in DVD, PgcDemux is sole.

I would add that properly demuxed DVDs have no delay. I once wrote a paper about the audio delay myth, if a DVD's audio is in sync during playback then there is no delay. The problem is to demux both the audio and video streams and keep them in sync using the same timecodes as a DVD (or any mpeg) player. Due to the nature of mpeg you can not simply extract the streams at an arbitray point and expect them to be in sync, that only happens at the start of a non-seamless VOB with no silence. Anywhere else you usually have to discard the audio packets that belong to the preceeding video, and then you are left with a delay caused, as rolz mentioned, by the disparity between video framerates and audio packet rates.
Copy protection adding in silent sections doesn't confuse a DVD player because of timecodes, demuxers and/or rippers need to do the same. Again, you can not just extract the two streams without checking the timecodes.
I want a question about MuxMan. In a DVD with 5 AC3s and 1 DTS Audio, PgcDemux display delays. For DTS,delay=(-26) and enter this values in muxman for remuxing. After it,check delays. All AC3s Audio's delay is same but for DTS, Delay was (-5). Why?

[mpucoder]

A negative delay indicates that the audio begins before the video. In this case MuxMan will first remove audio packets to get the delay to less than the duration of one packet. AC3 packets represent 32ms of audio, and in this case the desired delay is already less than one packet, so no packets get removed. But DTS packets cover a shorter time period, only 10.667ms, so 2 packets get removed leaving a delay of 5ms (rounded to nearest ms).

[dashali]

Thnx.
If I understand, for example, delay=-49 would be (-17) for AC3?

Why muxman doesn't keep delays as original? I guess it is better that keep original delays,because the author may has mistake in minus sign, if he wants fix that and hasn't elementary demuxed files, he face with problem, because of few first packets deleted from audio.

[mpucoder]

Because delays are not real, they are the result of improper demuxing. The audio that is discarded does not belong with the video, and should have been discarded by the demuxer.