Audio Delays Differences through processing steps

[gm901]

Hi,

Checking some movies, for another purpose, I noticed some differences at Audio Delays, in each step of processing.
Here is the table

Movie A Movie B Movie C Movie D
ORIGINAL DVD
AUDIO_STREAMS 1 2
AUDIO_DELAYS -80 -80, -80
SUB STREAMS 1 1

RIPPED
AUDIO_STREAMS 1 1 2
AUDIO_DELAYS -80 0 -80, -80
SUB STREAMS 1 8 1

Main Movie Shrinked
AUDIO_STREAMS 1 1 1 1
AUDIO_DELAYS -80 -96 -272 0
SUB STREAMS 1 2 1 2

RB(CCE)
AUDIO_STREAMS 1 1 1 1
AUDIO_DELAYS 0 -16 -192 0
SUB STREAMS 1 2 1 2

RB(CCE) > RB(100%)
AUDIO_STREAMS 1 1 1 1
AUDIO_DELAYS 0 -16 -192 0
SUB STREAMS 1 2 1 2


It seems that Shrink, whenever stripping audio or subtitles, modifies the Delay.
[RB CCE], if it finds negative Delay adds 80, no matter what the delay is. If it finds 0 leaves it unchanged.
[RB's CCE] output movie to [RB 100% No Compression] just leaves it alone.

Well, the sample of 4 movies is not adequate but, of all the RB movies I've tested (~50), without, though, having data for the previous processing steps, 60% has audio delay diff than zero, mostly negative, varying from -224 to -16.

Does that practically mean anything?

Maybe, should I leave RB to strip unwanted audios and subtitles ?

Thanks

EDIT Added info for ORIGINAL DVD

[manono]

Hi-

The issue has to do with the 2 frames that are commonly "lost" at the beginning (2 frames=80ms for PAL). The short reason is that the delay as given by DVD Decrypter is wrong, and your result from DVD-RB is correct. Assuming you're pointing DVD-RB to a reasonably recent version of DGDecode.dll, you shouldn't have any problems. For more information, please see Q34 of the DGMPGDec (DVD2AVI) F.A.Q. (http://forum.doom9.org/showthread.php?s=&threadid=87809).

I have no idea why Shrink is changing that delay in some cases, unless it's knocking out more frames for some reason. I think I'd advise you to leave the audio alone until you get to DVD-RB.

[gm901]

Thanks for the answer and the guidance as to what might be related.

I've used the DGDecode 1.0.12 which according to Q34 and neuron.net has solved the lost frames issue.
In any way, I haven’t notice any problem watching the movies.

--“the delay as given by DVD Decrypter is wrong”
you mean that Decrypter logs/shows some info on delay??

As for Shrink, after reading a while (the above guidance..) maybe it’s the way I use to MainMovie the dvds. Usually I cut off a few seconds/mins from the beginning, not of course for compression reasons, that would be insignificant, but because sometimes there is not only the studio’s logo but even the master distributor’s, even yet the author’s, so I’m fed up with too many pompous images and sounds. This cut may be interpreted as “arbitrary VOB cuts”.
So Shrink might be visually gorgeous, though not too harmless.

It seems that RB’s Main Movie function should be added to my wish list.

Thanks again

[manono]

Hi-

you mean that Decrypter logs/shows some info on delay??

Sorry, my mistake. I was thinking of the Stream Information file it gives you when ripping in IFO Mode. So, where did you get that original ripped audio delay from, if not from DVD Decrypter? But whereever it's from, it must have the same delay as DVD Decrypter, because of those "missing" 2 frames. You cutting some from the beginning of the movie explains the different delays after Shrink, and the 80 ms difference after DVD-RB is the actual correct delay after getting the 2 frames back again. Nothing to worry about, as you already know. :)

[gm901]

I’ve scanned the original DVDs just to make sure.
I’ve edited the 1st post adding the results

It seems that the delay exists there from the studio !!!

So I have to modify my previous comment (unless there is a specific use for that delay ???)

Nothing is harmless, even the programs that cost thousands or millions of $/€.

[jdobbs]

DVD-RB transfers the audio and subpictures intact from the original DVD with the exception of those that are excluded. The only time any timing information is changed is when it is offset by some change in the video -- and then DTS/PTS may be adjusted. That is very rare and usually only happens when there is incorrect timing in the video of the original that DVD-RB needs to correct.

What is your definition of audio delay?

[richarddd]

Sometimes 2 disk sets have diferent audio delays, as reported by DVD Decrypter in IFO mode, for the different disks. If I combine the 2 disks, for example, by renumbering vobs sequentially and using IFOEDIT to add ifo's, will RB produce a movie that's in sync from start to end?

[jdobbs]

If the title is in-sync before Rebuilder, it will be in-sync after (assuming the source meets the DVD specifications).

[gm901]

Originally posted by jdobbs
What is your definition of audio delay?
Diff (1st_audio_pts – 1st_Video_pts) //which are 3 bytes @ [0x17] 1staudio or video pack
And then +or-44(if positive or neg)
Then /=90, then the int part.
(Of course it’s not mine, it’s PgcDemux’s)

So the main point is don’t strip yourself, just let RB do it.

BTW from what Delay, more or less, the movie seems (when watching) out of sync ?

[jdobbs]

You have to be careful with that. Are you taking into account that the first video PTS could be temporally off by as much as three frames? That is because even though the I frame is first in the sequence as stored (and the source of your PTS), it could the 3rd that is displayed temporally.

You could adjust based upon the temporal sequence value in the header, but you'd also need to look at the RFF values of the frames that are temporally before it.

Also what are you using to determine what the numbers mean? The PTS/DTS is based on a 90Khz clock -- so each tick is only 1/90,000 of a second. You'd need a value of 9000 to make 1/10 of a second. (I assume that's the purpose of the "/90" in your post).

The best rule of thumb is that the original audio sequence was synched correctly -- so why mess with it?

Looking back -- that's probably where your "80" value is... PAL frames take 3600 clock ticks per frame. Two frames is 7200 -- divide by 90 and you get 80. So if you dump out the PTS of the first I Frame you will probably see it has a sequence number of "2". Now go back to the NAVPACK and look at the VOBU start presentation time and you'll see it is (very likely) a value that is 7200 (80ms) less than the PTS value you pulled from the I Frame.

What I'm trying to say is: "I know what I'm doing."

[gm901]

Originally posted by jdobbs
What I'm trying to say is: "I know what I'm doing." Never questioned that. I’m sorry if I’ve failed to make myself clear.
During all this thread, may have pointed the finger to other SW, never though to RB.
As a matter of fact, why would I do that, to a program that I’ve taken so seriously as to invest a large amount of time and effort???
All I’m saying is that, using a certain program, I found some diffs and asked if it means anything.

My only drive is to understand what’s going on behind my back (my click) and how does that affect my goal which is a perfect movie backup.
And I’ve learned at least 2 things:
--Don’t use Shrink to cut scenes from the start, and
--Use RB to strip

Thanks

[jdobbs]

Please don't take what I say wrong... I truly appreciate what you're doing. You did a great job at pointing out the errors with segment resets on the BCD value and the VOBU_SRI tables.

:)

[gm901]

;)