I need to correct audio drift

[Djard]

I have a video project where the audio stream is 240 ms longer than the video. So, if I understand correctly, the audio will gradually be delayed, more and more. Right?

So I demuxed the AVI file and tried to use Audacity to speed up the audio, figuring I won't need to drop the sound pitch; since the amount truncated is so small. But I can't find in Audacity a way to pre-determine how much I need to speed up the audio stream; so that the audio is truncated by exactly 240 ms.

Is there a way to do this with VirtualDub or Audacity, or do I need yet another app?

[hech54]

VirtualDub - Audio - Interleaving - Audio Skew Correction......IF the skew is constant.

[davexnet]

You should check the file carefully by eye/ear to see if it starts off in sync at the beginning and drifts out the further on it gets.
If it gradually gets worse, use Audacity/effect /change tempo. Set the new length (in seconds)

On the other hand, if it's out the same amount all through the file, follow hech54's advice.

[jagabo]

Audio and video within a file don't have to be the same length. And they don't have to start at the same time. You have to verify by eye and ear whether the audio or video needs to be adjusted.

[Djard]

Thanks for the valuable info.

[Cornucopia]

You don't say anything about the overall length. I mean, are you talking about 5 minutes or 100 minutes?
And when that is compared to 240ms (which is, after all, less than a second), it makes me wonder what you're worried about.
If there was lipsync involved that would be one thing...

The thing is that it isn't anywhere clear here that the audio MUST equal the video length. If you know that to be true, then you have the choice of:
1. Truncate/crop the end of the audio
2. Time compress the audio to make it the exact length as the video
3. Adjust either the framerate of the video (down) or the samplerate of the audio (up) to bring the counting of their timebases in sync with each other.

Scott

[Djard]

Thanks Scott,

Upon further examination, I notice the AV sync in my current project not only gradually drifts (starts OK then towards the end of the 60 min. video the asynchrony is noticeable, looking at the lips), but it also slightly shifts in and out every few seconds. My guess is that within each GOP (300) there is a problem. Do I need to add a few B frames?

[poisondeathray]

Upon further examination, I notice the AV sync in my current project not only gradually drifts (starts OK then towards the end of the 60 min. video the asynchrony is noticeable, looking at the lips), but it also slightly shifts in and out every few seconds. My guess is that within each GOP (300) there is a problem. Do I need to add a few B frames?

You can't just "add a few B-frames"

What is the source from ? What format? Is it in sync to begin with? If it's in and out of sync every few seconds, I suspect that it's a VFR source . The solution, if you are not editing, would be to mux in VFR timecodes . If you are editing, then you probably have to attempt a CFR conversion

[Djard]

XMedia Recode offers a field where you can type in a number for B frames, so I assumed that it was possible to add B-frames, which some sources comment is undesirable. I thought B-frames were parts of the I-frame that had changed. Obviously I need to learn a lot more about this subject.

The source of my problematic video is a music lesson I got from a teaching site on the Internet. No support is available. The format is AVI. It starts out in sync then by the end of the 16 minute clip the audio lags behind by about 250 ms, enough to be noticeable. Maybe my copy of MPC is defective becasue I was not able to replicate the subtle shift in what appeared to be every few seconds at about the middle of the video, which I suspected was a bad compilation of GOPs. I tried recoding the clip, but the audio drift remains.

If it's not a complex process, I'd be grateful for some guidance in how I could go about muxing in VFR timecodes and attempting CFR conversion. Or maybe there are some tools you could recommend.

[poisondeathray]

AVI doesn't support VFR, so it can't be VFR

If it was a teaching site, often their videos are flv - those are often VFR . I assumed the "AVI" you talked about was an export from an editor or software

How does it play in a different media player? try kmplayer or vlc ?

The number of b-frames is for re-encoding and specifies the maximum number of consecutive b-frames ; you don't just "add b-frames" , and it won't help your issues here

It starts out in sync then by the end of the 16 minute clip the audio lags behind by about 250 ms, enough to be noticeable.

If it's progressively worsening then just match the lengths up (either video FPS or audio length) , but you previously described it as going in /out of sync? which is it ?

If the AVI was derived from a VFR source, that could be one explaination your observations . You would need to get timecodes from the VFR source.

[jagabo]

Just to clarify:

I frames encode the entire picture, much like a JPEG image.

P frames encode only the changes from a prior picture. In a talking head shot with a static background a P frame can say "this frame is the same as the last one, just change these parts (the speaker's head and lips)..."

B frames are like P frames but they are Bi-directionally encoded, meaning they can reference both prior and later frames. They can say "copy these parts of that earlier frame, copy these parts of that later frame, then make these additional changes..." In theory that allows for even more compression. But in my experience the bi-directional encoding gives you very little additional compression with most material. The main reason B frames reduce the overall bitrate is that they are encoded with a lower quality. The reasoning is that you won't notice a few low quality frames because the picture will soon get cleaned up by a P or I frame.

So in a sequence like IBBP the P frame references only the preceding I frame, the two B frames can reference the I frame, the P frame or both (and with some codecs even other B frames). The decoder first decodes the I frame, then decodes the P frame, then the two B frames. In a 30 fps video those two low quality B frames account for 2/30 of a second. Hopefully that's not long enough for you to notice the lower quality with most material. But if you used more consecutive be frames, say IBBBBBBBBP, those B frames account for 8/30 (about 1/4) of a second. That may be enough that you can see the picture quality strobing. A clean frame, the picture degrades for a quarter second, then the picture suddenly clears up, then it degrades for another 1/4 second, etc.

You must also be careful about what your target player supports. With larger numbers of B frames the decoder will need more memory and more processing power. For example, DVD only allows up to 2 consecutive B frames.

[Djard]

I read at one of the video guru websites that the ideal GOP is 15 frames. But I notice when using VD that most video files have only one (I) keyframe about every 275 frames. I apologize if I have misunderstood what I have read, but I'm hungry to learn. I'll study the kind responses I've received and hopefully communicate my needs mre intelligently in the future.

The video file with the audio drift not only gradually drifts out of sync but it also goes in and out of sync every few seconds at about the middle. Seems some of the folks who make these videos know as much about encoding as I do. My guess is that they disregard I-frames when editing out leaders.

[Cornucopia]

The ideal GOP length is as long as necessary for bitrate reasons, but as short as necessary for quality & compatibility reasons.
IIRC, for DVD MPEG2, there is a spec-legal maximum GOP length of 18 for NTSC (15 being probably most common) and 15 for PAL (12 being probably most common). Those common ones are worked out as fitting nicely at (or nearly at) 1/2 second increments.
For HDV MPEG2, the GOP length is 6. (Important to be lower for easier facility with editing).
MPEG4part2 (e.g. Xvid, DivX) and WMV often get by with MUCH more (yet still retaining good quality), and I would guess (though I haven't tested this) that Mpeg4part10 (aka h264/AVC) can get by with even more still.

However, there are LOTS of media on the internet encoded by people who don't understand the frametype intricacies mentioned by jagabo above (though I have to disagree about B-frames being useless/lowquality), and I've seen so many that are encoded with GOP lengths of >300frames. Invariably with files of those type you will find seeking problems, quality degradation and A/V sync problems - just as you've already noticed. Whether they "edit leaders" or not, they certainly do disregard encoding more frequent I- or P-frames, to their detriment.

Scott

[Djard]

Thanks. I'm getting an appreciation for encoding video files. It seems to me that video editing is more complex than website building.