Re-writing audio headers without re-encoding

[mach]

I have an xvid encoded files which appears very blocky and discolored in some places. I opened it up in virtualDub, and got this message:

"VirtualDub has detected an improper VBR audio encoding in the source AVI file and will rewrite the audio header with standard CBR values during processing for better compatibility. This may introduce up to 11243 ms of skew from the video stream. If this is unacceptable, decompress the *entire* audio stream to an uncompressed WAV file and recompress with a constant bitrate encoder. (bitrate: 127.7 +/- 16.1kbps)"

When I play the file the audio is early (really early), so I was wondering if there is any way to re-write the audio header and shift the video back a couple seconds to compensate, all without decompressing and recompressing the entire video.

Thanks

[Matthew]

heh, you'll get that error message with virtualdub and virtualdubmod on any avi that has vbr mp3 audio. virtualdub can't deal with vbr mp3 audio but nandub/virtualdubmod handle it fine (in the latter case you just say no to the warning message).

So if you want to fiddle with the stream use nandub or virtualdubmod (and just say no).

Also, make sure you have the latest xvid codec, it's possible it's just a decoding issue and the xvid itself is fine.

[mach]

I do have the latest version of the divx codec. I figured out that ffdshow uses its own filters to display xvid files, so I set it to use the xvid codec. When I did this, all players would crash when I opened the file.

When I open the file in nandub, I don't get an error, but I can't play the file (it stops after a little bit). In virtual dub I can play the file perfectly (after it re-writes the audio headers), but audio/video is out of sync. So I tried doing a direct stream copy, but it just copied the corrupted video. Is there any way I can extract the good video, so I can combine that with the wav in a matroska container?

[shevegen]

i do have a similar problem, didnt know how to resolve it

did i already ask whether its possible to solve this by using an AVS script?

[mach]

Ok, so I was able to play the file in vidomi player. Here's a quote from the vidomi website:

Should you choose to override the default Lame settings to use VBR/ABR mode, you are committing yourself to using a Video Player that maintains A/V sync by using the playback samplerate. Playing video files with VBR/ABR audio using a video player that maintains sync using the audio bitstreams datarate will result in playback that plays too fast or too slow, and has poor A/V sync.
<snip>
The Vidomi Player maintains A/V sync using the audio samplerate, and correctly plays videos with CBR, ABR, and VBR audio.


However, there was a little bit of noise in the audio that I didn't hear when listening to the wav extracted using virtualdub. Also, the audio was about 11 seconds early, so I used yaai to delay it. The funny thing was that after a while it would get out of sync, but if I paused it and played it, it would be back in sync.

Can anyone explain this?

[stephanV]

the player does its 're-writing' of the audio header on the fly, i guess. if you press stop it can start reading audio at the right point again.

why dont you just mux the whole thing in a better container and get rid of this annoying problem?

[mach]

I tried to transmux it into a matroska container, but it always copied the original (corrupted) video, even though in vdub after rewriting the audio headers the video was fine. How can I make it use the good video?