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

[Matthew]

mpucoder the problem with background technical information on a topic like this is that it is difficult to understand, at least in my case :D

Also, taking people to task is a good idea, you are doing the person/people a favour :) I know I like to be told I'm wrong if, I am indeed wrong :) But you have to destroy them point by point :D

Anyway, in regards to this remark by you:

"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."

What I am trying to do is make it so that the streams, in effect, line up as they did in the original DVD.

Because as I understand it, just chucking them in Maestro means the streams are lined up, like you say they shouldn't be.

Do you dispute that if DVD2AVI reports a delay of 20 ms, say, it is wrong to ensure the remuxed file has a 20 ms delay by dragging to the right in Maestro? If the delay is measured as the time taken between when the first video frame is played and the first audio frame is played then how can this be wrong?

You yourself said earlier in this thread "Or disable timecodes and slide the audio around on the timeline by the delay value."

Well, if this dragging of the audio to the right is acceptable, how is that different from achieving sync on a negative audio delay by cutting frames. As you can't drag to the left of the video stream in Maestro, you need to remove the gap by cutting frames.

i.e.

audio XYZ
video YZ

is the same as the reauthored:

audio YZ
video YZ

except you are missing part X of the audio as you've cut it out..and it ain't noticable.

And Mr. Zippy, back to the question of whether DVD2AVI takes account of those 2 frames at the beginning. Well I tried a few DVDs, and of the ones that were 0ms according to DVD2AVI, none had dropped frames at the beginning when re-encoded. A couple had a -80ms delay and those lost the first 2 frames on re-encoding. Just appears as though DVD2AVI (and DVD Decryptor, etc) output delays that treat those 2 frames as not existing (for whatever reason) rather than authoring progs mysteriously shifting the audio.

[Alphaloop]

Today I experiences a weird thing: After trying many PAL movies, I tried a NTSC. It also had the frame issue. I ripped it, DVDDecrypter reported delay -67. Took both original streams into DVDMaestro, just dropped them into the timeline, compiled the project, and tested the delay. It came out with -67, and perfectly in sync.

Seems that all my problems are concentrated on PAL movies, so it's not surprising that so many people here haven't any sync probs, because they mostly do NTSC.


@mpucoder

Your authored DVD should have the same delay as the original.

Only two questions for understanding concerning those movies with the dropped frames issue:
If I take the original demuxed stream to reauthor it in IfoEdit or DVDMaestro, then I have to (disregarding what the auhtoring programs really does) enter a (corrected, if necessary) delay so that the reported delay of the final dvd-structure is the same like the one reported of the original dvd?
Now I have reencoded the stream, resulting in a stream that has two frames less at the beginning. Do I have to take care of the 80ms (2 frames PAL) in aligning the delay to the original vob? Now I actually have to work like already the original vob has two frames less at the beginning, ergo: like the original vob has 80ms more delay in it?

It's weird that it seems to function automatically with NTSC, but not with PAL movies. :confused:

[TRILIGHT]

Originally posted by Alphaloop
It's weird that it seems to function automatically with NTSC, but not with PAL movies. :confused:
Now this would make a LOT more sense considering myself and everyone I know works with NTSC material. Honestly couldn't tell you the first thing about PAL. However, from my understanding, PAL framerate is 25fps though I've seen people say to just use the encoded video as is which really is at Film speed of 23.97fps. Could it be the discrepancy in these two framerates that is really at the heart of your problem? Just a thought. ;)

[atreides93]

Originally posted by mpucoder

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?

Mpucoder,

whoah you've made me wonder about how I'm backing up dvd's now! maybe i'm doing it wrong!

This is what I do, please tell me if this is wrong.

I re-encode the entire movie using dvd2avi to avisynth to cce 2.50

I demux the AC3 file with dvd2avi

I use ac3delay to adjust the delay (whatever dvd2avi said the delay was). ac3delaly automatically grabs the correct value from the file name.

I then take these two files the m2v file and ac3 file and mux them with SpruceUP or Maestro. I don't do anything else with the ac3 file delay, i just lign it up with the video.

So according to you I shouldn't be doing the ac3delay step?

[Mr Zippy]

I am also only doing PAL movies, maybe it's a problem with the demuxing software when it comes to PAL movies.

I cannot believe it is Maestro of Senarist as they are professional programs that are designed for PAL and NTSC.

Hopefully we will find a simple AC3 solution, as just dragging freshly demuxed M2V and AC3 files from a PAL DVD into Maestro does not give the correct original delay, as it has been said NTSC does.

[benf2]

:( My demons are when the ac3 starts to slowly become out of sync 2/3 into the movie...the only thing i havent tried, which someone mentioned in a thread is to change the video framerate in the avs script and not to use pulldown...(i do ntsc movies) then just import into maestro as usual.

[atreides93]

benf, how often does that happen to you where you see it lose sync later on in the movie?

I did a rip of Airforce One and it appears to be in sync up to the end of the movie. Its NTSC

[benf2]

too many...i usually windup trashing the movie cause i get frustrated with it. All that time encoding wasted:mad:

I probably have 100+/- movies remuxed to dvd and i would say appx 25-30 i had problems with audio sync.

I tried using the ac3 file from smartripper, dvd2avi, vstrip...same problem. Thats why i am starting to think it has to do with the m2v file that was encoded in cce.

[gizmau]

@benf2
when all those movies were encoded/authored on the same machine, then i suggest a hardware related problem rather than a bad working program.

when you rip the dvd and demux the ac3, drag it into besplit/besliced and select 'fix' - are the sync errors reported? if so, then your ram modules (i believe that there are at least two different modules in the slots, isnt it? ;-) ) produce this, at least in 99% of all cases...

afaik, these corrupted frames are dropped during decoding/transcoding with besweet, therefore drifts the stream out of sync.

[Matthew]

Originally posted by Alphaloop
Today I experiences a weird thing: After trying many PAL movies, I tried a NTSC. It also had the frame issue. I ripped it, DVDDecrypter reported delay -67. Took both original streams into DVDMaestro, just dropped them into the timeline, compiled the project, and tested the delay. It came out with -67, and perfectly in sync.

Seems that all my problems are concentrated on PAL movies, so it's not surprising that so many people here haven't any sync probs, because they mostly do NTSC.

2 frames were dropped right?

Well 1/25 * 1000 * 2 = 80ms (PAL)
1/29.97 * 1000 * 2 = ~67 ms (NTSC)

So I think what happened with your NTSC DVD is no different from what happens with the -80ms PAL DVDs with 2 dropped frames.

The real test would be to have an NTSC DVD with an unusual delay :)

BTW TRILIGHT that comment about the encoded video speed being 23.97fps is probably because the mastering places often will create a PAL DVD by speeding up the (NTSC) video. That's why a PAL DVD is often shorter than the NTSC equivalent (and the video moves !4 percent quicker). But the video on the DVD is indeed 25 fps :)

[Alphaloop]

Soon we'll win the Doom9-Trophy for the longest thread. ;)

Sorry, I only have three NTSC-DVDs here (3 hentais :D). Two of them have delay 0 and no frame issues, the third is my only test example which I own.

The only facts that interest me at the moment are:

-When calculating the delay, is DVD2Avi comparing first audio frame with first video stream frame (means first of the two fill frames), or with "first movie frame" (means disregards two fillers and takes the third frame) (My guess: first stream frame (filler))
Ergo: Whatever the authoring programm changes the delay itself or whatsoever, just enter a (corrected) delay, so that the final delay matches the original delay

-when cce is cutting the two frames, will i have to include that "gap" into my delay calculations for auhtoring to compare with original delay? Means: Original delay is calculated (1st audio frame):(1st video frame [=filler]). Now first two frames are gone, I have to play with a 80ms (PAL)/67ms (NTSC) bigger delay in my authoring attempts when comparing with the original, so make my delay match the original delay minus 80 (or 67). :confused:

[Matthew]

Alphaloop, as you know I think DVD2AVI does not see those 2 frames for purposes of reporting delay.

tateu's post here provides evidence in favour of that, on a technical basis.

http://forum.doom9.org/showthread.php?s=&threadid=30895

Notice that the difference in delay values (+32 and -34) is equal to 2 NTSC frames.

I don't understand it all, but the basic gist of it is that often DVD2AVI does not take into account the first 2 frames when calculating delay. And it appears that in these cases the 2 frames are dropped when re-encoding. So we want to obtain an effective delay equal to that specified by DVD2AVI, not one that is different by -80ms.

Here's 2 cases, one with a delay of +29 and one with -102, both with 2 dropped frames and PAL.

Re-encoded streams treatment:
-----------------------------

1. DVD2AVI should actually report delay as 29+80 = 109ms
But 2 dropped frames after re-encoding means that delay should be reduced by -80 ms also. Result is we want an effective delay of 29ms. Which is what DVD2AVI reported in the first place. So we input that in IFOEdit or drag by that much to the right in Maestro.

2. DVD2AVI should actually report delay as -102+80 = -22ms
But 2 dropped frames after re-encoding means that delay should be reduced by -80 ms also. Result is we want an effective delay of -102ms. Which is what DVD2AVI reported in the first place. So we cut off 4 frames (128ms) and drag by 26ms to the right in Maestro (or simply input -102 ms in IFOEdit).

Unre-encoded streams treatment
------------------------------
1. DVD2AVI should actually report delay as 29+80 = 109ms
So we input that in IFOEdit or drag by that much to the right in Maestro. DVD2AVI would then report +29 ms delay(109-80).

2. DVD2AVI should actually report delay as -102+80 = -22ms
So you'd cut off 1 32 ms frame and then drag it to the right by 10 ms in Maestro. Or just input -22ms in IFOEdit. DVD2AVI would then report your delay as -70ms (10-80, or -102+32) if Maestro were used.

So what I stated originally still seems to hold up in regards to the whole dropped frames thing. If my method is wrong (and it may well be), it's wrong for other reasons :)

[Alphaloop]

Well, Matthew, that provides evidence for my "theories":


(Un-reencoded)
1. DVD2AVI should actually report delay as 29+80 = 109ms
So we input that in IFOEdit or drag by that much to the right in Maestro. DVD2AVI would then report +29 ms delay(109-80).

Adding the 80ms to compensate the 2 frames when auhtoring in IfoEdit. On page 4 of this thread you contradicted. ;)

I already did that (adding 80ms) when trying to sync Lethal Weapon 1. And the result was: perfect sync.

conclusion(?):
When handling unreencoded streams, play around with delay until the final delay dvd2avi reports matches the original delay (should be at least after second try ;) )

When handling with reencoded streams, jsut use the delay dvd2avi reports.

[TRILIGHT]

I've changed the name of this thread to something more appropriate. Too many NTSC users who have no problem at all are becoming confused and subsequently screwing things up that would otherwise have been fine.

[Matthew]

Alphaloop, on page 4 I was referring to re-encoded streams. In that case you wouldn't add the 80ms as it is offset by the 2 frames being dropped ;) With unre-encoded streams I always agreed with inputting the delay into IFOEdit (or Maestro) such that the delay reported by DVD2AVI was the same on the original and remuxed copies. (Hell, I did that on a reauthored DVD-R before this discussion even started). What I disputed was the that 1) the authoring programs were making adjustments equal to two frames (they weren't, it's just that DVD2AVI doesn't include them), and 2) that in the case of re-encoded streams, that a further adjustment had to be made because of the 2 dropped frames (it doesn't as DVD2AVI doesn't factor them in).

TRILIGHT: out of interst, how do you judge whether a release has perfect sync? Using your ears, or DVD2AVI or what? After all, I don't see how timescodes could be retained with NTSC after the video stream is re-encoded.

[Mr Zippy]

I am lost here, what makes you think DVD2AVI does not take account of the two possibled dropped frames when working out the AC3 delay?

The M2V file that is demuxed has no missing frames, and I have explained and posted a link to how DVD2AVI works out AC3 delay.

[Matthew]

Put simply, DVD2AVI takes the PTS value from the first i-frame and then subtracts this from the PTS value for the first audio frame in order to get the delay.

Often the first i-frame is not the first frame in the stream, but rather the third frame. Hence the previous 2 frames are not taken into account by DVD2AVI.

Obviously for encoding purposes the first i-frame is considered the starting point as well, that's why the frames before the first i-frame are dropped.

You can verify this by opening the vob or original video stream in womble mpeg editor. If you drag the slider along it only stops at i-frames. And the first stopping point corresponds to the third frame, in those dropped frame cases ;)

BTW as a side note seems that the timecode in Maestro is taken from the first i-frame, not the first frame in the stream. The timecode in Maestro matches that of the first i-frame (obtained using bitrate viewer), even when the first i-frame is the 3rd frame ;)

[Alphaloop]

Please confirm, whether it's just my narrow statistic, or a real "rule":
Start BitrateViewer, load the Vob, click on GOP.
Movies with the frame issue have the starting GOP like IB... (I frame followed by one/two B frames), movies without the "problem" have the first GOP like IP...(I frame followed by one P frame).

[Matthew]

Well I just tried what you said on a couple of movies, and it appears that what you say is indeed the case. I presume you just see this as a convenient way of detecting whether a film's first i-frame is the third frame?

[Alphaloop]

I presume you just see this as a convenient way of detecting whether a film's first i-frame is the third frame?

If it's not just a statistic error but a real rule of the effect, it would save lot of time, 'cause I (we?) could avoid remultiplexing first chapter with IfoEdit, comparing original and reencoded video with M2Edit (difficult with fade-in starts), or some other games... ;)

[mpucoder]

Something I don't get about this latest:
In DVD every GOP must start with an I frame. Not only must it be first in temporal sequence, but first in the stream. Until an I frame is encountered there is no reference for P or B frames.
Also B frames must be preceeded by two reference frames, usually an I followed by a P. Unless the GOP is "open" those frames will be in the same GOP, encoded before any B frames.
And, finally, the first GOP of a movie should be closed (how can it reference a prior GOP?).
So, how can the first GOP have the sequence "IB..."? That would indeed be a problem for decoding, no forward reference frame.
If this is the case, what you're saying is a large number of PAL movies are being encoded improperly.

Please make sure you are looking at the encoded frame order, it is not the same as the decode order (which is defined by the "temporal sequence number")
Typical encoding is IPBBPBBPBBPBB, but gets decoded as IBBPBBPBBPBBP (temporal sequence 0, 3, 1, 2, 6, 4, 5, 9, 7, 8, 12, 10, 11)

[Matthew]

mpucoder, I can't explain it as we are just looking at what bitrate viewer spits out (only one column called "pictures", and btw the first gop is reported as closed), except I'll just add that there was a case earlier in this thread where Alphaloop had a delay of -67 ms reported on a NTSC title. By my calculations that is 2 NTSC frames, which indicates that the 3rd frame thing (and hence this GOP thing) may not just be a PAL phenomenon.

Alphaloop, that's what I meant. Except I think it is even easier to use womble. Just dragging a vob into womble and using the slider will tell you in under 5 seconds where the first i-frame is. No comparison is necessary =)

edit: can paste results from IFOEdit "check gop structure" if you like, but you'd need to say which boxes to check (just i frames, or i, p and b).

[mpucoder]

You can use VobEdit to see the encoded frame order. If it is IBB... then there aren't many options for handling the 2 B frames. Either remove them, or replicate the previous frame. It sounds like DVD2AVI is dropping them.
I'm curious who is making these DVDs.

Trilight changed this to PAL only, but I'll answer the question about NTSC frames. They are approximately 33.37ms long, but 2 progressive frames (23.976fps) should be displayed as 5 fields (every other progressive frame has the rff flag set if pulldown was down right). That means 2 frames should be 83.4 ms long. Something to watch out for.

[Matthew]

It is indeed IBBP accoridng to vobedit.

[mpucoder]

Ewwww. Can you check the temporal sequence numbers? maybe the encoder put the frames in the wrong order for streaming.

[Matthew]

2, 0, 1, 5, 3, 4, 8, 6, 7, 11, 9, 10

BTW I scrolled right down and repeated this with another random GOP and the numbers/order was the same. Don't know if that means anything.

[mpucoder]

That is really messed up, but dropping frames 0 and 1 is the only thing a decoder can do. So it looks like, for these movies, you're doing the right thing to compensate.
What studio is making these? Maybe it's just one production house or studio.

[Matthew]

2 titles I can mention off hand are Brassed Off and Best in Show (I'm in region 4 BTW).

One is Mirimax, the other is WB/Castlerock.

Another one I had was the Best Bits of the Late Show, which was independently produced.

Doesn't seem to be a pattern there.

[mpucoder]

The PTS value and timecode apply to frame 0 of the GOP (which should be an I frame, but...), which explains why 80ms gets lost for PAL movies like this.
One thing that could be done to preserve the timing is replace frames 0 and 1 with black. Since DVD2AVI is open source, maybe someone could modify it to do this.

[Matthew]

Well having to cut off a couple of frames of audio doesn't do any harm =) Even with that fix, adjustments would need to be made anyway with many films, e.g. on one DVD I had the -96 ms delay would become -16 ms and so it would be necessary to cut one frame of audio and drag to the right by 16 ms.

Just as a postscript: in order to get exact chapters, chapter points as listed by chapterxtractor should be shifted to the left by 2 frames =)

[Alphaloop]

I also tested some with vobedit. Same here, movies without the frme issue have IPxx, movie WITH the frame issue have IBxx.

Which had the issue (tested also dvd library of my neighbor ;) ): 95% of the WB titles, a few Columbia Tristar. Best thing was my cool Devices 3DVD Set: 11 missions all together, 10 are okay (IPxx), one within (mission 9), has "IBB IBBPxxx" (3 pics 1st GOP, then second). nd it's NTSC! :D

But knowing when it happens, and why it happens, is very calmative, 'cause you then know how to bypass sync problems...

[Mr Zippy]

This is really starting to go over my head now.

Maybe someone will write a nice guide to AC3 sync when re-authoring DVDs, am I right in thinking if we can establish the correct audio offset delay then the AC3 Delay Corrector and dragging forward in the timeline is surely the best method. Unless we can find a way to put a start timecode in the AC3 or the authoring program - which I think you can in Scenarist.

[Matthew]

Mr Zippy, the method I outlined would seem to be fine - given that timecodes are disabled, getting the sync right at the beginning is the way to go (like with avi). So there is your guide (my first post in thread).

BTW an alternative to cutting audio with ac3 delay corrector is to insert frames into the re-encoded video stream using m2edit. e.g. for a -102ms movie you could insert 3 frames (120 ms) and then drag to the right in Maestro by 18 ms :) I'll just stick with cutting audio though as it is easier :) Unless perhaps it would be easy to add frames using avisynth, as part of the encoding process.

[Mr Zippy]

I followed that and like the Delay Corrector method, what has lost me is the talk of dropped frames on some movies and the fact that the quoted delay may be incorrect in these cases.

[Matthew]

Well ditching the theory, the practical implications of the dropped frames are usually insigificant. I assume that's what you are concerned about - how it affects what you should do.

Regardless of whether there are dropped frames, when re-encoding the video stream, just rely on the quoted delay. So follow the method as I described early in the thread and it'll work out.

If you are not re-encoding the video stream (a rare event I imagine), then do the following:
-Do a partial mux of the video and audio streams without making any adjustments.
-If DVD2AVI reports a delay of -80ms on the muxed streams then add that to the delay reported on the original DVD. e.g. (1) -80 ms becomes 0ms and e.g. (2) +29ms becomes 109ms and e.g. (3)-100ms becomes -20ms
-In example 1 you'd drag the audio 0ms to the right, i.e. by nothing and according to DVD2AVI the muxed copy would have a delay of 0-80 = -80ms.
-In example 2 you'd drag the audio 109 ms to the right and you'd want DVD2AVI to report a delay 109-80=29 ms.
-In example 3 you'd take your -20ms and make it positive by cutting the the smallest number of frames, i.e. 1. Your delay is now +12 ms. So drag it by that much to the right in Maestro. You want DVD2AVI to report a delay of 12-80 = -68.

Hope that makes sense :)

[Alphaloop]

I play around with unencoded streams, because I reassemble a few series DVDs. So for instance I backup my Cool Devices 3 DVD Set, where I have to reassemble each 4 episodes on one disc (and avoid to split the double episode between two disc like in original), and do that without reencoding.

I continue identifying frame issue movies this way: Rip/Demux video and audio of first chapter, start IfoEdit, Author DVD, select both streams, enter any test delay (+17, -23, what you want). If the final delay which DVD2Avi reports is exactly this value, then no frames are dropped. If the reported delay is 80ms less, then 2 frames got lost, and you have to copensate with 80ms (PAL).

But this is all theory for handling with unreencoded streams. Most time you have reencoded streams, there you just use delay value what DVD2Avi shows of the original vob for reauthoring.

[xkenshin55]

I didn't read through entirely so I'm jumping in to put in my two cents on how i fix desynched audio. I know my method is about divx and wav audio, but it might work with DVD also. I'm learning as much as I can to rip and do some DVD authoring, so.. here's the method I use.

With the Video and Audio, calculate the length of each in ms (milliseconds).

Next, simply do the math. Subtract one from the other and you'll come up with two values, one negative and one positive.

Now, in Maestro, input the value and it SHOULD fix something.

I'm not totally sure this will work. Because it works when I have desynched a divx file and an wav/mp3 file. I do that method I just described and it fixed my problem.

Hope this helped. I knew to DVD authoring so... I only pray this method works! Oh, and isn't there a way to reset all PTS points in the video and audio? I read somewhere in this thread that you can select Maestro to either use the PTS or not.. *shrug*

Kx5

[mpucoder]

OK, seems like I misinterpretted the spec for mpeg2, and so, apparently, did the author of dvd2avi. A closed GOP can indeed have B frames as frame 0 and 1. Take a look at http://forum.doom9.org/showthread.php?s=&threadid=43206

Does anyone know if this has been discussed in the dvd2avi forum? I don't follow it closely.

[Mr Zippy]

Originally posted by Matthew
Regardless of whether there are dropped frames, when re-encoding the video stream, just rely on the quoted delay. So follow the method as I described early in the thread and it'll work out.


Sorry I'm lost, why would I not need to worry about the possible dropped 2 frames if I re-encode?

Surely if the frames have been dropped, then re-encoding will make no difference there will still be a 80ms difference between the corrrect delay, and what you have.

I still maintain if we can either get a timecode based on the orignal PTS into the AC3 file, or specifly the start timecode for the AC3 then there would be no problem.

Keeping the correct timecode is simple for the video if you re-encode, you just enter the start timecode in CCE for example. The only issue would be again whether 2 frames have been dropped or not.

Oh well, I have my DVD Writer now... Hopefully I will not have any sync problems. Although I would like to know any movies I backup are 100% in sync.

It would be nice if someone wrote a guide for AC3 Sync when backing up movies as this seems to be overlooked by all guides I have read.

Also we really need an updated DVD2AVI or a framesever that does not drop frames.

[TRILIGHT]

Originally posted by Mr Zippy
It would be nice if someone wrote a guide for AC3 Sync when backing up movies as this seems to be overlooked by all guides I have read.

I think a great number of us only work with NTSC material and have never had a sync issue. This is probably why you find that no one references it. It's just not an issue for us and we have no way to test. Perhaps you can get with some of your informed PAL colleagues and come up with a solution. Those of us in the NTSC world won't be of much help to you.

[Mr Zippy]

Hopefully more PAL users will be on the scene soon....

[Matthew]

"Sorry I'm lost, why would I not need to worry about the possible dropped 2 frames if I re-encode?

Surely if the frames have been dropped, then re-encoding will make no difference there will still be a 80ms difference between the corrrect delay, and what you have."

Because DVD2AVI does not take account of these 2 frames when calculating delay, they being dropped in the re-encoding process doesn't matter. The 2 effects cancel each other out. i.e. DVD2AVI reports a delay of -80ms when it should report a delay of 0ms. Lets assume for a moment it did report the delay correctly - as 0ms. 2 frames are dropped when re-encoding, meaning that the audio file should start 80ms before the video, i.e. a delay of -80ms. Which is what DVD2AVI does report.

"I still maintain if we can either get a timecode based on the orignal PTS into the AC3 file, or specifly the start timecode for the AC3 then there would be no problem."

You can cross your fingers about that if you like, personally I don't care. Lining up the streams correctly at the beginning will ensure correct sync througout the movie. So what if I have to cut off a couple of blank audio frames at the beginning. If you are worried about that then you should be much more worried about the quality loss associated with re-encoding the video stream.

"Also we really need an updated DVD2AVI or a framesever that does not drop frames."

Yes that would fix the problem. Not that it is a big deal though (although it can be annoying if remuxing re-encoded credits or something like that). You could use REMPEG2 of course ;) Or add 2 black frames after the fact using M2Edit.

Losing a couple of black frames and a couple of blank audio frames at the start of a movie - equivalent to a fraction of a second - is nothing compared to copping a quality hit when re-encoding the video stream.

And I don't understand why this would be a PAL-only issue, hence I'm not convinced that is the case :)

[TRILIGHT]

Originally posted by Matthew
And I don't understand why this would be a PAL-only issue, hence I'm not convinced that is the case :)

I'm pretty convinced. My many backed up DVD's are convinced. Many other NTSC users who have followed the guides seem convinced. hehehe ;) Sucks that PAL users have to deal with it but it sucks for us that NTSC users have to deal with pulldown and drop-frame issues that PAL users do not. Such is the nature of the beast. ;)

[Matthew]

I agree it's good us PAL users don't have to put up with those NTSC issues of pulldown etc :)

But I'd like to see someone check whether 2 frames were dropped on some of their NTSC DVDs (specifically those with negative audio delays). It's not hard to check after all :) There doesn't seem to be any theory as to why this would be only a PAL issue.

And the fact remains that when there is an audio delay, on re-encoded streams the timecode has to be lost. So how can the streams be in sync without user intervention, whether PAL or NTSC.

[benf2]

i would say i can only partialy agree with that statement...i only do ntsc and sometimes i come across an async issue where the audio if fine for the 1st 2/3 of a movie and slowly goes out of sync...i think correcting this is the hardest of all.

[TRILIGHT]

Originally posted by Matthew
So how can the streams be in sync without user intervention, whether PAL or NTSC.

Don't know. It just is...every time. :) I think what it MIGHT be is that the clock is set to all zeros in CCE for the encode. The timecode in the audio files knows to delay by a certain amount from that number so it's always in sync since the audio timecode is never touched.

It also has a bit to do with the framerate I would imagine. I mean, with NTSC material, it is common practice to edit everything using drop-frame timecode. When we author and do the pulldown, setting the drop-frame flag for our video, the clip probably lines up just the way it did originally because the audio was created using drop-frame timecode originally and we made our video drop-frame also after the pulldown to 29.97fps.

From my understanding, PAL users do not even touch their video framerate. Instead they leave it as it is encoded at the FILM framerate. Since your original audio was authored in the process using the *real* PAL framerate of 25fps (I think that's what it is, right?) then when you try to put it together again, it does not match as it did originally. The timecode becomes different and therefore the audio gets out of sync with the video you authored.

As for your concern about 2 frames at the beginning.... I honestly don't know. Perhaps they are there. However, I am more concerned with whether my final product is going to be usable or not. Not whether a frame or two is missing at the very beginning. Afterall, when talking about 30 frames being displayed on the screen every second... I don't think anyone could see whether there were 2 frames there or not at the beginning. I think that works out to be roughly 7 hundredths of a second? Perhaps my audio is off by that much throughout the movie? Maybe. It honestly does not matter to me at all though because I can't tell and I doubt any human could.

[TRILIGHT]

Originally posted by benf2
i would say i can only partialy agree with that statement...i only do ntsc and sometimes i come across an async issue where the audio if fine for the 1st 2/3 of a movie and slowly goes out of sync...i think correcting this is the hardest of all.

What you are describing is a drop-frame problem you set incorrectly. It's the case everytime when things get progressively out of sync since drop-frame is 29.97fps and non-drop is 30fps. Starts off fine...is off by 1 second after 30mins of video....2 seconds by 1 hour of video...etc.

[benf2]

what u say makes sense, i guess somewhere along the line i missed how i would detect that the movie is drop frame...i dont think i have used that setting in cce at all...(i guess its apparent);)

so my question is how do i detect before i encode that i need to ck the box drop frame?

[TRILIGHT]

You must be using a different version of CCE. I encode the video and then use pulldown.exe for performing pulldown and setting the drop-frame flag on the encoded video. Please post in a new post though if you have drop-frame questions, benf2. These guys are trying to figure out their sync problem on PAL stuff and what you're talking about is not applicable.

[Matthew]

Most of what you just said went over my head but maybe that does explain it :) I take it you've obtained the audio delay on the re-authored vobs using DVD2AVI?

In regards to the 2 frame thing, I certainly don't care about the loss of 2 frames per se, but a desync of 80ms (67 ms for NTSC) can be noticeable :)