(PAL Problem ONLY!!) - How to get an m2v file and ac3/lpcm file that will sync

[TRILIGHT]

Originally posted by Mr Zippy
Form my tests DVDMaestro reads the timecode from the M2V and AC3 files, so this means most comments in this thread are useless.

I couldn't agree with this statement more! What in the world kind of process are you people trying that your audio is always out of sync? I don't know how many titles I've backed up in both Maestro and Scenarist now and it is always lined up correctly via the timecode. Perhaps because I use DVD Decrypter and not SmartRipper? Perhaps because the particular method I use does not result in the same issues whatever method you are following produces? The whole "delay" topic should be a non-issue if you're doing things properly.

[Matthew]

"Am I right in thinking that both the demuxed AC3 and M2V files start at 0ms, therefore I need to move the audio AC3 either ahead (- ms) or behind (+ ms) the video to ensure the correct sync. The method to do this is to change the 1st audio frame in the AC3 file to the frame that would have been played at the specified delay by adding/removing frames, rather than changing the time at which the first audio frame is played. So the physcial calculated delay should be 0ms (if the orginal delay is divisable by 32ms audio frames), but the audio frame that is played with the first video frame is still the same as in the orginal VOB."

Sorry I'm confused.

"I have a question on your method I quoted below,

"So here is what you do in the case of a re-encoded video stream, where the -80ms thing is a non-issue:
Cut the AC3 by the smallest number of frames that results in a positive delay. i.e. 4 x 32 = 128. That means your delay is now -111 + 128 = + 17 ms after cutting 4 frames using AC3 delay corrector. Drag the AC3 in maestro to the right by that much. As I said, you have re-encoded the video stream the -80ms won't come into it."

Now in my test dragging audio forward in the timeline adds postive delay ie. moves the audio behind, thefore you would end up making your +17ms AC3 track +37ms if you dragged foward half a frame in the timeline, as you would have moved it behind another 20ms."

No. I'll try to explain it graphically. Ideally you would move your audio file to the left on Maestro by 111 ms. So it looks like the following

Audio: AAABXXXXXX
Video: XXXXXXX

Where AAA = 111 ms and B = 17 ms

But as this is not possible you instead cut off AAA (imagine for a moment you can cut off 111 ms exactly). So it now looks like:

Audio: BXXXXXX
Video: XXXXXXX

In sync. But you cannot cut off 111 ms exactly, you have to cut off another 17 ms, i.e. B

So this is how it should look in Maestro:

Audio: XXXXXX
Video: XXXXXXX

See the audio is dragged to the right by 17 ms.

Hope that clears that part up :)

And TRILIGHT, going by the DVD2AVI reported delays on original and re-muxed dvds, it would not be the best method to rely on timecodes. I don't find this surprising as timecodes are on a frame by frame basis, whereas delays reported by DVD2AVI can be in increments (e.g. 96 ms on a PAL release is nowhere near a multiple of 40).

[mpucoder]

This thread is getting ridiculously circular. Timecodes were all the original authoring program (most likely Scenarist) had to use. The authoring software computes the correct Presentation Time Stamp (PTS) values based on timecodes, hopefully muxes the streams so that it is possible for the player to present them at the proper times. Alignment of the streams is not as important as it is in avi, as the player continously monitors the PTS values.
Yes, it is possible for the authoring software to ignore the timecode or apply an offset to it, but this is not what the "delay value" measures. Rather than comparing the PTS values of the first frame of video and audio for relative offset (which works great for avi alignment) we should be looking at the timestamp to PTS offsets of each stream when working with DVD authoring. This is what can be adjusted by dragging things around the timeline. For most DVDs, though, as Trilight and I have observed, these values are zero, and preserving the timecodes is all that is needed for proper sync.
Unlike avi, DVD does not require audio throughout the movie, it can start before or after the video, and may have gaps in it throughout the movie.

And, finally, a little hint about movie making and timecodes. The first frame of many productions is not time 0:00:00.00, but 0:59:xx.xx This is due to "pre-roll", a second or two of black/silence before the movie. This is a practice left over from automatic tape machines and VITC/LTC codes. Tape machines require a little time (mine need 20 frames) to get up to speed from a dead stop. Habits are hard to break, and whether preparing the movie for DVD or network presentation, the transfer is made with pre-roll. Since there is no negative time, 1:00:00.00 is used as the "start of presentation" time.

[Matthew]

So mpucoder am I correct in saying that we shouldn't be using DVD2AVI for detecting delays when it comes to DVDR?

I don't understand how it can be right to use DVD2AVI for AVI and wrong to use it for DVDR. I can understand that in practical terms it may be unnecessary to use anything other than correct timecodes (presumably this can be achieved by stamping the original timecode on the video stream using CCE?...although a couple of frames can be lost at the beginning of the re-encoded stream, as mentioned before) but as a matter of theory I don't understand how a mpeg2 video stream muxed with an AC3 can require a different delay value than a divx/xvid stream muxed with an AC3. That is to say, I don't understand how my method can be wrong, even if it practical terms using timecodes also achieves the right end.

Sorry if I sound like I'm being a pain in the ass btw, I tend never to shut up until I have no other questions ;)

[mpucoder]

AVI has no timecode, sync depends on the audio and video being properly aligned at the beginning, and the video frame duration (avi does not use frame rate, but duration) and audio sample rate being correct throughout. The difference between the initial PTS values is all that is needed to get it going properly by adding silence or removing some samples.

DVD, being a streaming medium, is quite different. First you must realize that while a movie has a beginning and end, an mpeg stream does not. So there is no initial alignment, only embedded timing information. The PTS value is what all MPEG decoders use to establish sync. This is not the timecode we refer to, though. At the encoding level each stream can have a timecode inserted, and then at the authoring level this timecode can be used to produce the PTS, or it may be ignored.

The objective is to do exactly what the original author did. Unfortunately, you can't be sure if timecodes were used or ignored. The majority of movies have correct timecodes, since that's how Hollywood likes to work. So there are 2 ways to go. Use the timecodes and let the authoring software line up the streams for you. Or disable timecodes and slide the audio around on the timeline by the delay value.

If timecodes are being used, cutting frames will not alter the sync, only introduce silence, since each frame has a timecode, the muxer will just adjust the PTS value accordingly.

The reason more and more of us are getting annoyed by the audio delay is that it addresses only one stream. We are seeing more and more posts about other streams (LPCM, DTS, and now subpictures) being out of sync. Mostly caused by destroying the video stream timecode. In the end it would be best to preserve timecodes and use them for DVD authoring.

[Matthew]

Thank you for clarifying.

"Or disable timecodes and slide the audio around on the timeline by the delay value"

If you mean what I think you do, well it's good to know that the method I'm using is correct for the audio on re-encodes, if nothing else. With subs, being a couple of frames off is not noticeable anyway - there can be differences like that on the original (e.g. english for hearing impaired subs may differ a little in timing from the plain english subs):)

[Mr Zippy]

This has gone back to what I posted a while ago about the AC3 track having a timecode.

Does any program (ie. DVD2AVI) preserve the original timescodes in the demuxed M2V and AC3 files?

If so all we need to do is ensure the timecode is set correctly in CCE when transcoding, this would save a lot of messing around and DVDMaestro would sync the stream automatically from the timecodes.

In my brief test ealier in this thread I got a differet delay in a demuxed then re-authored stream, now this would say that timecodes are not being preserved, as the reauthroed steam should show the orignal delay, as they are synced the same way.

What we need is...

1. A program that is known to demux the VOB streams preserving the orignal timecodes.

2. An accurate method of transcoding with CCE to preserve the orignal timecode.

Then all we would need to do it drag the AC3 and M2V into DVDMaestro and it would all sync (as long as we had not told it to ignor the orignal AC3 timecode).

Now this would be simpler, faster and more accurate than cutting frames and dragging in the timeline.

[Mr Zippy]

Just done a quick test,

1. Demux a VOB
2. Import the M2V into DVDMaestro and view properties to see offset (which appears to be start timecode)
3. Transcode the M2V in CCE setting the timecode to the offset figure from above.
4. Import the transcoded M2V into DVDMaestro, view properties, the timecode is set to the orginal offset :)

Now I have looked at the AC3 track in DVDMaestro, there is no offset (it's blank).

I believe the AC3 timecode is being lost, what we need to do is find a way to demux the AC3 leaving the embedded timecode, then no more messing around as DVDMaestro can sync from the file timecodes.

Only other thing to check is that CCE is starting with the first frame, as there are comments about 2 blank frames in the demuxed VOB and CCE dropping a couple of frames, now CCE needs to start with the same first frame as the orginal M2V as we are assigning frame 0 to the orginal timecode.

I have put the follwing post in the DVD Decrypter Site forum

Can DVD Decrypter be updated to transfer the orignal AC3 PTS timecode into the demuxed AC3 file.

Reason:
----------
The AC3 delay figure is for use only when creating AVI/DivX files as they have no timecode to sync the audio.

To sync a DVD the M2V and AC3 timecode is used in the authoring program.

The problem is AC3 stream output from programs such as DVD Decryter is there is no embedded timecode.

The AC3 PTS timecode is vital for correct audio sync when authoring.

The M2V output appears to have the orignal PTS timecode embedded, so that's not a problem.

[Mr Zippy]

I've added the folling article to my site

http://www.encodinginfo.org.uk/index.php?aid=129

Let me know if you think I have covered issue clearly.

Hopefully someone will find a problem to the missing AC3 timecode.

[Matthew]

Mr Zippy I also performed a test. The AC3 + original video stream muxed with a delay of -80ms (according to DVD2AVI). However when I re-encoded the video stream with the correct timecode this inbuilt delay was not there (0ms according to DVD2AVI) after muxing. That would indicate only a video-stream related issue. Might have something to do with the 2 dropped frames at the beginning (and they are not black in this instance). I tried adding 2 frames to the timecode to account for this but no change in the result. [And "ignore embedded ac3 timcode" in maestro was unchecked].

BTW you can use bitrate viewer to get the timecode. Load vob and click on GOP straight afterwards. First GOP = timecode. No need to wait for demuxing etc ;)

I'm gonna stick with what I've been doing, as it works just fine :)

#BTW 2: saving the dvd as an uncompressed avi using DVD2AVI resulted in the first 2 frames being dropped, so it wasn't CCE's fault ;)

[TRILIGHT]

No offense guys... you're more than welcome to talk about this til the cows come home. hehe ;) However, I think it's very important, especially for newbies who may be trying to learn, that you share the exact process you are using for your backups. Afterall, there are a great number of us who have absolutely no sync issues at all following the process we use.

[airedale]

I have just started with CCE and Maestro and the only movie I have backed up is Silent Bob and Jay Strike Back. I did not have an audio problem at all and the file that I got from DVD2AVI came back with -66 ms, but I just dropped both the movie file and the audio file on the time line and compiled the movie. Didn't have a problem at all with the audio sync.

[Mr Zippy]

Matthew if you re-encoded the video assigning the correct timecode then the delay would be the same, unless your frameserver or demuxer is adding extra frames and two PAL frames would be 80ms. I have read that mpeg2dec can have frame innaccuracies, mpeg2dec2 is supposed to be more accurate. Also one question how do you find out 2 frames at the start are added?

Trilight I am using the DVD Full copy and Getting the best out of CCE guides from this site.

I have not had sync problems yet, but I want to do this correctly, and the correct way would be to have an AC3 and M2V file with an embedded timecode, which is read when dragged into an authoring program - this is the way it would have originally been authored.

Now as in tests it makes no difference whether you select 'ignor AC3 timecode', and also when looking at the properties of the AC3 file there is no offset figure, I would say the issue is extracting the AC3 stream from the VOB with the timecode still embedded.

[Mr Zippy]

The author of DVD Decrypter point out that you can output RAW AC3 which includes all the frame information including the timecode.

DVDMaestro and Senarist cannot read the RAW AC3 file.

Does anyone know how we could convert the RAW AC3 file to a usable AC3 file with the timecode still remaining?

[Matthew]

"Matthew if you re-encoded the video assigning the correct timecode then the delay would be the same"

Well it isn't ;) Have you tried it yourself?

"unless your frameserver or demuxer is adding extra frames and two PAL frames would be 80ms"

Haven't checked that but the delay is 0ms so don't think so...

"I have read that mpeg2dec can have frame innaccuracies, mpeg2dec2 is supposed to be more accurate."

Using DVD2AVI to save as a lossless avi results in the 2 frames being dropped though.

"Also one question how do you find out 2 frames at the start are added?"

Womble MPEG2 VCR or whatever it is called. M2-Edit would also do the trick.

[Alphaloop]

Concerning the frame problem at the beginning I did a lot of tests:

1) Rip the first chapter, no stream processing
2) check Frame number of the first non black frame with M2-Edit Pro
3) Demux video stream with vobedit
4) Do Step 2 with this demuxed .m2v file
5) Transcode with CCE (doesn't depend on VBR/CBR, when it happens, then in both)
6) Do step 2 with this transcoded .m2v file

Results:
a) The Original VOB and the demuxed M2V had always same frame position
b) The CCE transcoded M2V sometimes has its first non black pic two frames earlier (only tested PAL movies)

Notes:
There are two groups of movies, one group ( called group A) is okay, the other ( called group B) has this effect. But how to categorize movies into one of these groups?:
a) Group B had always some strange timecode shown in M2Edit (like 58:xx:xx or 03:xx:xx), group A always had timecode 1:00:00:00 or 00:00:00:00 in M2Edit) ("always" is meant concerning my tests with apx. 10 DVDs)
b) If I used "Step 3"-M2Vs and audio streams from Group B with the Authoring feature of IfoEdit, then the resulting delay was exactly 80ms (two PAL frames) lower than any of my entered delay tries. Seems like IfoEdit cuts two frames when authoring, same does CCE.
c) If I use "Step 5"-M2Vs of Group B (cce with 2 "cut" frames) with IfoEdits authoring feature, all is fine, resulting delay is exactly the value I entered. Seems IfoEdit then doesn't "cut" any more frames when cce already did it.

Conclusion:
a) Seems like sometimes there are two (PAL at least) frames in front of the movie, which are cut either by cce when transcoded or by IfoEdit when authored.
b) To get audio sync, just add +80ms (PAL) to the audio delay to compensate the two "missing" frames.
c) The calculated audio delay which the rippers (and dvd2avi) show is calculated with the two frames, so just add 80ms to audio delay

I now rip (and demux while ripping) the first chapter and "reauthor" it quickly with IfoEdit. If same delay comes out, it's group A, if not, it's group B. Group A: all is fine Group B: add 80ms (PAL)

Well, just statistics, maybe I'm completely wrong...(?) :rolleyes:

[Matthew]

Alphaloop I agree with most of what you say, except how you should deal with transcoded streams.

I'll represent my thoughts graphically. For a film with -80ms delay:

original m2v + ac3 looks like this

audio XXXXXXXX
video AAXXXXXX

AA = 2 frames (80ms) and the reason they are dropped on a re-encode is that they are there as "filler". The video actually starts at the first X in "real terms". In other words, these 2 frames form a negative audio delay.

That means you want the re-encoded m2v to look like this:

audio XXXXXXXX
video XXXXXX

That is, you want a -80ms delay on the audio

So you should input a delay of -80 ms into IFOEdit (or in my case I'd cut 3 frames - 96ms use ac3 delay corrector, and ensure I got a +16ms delay after muxing in Maestro).

In the case of that odd +29ms (I think) delay you had that I saw in CCE forum:

Original:

audio BXXXXXXXX
video AAXXXXXXXXX

B = 29ms. Again the 2 frames = filler.

You want remuxed to look like this:

audio BXXXXXXXX
video XXXXXXXXX

So you drag audio to the right in Maestro by 29ms or enter this value in IFOEdit.

Of course this is just a theory, make be completely wrong.

[Alphaloop]

Well, but with adding 80ms instead of subtracting I had perfect sync in Lethal Weapon 1 (Swiss Version). :confused: Well, maybe my ears were sleeping... ;)

Well okay, maybe I'm too fixated onto the IfoEdit authoring feature:
IfoEdit took my video, my +29ms audio, and finally made a -51ms delay. Possibly IfoEdit took both streams, aligned them by my delay, and then cut the two frames, result: The audiostream is (by value) 80ms "too early", but concerning original sync correct.

Original (A=Fill frames, B=29ms delay):

V: AA1234
A: BXxXXX


Demuxing:
V: AA1234; A: BXxXXX

Reauthoring:
1st step - Aligning:

V: AA1234
A: BXxXXX


2nd step - cut 2 fill frames:

V: 1234
A: BXxXXX


That'd explain that my +29 got -51...

Now to CCE:
Again V: AA1234; A: BXxXXX
CCE now cuts 2 frames. => V: 1234
IfoEdit -> Authoring DVD...Enter delay +29:
Now the two fill frames are already gone, so IfoEdit aligns directly at the "1", not at the "A", so you have to subtract 80ms for two frames to get the "x" under the "1":

V: 1234
A: BXxXXX


I'm more and more confused...
*doingsomemoretests*

[Alphaloop]

:confused: :confused: :confused:

Why the hell is the first non black pic at the same position, when I reauthor the original videostream with IfoEdit and load it into M2EditPro? That destroys my theory concerning IfoEdit and its frame cuts. :devil:

*justmoretesting,evenwithmaestro*

PS: The two cut frames are not the "fault" of CCE. Just open the .avs into VirtualDub and you'll see that they are already there gone.

[Mr Zippy]

PS: The two cut frames are not the "fault" of CCE. Just open the .avs into VirtualDub and you'll see that they are already there gone.
This brings me back to my comment about mpeg2dec not being 100% frame accurate. I have not had a lot of time to test all this yet, but try mpeg2dec2 if you get a chance.



c) The calculated audio delay which the rippers (and dvd2avi) show is calculated with the two frames, so just add 80ms to audio delay
This goes agaist what I read about DVD2AVI (I think), as the audio delay is the difference between the first video I frame and the first audio frame being played, now would the 2 blank frames be I frames ie. have a timecode?

This is getting more complicated by the day, there seems to be no definative method to 100% perfect sync - except 1:1 copy of DVD5 discs.

Maybe someone can sort out a mehtod of ripping the AC3 with the timecode still embedded, as the M2V already has a timecode embedded sync would be automatic in authoring programs. The only problem would occur when transcoding, as with these 2 possible lost frames you could end up assigning the start time code to the 3rd video frame rarther than the 1st (if 2 frames had been dropped).

[Mr Zippy]

Just done a quick test on the video frame loss...

Orginal IFO for movie shows 1:30:53.16

Mehtod 1 - 1:30:53.10
Method 2 - 1:30:53.13
Method 3 - 1:30:53.16

Method 1 = Create D2V file with DVD2AVI 1.76, open in CCE with AVIsynth/mpeg2dec2.dll - read number of detected frames.

Method 2 = Create D2V file with DVD2AVI 1.76, create AVI with VFAPIConv, open AVI in CCE - read number of detected frames.

Method 3 = Demux VOB to M2V and open with DVDMaestro and read report frames.

This is interesting, if we can sort this out we can at least accuratly use the AC3 Corrector method for now.

[Alphaloop]

@Mr Zippy: But be aware, that the "lost" frames aren't all at the beginning everytime. Just compare the files in M2EditPro or some other program with exact timeline and still picture preview.


BTW: Same effect like IfoEdit with DVDMaestro. I demuxed video and audio, importet them into DVDMaestro, just put them into the timeline (maximum left, no aligning), compiled it, checked delay with Tsunamis streams.exe: Result was a delay of -80ms :devil:
But same number of frames in source .m2v and in final .vob, so no frames where lost... :confused:

I guess there's somewhere something that irritates the authoring tools...

[gizmau]

Originally posted by DSPguru
i once wrote a small tool that updates AC3's dialog normalization tag and then updates the crc1&crc2 tags.

could you please please please offer this tool for download, please?

[Matthew]

I was thinking, maybe this is all simply a result of a bug in DVD2AVI. After all, using DVD2AVI to save as a lossless avi (which bypasses mpeg2dec) results in the frames being dropped.

Lets assume that as far as DVD2AVI is concerned, those 2 frames at the beginning don't exist.

The results are the same as in my previous post, but this perhaps makes more sense.

This means that for a film with 0ms delay, where DVD2AVI doesn't like the first 2 frames, is as follows.

original m2v + ac3 actually looks like this

audio XXXXXXXX
video AAXXXXXX

AA = 2 frames DVD2AVI doesn't like.

DVD2AVI sees the original VOBs (or muxed unreencoded streams) like this:

audio XXXXXXXX
video XXXXXX

Which equates to a -80ms delay.

Now when you re-encode, on account of the DVD2AVI project file the first 2 frames are dropped. DVD2AVI didn't recognise them when calculating the delay anyway, so you want the re-encoded m2v + AC3 to look like the above.

That is, you want a -80ms delay on the audio

So you should input a delay of -80 ms into IFOEdit (or in my case I'd cut 3 frames - 96ms use ac3 delay corrector, and ensure I got a +16ms delay after muxing in Maestro).

In the case of that odd +29ms (I think) delay you had that I saw in CCE forum, the real delay is actually 109 ms.

Original m2v + ac3 actually looks like this:

audio BXXXXXXXX
video AAXXXXXXXXX

B = 29ms. Again A = 2 frames DVD2AVI doesn't like.

As DVD2AVI doesn't recognise these first 2 frames, it sees only the following, and the delay is calculated accordingly.

So DVD2AVI sees this:

audio BXXXXXXXX
video XXXXXXXXX

And so that is how you want the remuxed file to look like, as the 2 frames at the front are dropped.

So you drag audio to the right in Maestro by 29ms or enter this value in IFOEdit.

So if this theory is correct, this issue is totally separate from the timecodes one, which makes sense :)

[Alphaloop]

Matthew, why do you align the audio at the "A"s in the first code-example, but in "my" 29ms-example at the "X"s? ;)

[Matthew]

In the second example, remember, DVD2AVI sees this:

audio BXXXXXXXX
video XXXXXXXXX

And hence calculates a delay of 29 ms.

But in actual fact it actually looks like this, as the first 2 frames are not seen by DVD2AVI:

audio BXXXXXXXX
video AAXXXXXXXXX

So real delay is 29 + 80 = 109ms. So that means audio is 109 ms to right of video in original.

In the first example, on the other hand, real delay is -80 + 80 = 0ms. So that means audio lines up with video in original.

[Alphaloop]

BTW: Not only DVD2Avi drops the frames, also does actual VirtualDubMod, which is able to open mpeg2 vob.

[Matthew]

Oh okay. Well regardless of the reason DVD2AVI drops the frames, my analysis makes sense in terms of how to compensate for this "problem". Then again I would say that :D

[Mr Zippy]

As DVD2AVI doesn't recognise these first 2 frames, it sees only the following, and the delay is calculated accordingly.
Note that if you demux with DVD2AVI the frames are not lost the length of the M2V corrisponds with the reported length in the IFO file, therefore DVD2AVI knows those frames are there and this is used in the delay calculation, also DVD Decrypter gives the same reported AC3 delay.

The issue is establishing whether any frames at the beginning have been dropped, so that we can manually align the audio with the video in the abscence of the a timecoded AC3 output.

Another question would be is there another way to get the M2V stream into a program such as CCE for transcoding, that is 100% frame accurate?

And lets face it, if we can fix the video be 100% frame accurate during the transcode all we need for simple sync would be a way to extract the orignal AC3 with the original PTS timecode embedded.

[Alphaloop]

So we may be absolutely sure that DVD2Avi (and Tsunamis stream.exe, and ...) calculate the delay regarding the two frames? If that would be 100% sure, we just need to look whether two frames were dropped after encoding and compensate them with a value of 80.


I saw, that IfoEdit makes a 80ms slide to the left when authoring the original stream, so just demux first chapter, author in IfoEdit and look whether IfoEdit creates exactly same delay as you entered. If yes, no "frame effect", if no, "frame effect" occurs. Am I right...at least a little? :cool:

[Mr Zippy]

Sounds right to me, I have a weeks leave in work so I'll have some time this week to investigate, what I want to do is put a AC3 Delay guide on my web site when we have resolved this issue.

As I've said before if someone can write a program to demux AC3 from the VOB with the PTS timestamps embedded that would simplify the AC3 Delay further, also a way to frame serve without dropping and frames would be helpful. See below for a compartision in methods that would be required to re-author a DVD.

Now
===
1. Demux VOB
2. Transcode video.
3. Use a IfoEdit or similar to see if DVD2AVI is dropping 2 frames at start.
4. Compensate delay figure if 2 frames (80ms) dropped.
5. Use AC3 corrector to add several frames to make the delay positve.
6. Re-author - ensure you drag the AC3 forward in authoring program forward to remove postive delay created in step 3 above - 1 frame = 40ms in PAL (if required).


If AC3 timecode embedded and no video frames dropped
====================================================
1. Demux VOB to M2V and AC3 both with embedded timecodes.
3. Transcode video assigning orignal start timecode.
4. Re-author by dragging M2V and AC3 files into your timeline.

[Alphaloop]

I have a weeks leave in work so I'll have some time this week

You lucky one!
I have 4 exams at the end of februar. One of them is my study exam in math. :scared:


Use a IfoEdit or similar to see if DVD2AVI is dropping 2 frames at start.

Yeah, I do it this quick way:
DVDDecrypter -> only 1st chapter -> stream processing -> demux while ripping video and single audio -> IfoEdit -> Author DVD -> Enter Delay shown by DVDDecrypter -> final delay 80ms too low? 2 frames dropped, otherwise not
After checked that I start ripping complete movie.

[TRILIGHT]

Just to reiterate for all the newbies out there trying to learn...

All of these "extra steps" are not necessary to make a reliable working backup of your DVD. Follow the full copy guides (http://dvdguides.trilight.net) and you won't have any problems. Myself and others are available here on the forum or on IRC if you have any questions.

[Alphaloop]

Yeah, here is just the playground of a few nerds who have to much of spare time, who want to know why something is working...well...or why not. :D

[Mr Zippy]

I agree as I have not had a problem yet, but from all the details of dropped video frames and AC3 delay it is perceivable that a problem of noticable bad sync will appear, especially if the movie had a large offsets as it's suggested delay offset greater 80ms would be noticable to the human ear.

I am a perfectionist, and really you want the audio and video to be 100% in sync. I intend to put a simple guide to AC3 delay on my web site, but I still want to do some more research first.

If we can find a more accurate way to frame serve the M2V to transcode with no fear of dropped frames, then the AC3 delay corrector stage is very simple.

Demux VOB to M2V & AC3
Frame serve video to encoder
Transcode video
Change AC3 delay to positve by adding frames (32ms) with AC3 corrector
Drag M2V and AC3 into authoring program
Pull AC3 track forward to remove the postive delay created as best possible - 1 frame=40ms

[Matthew]

Originally posted by TRILIGHT
Just to reiterate for all the newbies out there trying to learn...

All of these "extra steps" are not necessary to make a reliable working backup of your DVD. Follow the full copy guides (http://dvdguides.trilight.net) and you won't have any problems. Myself and others are available here on the forum or on IRC if you have any questions.

Not entirely sure I agree with that as in my experience the guides don't adequately explain how to deal with audio delays. No offense, they are fantasic guides, just insufficient when it comes to non-zero audio delays. IMO anyway :)

[Matthew]

Originally posted by Alphaloop
I saw, that IfoEdit makes a 80ms slide to the left when authoring the original stream, so just demux first chapter, author in IfoEdit and look whether IfoEdit creates exactly same delay as you entered. If yes, no "frame effect", if no, "frame effect" occurs. Am I right...at least a little? :cool:

Well I'd disagree that IFOEdit makes an 80ms slide to the left - DVD2AVI just doesn't see those 2 frames when calculating the delay. But yeah I'd agree that if you demux the original files and reauthor them in IFOEdit or Maestro (without entering in a delay), and DVD2AVI tells you the delay is -80ms, then the drop frame problem is there.

But even if the delay is -80ms and is "normal", i.e. there are no dropped frames, then you still deal with it in the same fashion :) So you don't actually need to know whether the delay is on account of the drop frame phenomenon, unless you want to get exact chapters - in which case you'll need to subtract 2 frames from each of the chapter points :)

Mr Zippy a correction here:

"5. Use AC3 corrector to add several frames to make the delay positve."

You need to cut frames, not add them. Remember the audio starts before the video with a negative delay, so you need to cut frames so it starts after the video.

I've been doing this for months, as outlined in my first post in this thread, just follow that :)

[Alphaloop]

Just try it by yourself: Take one of those movies, demux video and audio of the first chapter, start IfoEdit, Author DVD, put in both streams, put in a fictitiously delay, and you'll see that the resulting delay will be 80ms less than your value (just load the resulting vob-set into dvd2avi). Whether its IfoEdits point in sliding left, or Stream's/DVD2Avi's point in seeing the delay, I don't know.

[mpucoder]

You're not trying to get the delay to be zero, are you? That would be wrong. Your authored DVD should have the same delay as the original.

[Matthew]

Originally posted by Alphaloop
Just try it by yourself: Take one of those movies, demux video and audio of the first chapter, start IfoEdit, Author DVD, put in both streams, put in a fictitiously delay, and you'll see that the resulting delay will be 80ms less than your value (just load the resulting vob-set into dvd2avi). Whether its IfoEdits point in sliding left, or Stream's/DVD2Avi's point in seeing the delay, I don't know.

Well you have to ask: why would IfoEdit/Maestro set the frames back 2? Only thing I can think of is timecodes. But when AC3 embedded timecodes are disabled in maestro, DVD2AVI still reports the -80ms delay. So I'd think that rules out the authoring application being the explanatory factor.

And mpucoder, what we are trying to do is get the effective delay on the reauthored DVD to be exactly the same e.g. with a -10ms film you'd cut off a 32 ms frame and then the delay on the file would be +22. So you'd drag it by that much to the right in Maestro. The reported delay would be different, before and after, but the sync would be perfect.

[Alphaloop]

@mpucoder: Yes, I always make the delay same as original. It was only an IfoEdit test to show that whatever delay you input, the resulting delay is 80ms less. I don't know why, and that makes me crazy. I check the delay of the original vob, I demux, I reauthor, I check the delay of the authored vob. It's 80ms lower in those movies. Did IfoEdit slide the audio two frames left? Or did DVD2AVI calc/report the two delays in different ways because of slightly different muxing rules? that's the questoin....

[Mr Zippy]

Well I'd disagree that IFOEdit makes an 80ms slide to the left - DVD2AVI just doesn't see those 2 frames when calculating the delay. But yeah I'd agree that if you demux the original files and reauthor them in IFOEdit or Maestro (without entering in a delay), and DVD2AVI tells you the delay is -80ms, then the drop frame problem is there.
I have posted this several times before, but the delay is calculated as the time difference between the first video I frame and the first audio frame, and DVD2AVI DOES calculate this correctly whether frames are dropped or not. You can verifty this by using DVD Decrypter or DVD2AVI to demux the VOB file, you'll find the output M2V has exactly the same number of frames as specified i the oringal IFO file - or am I missing something.

You need to cut frames, not add them. Remember the audio starts before the video with a negative delay, so you need to cut frames so it starts after the video.
My error, sorry your right.

You're not trying to get the delay to be zero, are you? That would be wrong. Your authored DVD should have the same delay as the original.
Getting the delay effectivly to zero by cutting frames is probably the simlest way to correct for lack of timecode in the AC3 file. Although the reported delay will be zero, the actual 1st audio frame played should be the one that would have been played at the specifed delay time.

What we need:
Frame accurrate frame serving - no dropped frames
Demxed AC3 with embedded timecode

[mpucoder]

This thread is going so far away from the truth that I have been reluctant to participate. I dislike taking people to task, but I must. PTS is a timestamp, it is NOT the timecode I referred to in audio and video streams. That timecode is seperate, PTS is derived from it. PTS is an MPEG timestamp, and, therefore, does NOT appear in a properly demuxed AC3, DTS, or LPCM stream. These streams are not MPEG streams, but DVD extensions, so they ALL appear as a privately defined data object in private stream 1.

While the AC3 timecode is optional, it is not an extension (that is it takes no additional bits), so it would be highly unlikely that demuxing the stream would remove it. I've never seen it disappear. However, there will be no PTS to compare it to for offset, that must be done in a system stream, such as a vob file.

The "audio delay" is a measure of how early or late the audio start is relative to the video, it is not pertinent to DVD muxing, but only to avi. It is normal for one stream to start before the other, lining them up will introduce sync loss in such a case.

Think about this: the DVD plays fine with the "audio delay" being non-zero. What is more logical, to duplicate the original conditions, or to strive for what you perceive as perfection, even though you don't understand the basic concepts of MPEG?

[Alphaloop]

@mpucoder:
So please be so kind to say how would you handle this:
A movie, ripped in IFO Mode with DVDDecrypter. The info files reports that the audio stream has a delay of +17. Demux audio for later use. Start DVD2Avi, create project, AviSynth, load into CCE, encode. Now I have a reencoded .m2v and an .ac3 file. I start IfoEdit, Author DVD, put in both streams, set the delay +17 into the delay field, and wait until IfoEdit finished. Am I right with these steps? Did I make any mistake?

Now the problem: what if the cce encoded video stream has two frames less at the beginning? Nevertheless use +17?

[mpucoder]

I can't comment on any process that uses frame serving. I've never used it.

[Alphaloop]

Well, okay, then just from starting point: A DVD, to be backuped movie only, is ripped in movie mode and showed a delay of +17. The movie is too big, has to be transcoded by cce...

[Mr Zippy]

While the AC3 timecode is optional, it is not an extension (that is it takes no additional bits), so it would be highly unlikely that demuxing the stream would remove it. I've never seen it disappear. However, there will be no PTS to compare it to for offset, that must be done in a system stream, such as a vob file.
I do understand this, but looking at the asset properties for the M2V and AC3 streams in DVDMaestro, the M2V stream shows an offset which I belive is the start timecode, yet the offset box is blank on the AC3 stream properties.

I have take this blank offset as meaning no timecode is present, also if I re-author and demux I get the same -80ms delay whether DVDMaestro is set to ignor AC3 timecode or not.

If the AC3 stream has no timecode, as I believe, is there a way to tell DVDMaestro the start timecode for the audio? I have looked in Sonic Sencarist, which is too complaicated for me, but it looks like you can add the start timecode for the AC3 track.

[mpucoder]

@Alpha - I understand why frameserving is used. I just don't do it. There are other ways to transcode with CCE.

@MrZippy - show me the first 20 bytes of an AC3 stream, and I'll show you the timecode. The problem I see here is no one is bothering to look up specs, or visit info pages, but trying to reverse engineer everything by way of observation of program behaviour. At least look at the files with a hex viewer.
Then have a look at some info, such as www.mpucoder.com/dvd/ and, especially for AC3, look at http://www.atsc.org/standards/a_52a.pdf

[Mr Zippy]

Ok, I admit I am possibly looking for a quick fix without reading the background info. As I said yesterday I have a weeks leave this week, so I'm going to spend some time looking into this.

So are you saying the demuxed AC3 does have a timecode?

If so, why when re-authoring M2V and AC3 streams in DVDMaestro is the output file when demuxed got a different delay? If the timecodes were present the delay should be exactly the same.

What I'm thinking is the orignal AC3 used to author the movie had a timecode, but this timecode was just used to align the audio using the PTS code, when demuxed the AC3 has no timecode as it was never embedded in the movie.

I understand why frameserving is used. I just don't do it. There are other ways to transcode with CCE
What other methods?

[Matthew]

"What other methods?"

Perhaps he means loading in an avi. Although saving an avi from a vob using DVD2AVI = 2 frames lost as well.