A way to find audio delay in AVI?

[absinthe]

I was torn about what forum to post this in, but have opted for the Audio forum.

I gather that when audio and video is "interleaved" in an AVI, it can be done so with a positive or negative audio delay. I think this is what leads to my problem with audio sync after I demux the audio and video for conversion to another format.

I'm wondering if there is a way to find the precise audio delay value (if any) in an AVI before demuxing, say in VirtualDub for instance, in a manner similar to what DVD2AVI reports in a demuxed audio file.

As a subquestion (and this pertains to VirtualDub in particular), I sometimes note when loading an AVI into VirtualDub via an AVISynth script, I will get a black frame with the message "Warning: Nothing to Ouput. BFrame Decoder Lag." This frame can even end up encoded in MPEG2, though it may pass so quickly you don't see it during playback. I'm wondering if that message is a result of a negative audio delay ... i.e. the audio is starting before the video, so there is "no video to decode." ???

It would be terrific if I could figure out the audio delay thing. It would help me immensely ... :D

Thanks,

-abs

[Matthew]

If you are talking about nandub/vdub muxed avis with mp3 audio then this may help:

http://www.yousendit.com/d.aspx?id=4DF9D981E03508B86D1E3E8957456E2C

-Extract program files to directory.
-Open avi in nandub
-Chop off all but first 20 secs or so.
-Use "save wav" and save as audio.mp3
-Save video only (set audio to no audio and video to direct stream copy) as video.avi
-Optional step to ensure success: open audio.mp3 in a hex editor and ensure that structure is as follows. First 58 bytes wave header. Thereafter lots of zeros (no zeros=no delay). After zeros first hex byte should be FF (denotes start of mp3 stream), if there is a tag delete it so that this condition is true and save file.
-Run the bat, wait a couple of mins, and check out the delay.txt

Re the b-frame decoder lag, that is something separate, a result of a setting used when encoding the xvid, you can't do anything about it when re-encoding to mpeg-2, short of replacing frame 0 with frame 1 or something like that. This will do the trick:
AVISource("C:\whatever.avi",false)
FreezeFrame(0,1,1)

If ac3 audio then my post here may be of use:
http://forum.doom9.org/showthread.php?s=&threadid=81670

[alexnoe]

Open the file in AVI-Mux GUI and add it as data source. If the file has a delay (i.e. if a shitty muxing app like NanDub has added crap data instead of audio data), it will try to detect it.

[Matthew]

When did you add that? Wish I'd known about it before writing my tool :p

Incidentally I tested AVIMUX GUI on a nandub file and it was off by a little bit, it said 432 ms but using my (slower, cumbersome, crude) tool result was:

"Start of delay range is 444.
End of delay range is 467.
These values are inclusive."

The "real" delay was 464.

[alexnoe]

How do you know the real delay? Do you hear a delay of 32ms? What did it display as 'bad' value?

[absinthe]

Originally posted by Matthew
[B]If you are talking about nandub/vdub muxed avis with mp3 audio then this may help:

http://www.yousendit.com/d.aspx?id=4DF9D981E03508B86D1E3E8957456E2C

Matthew,

This link doesn't work. Got a fix?

-abs

[Matthew]

The link is fine for me, you just have to click another "download" link on that page (i.e. the link I gave is not a direct link).

Originally posted by alexnoe
How do you know the real delay? Do you hear a delay of 32ms? What did it display as 'bad' value?

I know the real delay because I muxed the test file in nandub myself :) If I didn't (which would be the norm, oviously) then I'd use the midpoint of the delay range (455 or 456 ms).

Do I hear a desync of 32ms? Almost certainly not, I didn't mean to imply that it was that big a deal (I think it's great you've added this feature). But if the audio is little out of sync to begin with it could lead to noticeable desync.

The "bad" value was 432ms, I said that in my previous post :)

[alexnoe]

How do you know that NanDub did what you said?
The "bad" value was 432msthe 'bad' value indicates how many BYTES are crap.

Mh... i hope i didn't forget to make it display the number of bad bytes for AC3 :P
I didn't mean to imply that it was that big a deal (I think it's great you've added this feature).If avi-mux gui reads a wrong delay, then i need to look into this, if the flaw is somewhere else, then i don't need to look into it. And I need to know which of these 2 is the case...

[Matthew]

Well I arbitrarily decided the delay was 464 and inputted it. Now, nandub may indeed not delay it correctly - i.e. instead mux the audio with a lower delay so that the avi is out of sync. But in any event, when finding out what the delay is, I want to know what the delay should have been - not what nandub actually did. So delay detection should ideally account for any flaws in nandub, if you catch my drift :)

AVIMUX GUI says the number of bad bytes is 20736, which corresponds to the number of 0s in the file (after the wave header). So that part is right.

[absinthe]

Well, the AVI-Mux_GUI solution seems to work.

I loaded an already-muxed AVI into VirtualDub, set an audio delay of 1050 ms, then did direct stream copy on audio and video. I loaded my "copied" file into AVI-Mux_GUI and it reported an audio delay of 1049 ms.

That's close enough to do business. :cool:

I hope it's accurate with AC3 as well.

-abs

[Matthew]

mmm...AVIMUX GUI says get 1032 when I use that delay in nandub. This is *vbr* mp3...so that might have something to do with it.

I'd be amazed if AC3 delay detection wasn't perfect, anyone can do that calc easily using besliced, as I explained in the thread I linked. So you can verify it yourself :)

[alexnoe]

AVIMUX GUI says the number of bad bytes is 20736Which is exactly 13,5 frames of 384 kbps AC3 audio = 432 ms.

NanDub fooled you or hid those other 32ms in the dwStart value :)

[Matthew]

I'm confused...what does 384 kbps AC3 have to do with VBR mp3 audio?

[alexnoe]

Nothing. It just worked out from the numbers you gave :D The thing is: a delay of 464ms is absolutely impossible with MP3 :D you can have k*24 ms only for 48 khz, i.e 432, 456, 480, but not 464 ms

On the other hand, half AC3 frames can be applied as delay using the crap byte method. So I thought your file has to be AC3 :p

BTW, 20736 / 1152 * 24 = 432, so 432 is correct for your file.

[Matthew]

heh, well no it isn't AC3...even AVIMUX GUI says it's VBR mp3 :)

Well, lets say for arguments sake I made the avi and used 464 delay as that was the right one. nandub muxes it such that the delay 'crap' consists of 20736 0s. Now, it inserts this same crap this when I use a delay anywhere between 444 and 467 (results are binarily identical). But according to your calcs this junk only translates to 432ms.

Anyway...I did a few tests and it seems that nandub's actual muxed delay may be calculated as follows:

Actual muxed delay=roundeddowntomultipleof24(Inputtedms-12)

e.g. muxed delay=roundeddown(464-12)=432
e.g. muxed delay=roundeddown(1050-12)=1032
e.g. muxed delay=roundeddown(491-12)=456

Now taken your calcs as correct logically an inputted delay of 491 should be translated into 480ms worth of junk...but it it actually leads to only 456ms being inserted (21,888 bytes). 492 ms inputted delay results in 480ms actual delay (23,040).

'reverse engineering' the delay, the formula is:

start of delay range=(junkbytes/48)+12
end of delay range=start of delay range+23

The delay that the user inputted into nandub could fall anywhere in this range. And isn't this the delay we want to find out? Assuming the user inputted the correct delay in the first place.

[alexnoe]

I don't. If the user was happy with the file NanDub created (at least with its sync...), then the delay NanDub has applied can't be too wrong. I just want to find the delay which occurs when playing that file in DirectShow. And that is simply:
24ms per each 1152 bytes or chunk, whatever is less (fractions of 1152 bytes count as full 1152 bytes)

So
1152 bytes = 24 ms delay
1153 bytes = 48 ms delay
2 chunks of 17 bytes each = 48 ms delay
There is nothing inbetween for DirectShow. It just doesn't exist for VBR. Just like being a bit pregnant doesn't exist...

[Matthew]

Well, I suppose it depends on whether the avi was synced manually or according to some other objective means (e.g. DVD source).

If the delay came straight out of DVD2AVI or something like that then nandub's 'bug' (assuming it is a bug) is relevant ;) If the avi was synced manually then you don't want to find out the inputted delay.

Also, when people grab the delay from an avi they are often converting to another format (e.g. DVD-Video) which does allow more preciseness (e.g. to within 2ms) so the 'range' of possible original values does have relevance.

It might warrant a one-line mention in your readme or something, but that's obviously a matter for you ;)

Anyway, thanks, I've learned something through this thread, which is always nice :)

edit: so is the 1152 bytes of junk the same for other sampling rates and all bitrates then. i.e. in *any* mp3,does <=1152 bytes of junk=24 ms?

[alexnoe]

mpeg1 layer3 is 1152
mpeg2 layer3 is 576
44.1 khz -> 26.112 ms

[Matthew]

Ahh....cool...thanks (again) :)

ms interval=48/samplerate*24 is the formula then :)

[alexnoe]

those 1152 or 576 are samples per frame btw

[Bayron]

I know this is an old topic. But I have some AVI movie I want to extract with VIRTUALDUB or VIRTUALDUBMOD or even NANDUB then recode the audio to MP3 with LAME and then REMUX to AVI with VIRTUALDUB. I saw you divided the BAD BYTES from an extracted wav by the FREQUENCY for instance 48000. This gives the correct delay. But for some movies I have to delay it negatively like -200ms, how can I calculate this? And also how do I do this with AC3 audio so it stays in sync.

I also would like to know how you exactly determinate the amount of bad bytes. Because sometimes it isn't a bunch of 0 but sometimes it is a repeating sequence of junk.

And the link in this topic containing more info seams dead. I would just like to know everything you know about getting the audio/video back in sync after extracting it.

I was actually making a program here: http://www.psu.com/forums/showthread.php?p=3869589#post3869589

Regards.

[tebasuna51]

Decompress, add delay and recompress is only a good idea for MP3 VBR, for MP3 CBR and AC3 you can extract the track and use DelayCut to clean the initial garbage (delay) and add a propper delay with silence frames.

I saw you divided the BAD BYTES from an extracted wav by the FREQUENCY for instance 48000. This gives the correct delay.

I can't understand this.
A extracted wav (Direct Stream Copy) is a wav container with the compressed stream (mp3, ac3) inside. If your BAD BYTES is the bytes between the 'data' chunk and the first valid header of the compressed stream then isn't the method to know the delay (see you after).
A decoded wav (Full processing mode -> No compression) can't have BAD BYTES.

When 'Demux' (VirtualDubMod) a audio track without decompress you can know the delay like AVIMuxGUI do:
Delay = Bad_bytes * 8 / BitRate

I don't know avi files with negative delays. At least using VirtualDub/Mod when you put a negative delay the audio stream is cut an discarded, you can't recover the initial audio in the resultant avi.

EDIT: you can use also MediaInfo to know the Delay and eac3to to add the delay without recompress (in 6 sec.):
eac3to v3.12
command line: "D:\Test\eac3to.exe" "D:\Video\tran.mp3"
"D:\Video\tran_delay.mp3" +10512ms
------------------------------------------------------------------------------
MP3, 2.0 channels, 1:46:38, 128kbps, 48khz
Applying MPx delay...
Creating file "D:\Video\tran_delay.mp3"...
eac3to processing took 6 seconds.
Done.

[Bayron]

THX for the info. The only thing I basically want to do is EXTRACT the audio stream, RECODE it, add it back. I want to do this automatically. Therefore I used VCF scripts, this works. All I needed to know was how to find the amount of bad bytes. And if you also had to check bad bytes in the VIDEO part? Because the program listed before here in the thread seems to need the avi file too, but I can't download it anymore as the link seems to be dead.

Actually how do I find the first valid header?

I just want to know how to count the bad bytes, actually how to detect it are bad bytes. Or is there another way to find the delay? I can't use another program as I want to check it myself.

[tebasuna51]

For what recode?
You can add the delay without recode.

And how do you want recode the multichannel ac3?
To stereo mp3?

I say you than MediaInfo can inform you the audio delay in ms:

MediaInfo.exe --Inform=Audio;%Delay% movie.avi

[Bayron]

Ok I might try MediaInfo, the problem is some AVI files don't play on Playstation 3. I found out that if I extracted the AUDIO, reencoded it and then added the audio back, it worked. So I just wanted a way to retreive the amount of bad bytes to know the delay automatically, that's all. Because some files DON'T contain all 0 as bad bytes but stuff added by lame, which repeats itself.

[tebasuna51]

I have the PS3. I know the problem. I read your post, download your soft, read your scripts, test it and ...

- You only need reencode mp3 VBR to CBR but you encode AC3 (even multichannel) and MP3 to MP3 VBR
- You mux MP3 VBR to avi with VirtualDubMod (isn't a good idea)
- Your output files remain with BAD BYTES, check it with AviMuxGUI.

Sorry but there are more clean methods like I say you.

[Bayron]

@tebasuna51 I know but I have one movie that doesn't work without recoding (IE fixing it with AVIMUXGUI doesn't work, but that might be an exception). The PS3 supports VBR MP3. I know I recode AC3 to VBR (I also wanted to fix this). That's because I had a problem with the AUDIO delays.

But I don't understand how AVIMUXGUI fixed bad bytes? I can't seem to find a delay BYTE in the header instead of adding 0?

[tebasuna51]

To make true delay you can add real frames with silence instead garbage.
You can use DelayCut, eac3to, AVIMUXGUI (for some ac3, see ...\silence files subfolder) and also modern VirtualDub (testet with 1.7.7) for mp3.

[Bayron]

OK I'll check this out. You say "and also modern VirtualDub". I have "VirtualDub-1.8.8" atm. Is there an option to do that? FIX bad audio or sthing? Because this seams to screw up most movies on PS3: the bad bytes. I think it works if the bad bytes are divided in sections starting with FF, but if it's just a bunch of 0 at the start, the ps3 won't play it. I also found some more info about MP3 bad data here: http://www.hydrogenaudio.org/forums/index.php?showtopic=69525&pid=616293&st=0&#entry616293 and http://gabriel.mp3-tech.org/mp3infotag.html

[tebasuna51]

OK I'll check this out. You say "and also modern VirtualDub". I have "VirtualDub-1.8.8" atm. Is there an option to do that?
Nope.
You have two problems.
1) Delete the initial bad bytes
2) Insert silence frames to compensate the delay

And I say you how to do:

eac3to bad.mp3 good.mp3 +XXXXms

I also found some more info about MP3 bad data here: http://www.hydrogenaudio.org/forums/index.php?showtopic=69525&pid=616293&st=0&#entry616293 and http://gabriel.mp3-tech.org/mp3infotag.html
This threads isn't related with the problem.
Maybe this 'special', but not bad, frame can cause a delay of 24 ms in some decoders but never reject to play.

You can safely encode mp3 with -t parameter but only CBR, if you want VBR you need this frame.

[Bayron]

Ok thanks for the info on how to legally add a delay. Now one little question. How do I find out how many bytes are bad manually if they aren't zeros but just random junk that constantly repeats? Maybe check how many times the first junk part repeats itself?

[tebasuna51]

Ok thanks for the info on how to legally add a delay. Now one little question. How do I find out how many bytes are bad manually if they aren't zeros but just random junk that constantly repeats? Maybe check how many times the first junk part repeats itself?

You need search the first valid header.

Maybe you can use this: LeeAudBi03b.7z (http://www.sendspace.com/file/q99ok3)
with logs like:
File ........: D:\Test\VideoS\VDPrueba\11 DELAY 1000ms.ac3
Size ........: 3360000 bytes

----------------------------------------- First Frame Info
Bytes before first header ...: 55999 (maybe a delay)
SampleRate ..................: 0 (48000 KHz)
BitRate .....................: 15 (448 Kb/s)
Version (bsid) ..............: 6 (Alternate sintax)
Bit Stream mode (bsmod) .....: 0 (main audio service: complete main, CM)
Audio coding mode (acmod) ...: 7 (3/2 - L, C, R, SL, SR)
Center Mix Level ............: 0 (0.707, -3.0 dB)
Surround Mix Level ..........: 0 (0.707, -3 dB)
Low frequency effects channel: 1 (Present)
Dialogue normalization ......: - 31 dB
...

or
File ........: D:\Test\VideoS\VDPrueba\11.mp3
Size ........: 960000 bytes

----------------------------------------- First Frame Info
Bytes before first header ...: 15744 (delay or ID3v2 tag)
MPEG Audio version ID .......: 3 (MPEG Version 1, ISO/IEC 11172-3)
Layer description ...........: 1 (Layer III)
Protection absent ...........: 1 (Not protected)
BitRate .....................: 9 (128 Kb/s)
SampleRate ..................: 1 (48000 Hz)
...