what's the deal about the "AC3 delay" please ?

[Zetti]

Hi all,

Most of what I do is take already formatted DVD's and rebuild them, say adding my own menus, intro and outro movies, etc, etc - WITHOUT VIDEO REENCODING.

For example, I get lots of stand-alone authored discs and use DVDDecrypter in IFO mode to retrieve the streams, either muxed or demuxed.

As you know, Decrypter creates an information file about the streams, and it indicates the so called "Audio AC3 delay"; what I've been doing is to demux the streams and apply the value indicated by Decrypter at the "AC3 delay corrector" software, so building a "fixed" AC3 stream.

Is it correct ? Am I doing the right thing ?

Why does the delay exist ?

Is it created by the burning software or by the authroring software ?

Why sometimes is the delay zero ?

I'm really confused on that, any help will be very apreciated,

Thanks,

Zetti

[Zetti]

Anyone please ?

Thanks,

Zetti

[awlchu]

I asked the same thing over at mmbforums. A very knowledgeable person responded:

His response:

You have a very good technical question. Generally, this question is about the working priciple of presentation time of video frames vs. audio frames. Before we tag time codes to each video frame and audio frame, we notice that decoder is built to accept frames based on 'time line' concept. The decoding process starts at time 0, or the decoder buffer is totally empty at that time. When the system clock ticks, the decoder buffer is accepting video frames and audio frames. The 'flow rate' of frames entering the buffer is depending on the value called SCR (System Clock Reference) attached to each video pack and audio pack. Each pack has fixed number of video data or audio data. It is not necessary to have one or multiple frames in a pack. A pack can have a fragment of video frame. A video frame is always larger than an audio frame.

Anyway, we have to look at the detail of the decoder buffer. It is the second step to examine the time codes. Each video frame or audio frame has a 'time code' relative to the decoder 'time line. Decoder verifies the frame time code when the frame is stored in the decoder buffer. The decode has one time line system, so video time code and audio time code are based on one system. This makes V/A sync. Decoder decodes both video frame and audio frame at the same time when both video frame time code and audio frame time are due.

If the time code of an audio frame is 'larger' than a video frame, the audio frame will stay in the buffer for longer time. Decoder will decode video frame when its frame time code is due, before it decodes audio frame with larger time code.

In the expanation above, we can find that the speed of decoding frame is totally depending on frame time code. The time code we add to each frame is technically called Presentation Time Stamp (PTS). We can stamp different PTS to video frame or audio frame in the pack so we can have a 'delay' effect.

We also need to watch how long a frame can be stayed in the decoder buffer. Since the decoder buffer size is limited, we have to calculate SCR of video pack and audio pack in order to control the speed of video frames and audio frames 'flowing' into the decoder buffer. In other words, we have to make sure both PTS and SCR of each frame are matching the decoder 'time line' during the moment when the frame is staying in the buffer.

As an end user, we do not need to consider that deep. We only need to set different PTS in the beginning of the audio stream. The built in muxer will do the rest for us. Again, according to DVD Spec, there cannot be any 'gap' in the audio stream flow. The beginning audio PTS will make the delay vs. video PTS for the entire movie. There is no need to have dummy audio frames at the beginning of the audio stream.

For negative audio delay or decoding audio before decoding video at the very beginning of the decoding process, we can tag larger PTS value to the very first I frame of the video stream. When the I frame data stays in the decoder buffer, it will stay there until its PTS is due for decoding. The muxer should be smart enough to delay latter video data going into the buffer to avoid buffer overflow. When decoder has not started decoding, the screen displays nothing. On the other hand, the audio plays.

[Zetti]

Thank you, I'll try to understand it...

Zetti