Delay Question?

[DelBoy83]

I was just wondering how the Delay on audio works i have a PCM audio track which has a -66ms value. When demuxed with the latest eac3to their is no mention of any delay in the log so i'm wondering how dgdemux managed to get a delay of -66ms?

[Curly]

eac3to corrects the delay by adding/removing audio frames whereas DGDemux does not.

[DelBoy83]

Hi Curly, I understand that eac3to automatically corrects the delay but the log shows no sign of any delay correction. DGdemux however shows a delay of -66ms when demuxed.

[Curly]

Correctamundo. Do you need me to do something? If so, please explain the value.

[DelBoy83]

I'm not asking you to do something, I was just wondering why dgdemux would give a -66ms Delay and eac3to/makemkv doesn't show any sign of delay for the audio? I'm not sure that a -66ms delay would be noticeable anyway but I thought I'd ask.

[von Suppé]

I was just wondering why dgdemux would give a -66ms Delay and eac3to/makemkv doesn't show any sign of delay for the audio?

My apologies for chiming in somewhat late.
Matroska container can't carry a negative audio-delay. When a negative audio-delay value is entered in MKVToolNix it will remove audioframes , just like eac3to does. In case of certain codecs - eg. TrueHD - even a residual positive delay may be applied by MTX since on not every audioframe can be cut.

[Curly]

I'm not asking you to do something, I was just wondering why dgdemux would give a -66ms Delay and eac3to/makemkv doesn't show any sign of delay for the audio? I'm not sure that a -66ms delay would be noticeable anyway but I thought I'd ask.

It's cool Mr DelBoy83. It's just different philosophies for the two apps. eac3to removes starting audio frames so that there is no longer an audio delay. And BTW, most competent authorities (including me, wise guys) accept 20-25 milliseconds as the minimum perceptible desync. DirecTV specs 20 milliseconds to settop box makers. DG knows all about those famous flash-pop streams!

Marking resolved.