Synch Audio in DvdMaestro

[nimrodim]

I use the following methods to create DVD's from my AVI's in NTSC.
1. create video stream in CCE.
2. create audio stream in AC3 in soft encode after PAL to NTSC conversion if necessary.

The question is what is the best method to synch the audio with the video in DvdMaestro when using "create synch audio track" in DVDmaestro:
Should i use "Synch to audio time code" or not?

[Matthew]

If I recall correctly "create sync audio" is for concatenating multiple AC3 audio streams, and maybe for cutting them also.

Sync to audio time code, whatever that means, will be useless because you have no useful timecodes in your assets (m2v/ac3).

I just sync using the preview box. If the audio needs to be shifted left then I just cut a second or so off the ac3 using ac3 delay corrector. Then I shift the new audio track right on the timeline until the audio is in sync. If you zoom in to the max you can shift right in 2 milisecond increments. Obviously if the audio needs to be shifted right in the first instance then no cutting is necessary.

If the original avi is in sync, then you shouldn't have sync issues. Any initial delay can be calculated by running the original AC3 through besplit, and noting the framesize value. For example if it says sync found after 5749 bytes and the ac3 is 384 kbps the formula is:

junkbytes/(4*bitrate)*32
=
5749/(4*384)*32=120 ms. To adjust for the framerate change multiply this figure by 25/23.976.

In the case of mp3 audio, every 1152 bytes of junk at the start=24 ms. alexnoe's avimux GUI will tell you the delay if you don't want to do the calcs yourself.

[nimrodim]

I don't understand how you arrived at those formulas - could you explain it?

Also i use virtual Dub for concatenating AC3 or mp3 (for example when joining 2 avi segements of the same film), and then run the audio through besplit. I usually then get 2 instances which inform me of:
"sync found after xxxx bytes" - how would you treat this situation?
This was never really an issue - and i never noticed any out of synch problems.

But still i would like to understand those formulas.
Regarding PAL to NTSC conversions - i use besweet for the audio conversion from 25 to 23.976 "FPS" - but i do seem to think there are more cases of synch problems here.

In DVDMaestro when i use NTSC drop frame - the movie length and Audio length never come out the same - and then i apply the "create sync audio"" - which seems to change the length of the AC3 produced by a few milliseconds to get it closer to the Video length.

[Matthew]

An AC3 file is made up of frames, each being 32 ms. The size of each frame depends on the bitrate. It's 4 x bitrate. So each frame is a 448 kbps AC3 is (448*4)=1792 bytes. or 896 bytes for a 224 kbps AC3.

Now, there's no such thing as partial AC3 frames in DVD, but AVIs can include them (or even full junk frames that are just 0s) - in order to maintain audio sync (they can't be decoded AFAIK). So when you re-encode the source AC3 or even just fix it, these junk bytes are deleted, and sync relative to the avi is lost. Besplit tells you how many bytes are deleted at the start of the AC3, and you can use that to calculate the equivalent number of AC3 frames and multiply that by the frame length (32 ms). That's what the formula is about, if that makes sense :)

AFAIK concatenating mp3 avis should not be an issue as far as join-point sync goes, but it's not uncommon for nandub/vdubmod to split avis badly. In theory, they should be split so that the partial frame at the end of CD1 can be rejoined with the partial frame at the start of CD2, however sometimes the same byte(s) appear in both partial frames, or sometimes bytes are missing from both partial frames. The result is a corrupt joined AC3 stream - it will either be less than the framesize (usually 1792 bytes) or more. Besplit will fix this by deleting the badly rejoined frame - the result being 32 ms desync (which shouldn't be noticeable) versus the original source.

Anyway, "stream found after :032" relates to junk data/partial frame at the start of the AC3. The second error would be at the join point I presume. You shouldn't often get errors anywhere else.

I've used besweet (and softencode) for 23.976->25 fps *a lot* and certainly had no noticeable sync problems with that. I have done a couple of 25->23.976 in the past and also noticed no sync problems.

The length issue in Maestro that you mention sounds familiar, if memory serves it's just a GUI issue and nothing more. If you place the audio and video on the timeline and zoom to the end, the lengths should match up fairly well (sometimes the lengths differ to begin with).

[nimrodim]

Sorry for being so daft/stupid but i still don't get it fully:

For example - an ac3 stream from concatenating 2 parts of a film (448 kbit/second).
After joining the audio and running it through besplit i get:

[00:00:00:032] Stream error : Sync found after 58 bytes
[00:55:21:056] Stream error : Sync found after 1863 bytes

First is junk and also should be insignificant as:
58/(4*448)*32=1 Millisecond.

The second might be the join:
1863/(4*448)*32=33 Milliseconds.

Both together are insignificant.

Lets assume they were significant - would I join these sums together before shifting the audio?
Lets assume only the second one was significant - it tells us that from point [00:55:21:056] we have a 32ms synch problem. - shifting the audio only changes the point where desynch occures...you would have to shift the audio at point [00:55:21:056] to get the right correction.

[Matthew]

In your position I'm sure I wouldn't get it fully either ;)

ooops forgot about the wav header.

I use virtualdubmod to "demux" the audio.

But nandub (or vdubmod's "save wave") adds a 58 byte wav header to the start of the ac3, so you need to minus that in any delay calculation. So in this case the "delay bytes" is 0. i.e. no delay.

Re the join point error to get the ideal sync you either A) delete the extra bytes (~70) in a hex editor from either the start of CD2 or the end of CD1, then join and test with besplit; or B) join CD1 + 1 frame dummy + CD2 and then fix with besplit. If option A fails for some reason then you must use B.

BTW I'm assuming that no video frames are missing or duplicated between the 2 avis, i.e. that the video (and hence the audio, in theory) is a perfect match at the join :)

[nimrodim]

Thanks for the info...! :D
It is insignificant as i showed before - so the i am willing to do without the "perfect" synch.
You said the 58 byte synch is just junk - and besplit removes it...ie. this is no delay. - so i don't have to worry about that.

The second point is a join point...is odd...if it is only one frame it should be 4*448=1792 bytes not 1863 as i got.

What does one frame of sound actually mean?

Why would 70 bytes deleted - be the right amount if it is one frame which is 1792 bytes?

How would you go about doing option B?

[Matthew]

To clarify the join point thing, the length of a video frame (say 40 ms for PAL) and the length of an AC3 audio frame (always 32 ms) don't match up, so usually when you cut at the end of a video frame, you are left with part of an audio frame only.

So a single 1792 byte AC3 frame gets chopped in 2 when you split the avi. In a perfect world, CD1 might get 536 bytes of this frame and CD2 will get 1256 (1792=536+1256). So when the avis are rejoined, the AC3 frame at the join point is reconstructed properly and everything is all fine and dandy.

However, what happens fairly often (for reasons I don't know), CD1 might get 545 bytes and CD2 1256. 545+1256=1801. So the same (nine) bytes have been included in both frames. Besplit doesn't look for this, it just says "corrupt frame" and deletes the bitch. But you, being a smartipants, can extract the individual AC3s, delete these 9 bytes from one of the AC3s and then join them yourself.

In your case beplit is telling you the corrupt frame is 1864 bytes (besplit's stream error understates the corruption by one byte). So that means there is 1864-1792=72 overlapping bytes that you need to delete.

Note that if instead the corruption bytes figure is less than 1792 this means that bytes are missing - and there's nothing you can do about it except use a dummy (silent) frame to maintain sync.

I just remembered that jsoto's delaycut supports replacing bad frames with silence, so that should do the trick for option B.

[nimrodim]

What does Besplit actually do?
Does it delete the whole frame - i.e. 1863 bytes or just the extra bytes?
If it delets the whole frame that means i have a 32 ms delay...which is earlier to the video.
If it deletes only the extra bytes - there should be no problem.

[Matthew]

"Besplit doesn't look for this, it just says "corrupt frame" and deletes the bitch."

i.e. it just deletes the whole frame.

[nimrodim]

any chance besplit will be updated to deleteing just the extra bytes or padding when bytes are missing...

[Matthew]

Updating to support padding (insertion of silent frames) is a possibility I suppose - delaycut does it (and it has cli).

But deleting the extra bytes...I say no chance. It's not really within the scope of what besplit does.