[HELP] Hybrid introducing audio delay that is not present in source material

[Selur]

Hurray, going to bed now.

Cu Selur

[4i4oVi40]

@protectron: Going to bed now, send you a new link, which hopefully now includes the correct version.

Cu Selur

Selur,

I'm not sure should I start a new thread but I'm having exactly the same issue. I've just noticed that the last 2 videos I encoded have exactly the same delay of -43 ms.

iId_3_aid_0_lang_fr_DELAY_-43ms_2021-10-10@22_55_44_2910_01.dts
iId_8_aid_2_DELAY_-43ms_2021-10-10@23_19_45_4210_01.dts

It's highly suspicious that both of them have exactly the same delay, which is the same one mentioned in this thread too. In fact, there is no such delay in the MediaInfo or ffprobe info.

I see that you mentioned here that you have a development version version where this issue is resolved. Can I have this version too?

Thanks.

[protectron]

Problem is unless I see no indication of that delay somewhere in the meta data so there sadly isn't anything I can do about that.

Cu Selur

Here is what he said about the delay. 
Is your output file A/V out of sync? 
My situation only seems to stem from an amarectv recording with Lagarith and PCM.
I've been doing other files like MPEG2 DVD to AVC and they're fine, although those also insert a -43ms delay.

[4i4oVi40]

I've been doing other files like MPEG2 DVD to AVC and they're fine, although those also insert a -43ms delay.

Well, doesn't it seem suspicious to you that totally unrelated video sources produce exactly the same delay of -43ms?
This does seem like a bug to me. And I'd like to have solution or at least workaround. Preferably, inside Hybrid.

[Selur]

Does not seem suspicious to me. -43 and -41 ms delays are rather common,..

In fact, there is no such delay in the MediaInfo or ffprobe info.

That seems odd, but without a DebugOutput of the loading/analysis of the source I can't say anything about that.

[4i4oVi40]

Does not seem suspicious to me. -43 and -41 ms delays are rather common,..

In fact, there is no such delay in the MediaInfo or ffprobe info.

That seems odd, but without a DebugOutput of the loading/analysis of the source I can't say anything about that.

Here I'm attaching the DebugOutput file.

On line 7604: Adjusting audio delay from 0 by 43 to -43 due to encoder compensation.

So why is the encoder adding this delay of -43ms? And why is it often (always?) -43ms?

[Selur]

Adjusting audio delay from 0 by 43 to -43 due to encoder compensation.

This happens if you encode to aac.

So why is the encoder adding this delay of -43ms? And why is it often (always?) -43ms?

Different encoders use different sample lenght depending on the channel count, the aac profile and sample rate.
Also deplay is differently compensated by different containers (mp4/mkv) and muxers.
There should be a few discussions about the aac delay over at doom9s and gleitz (german) forum.
I collected all the infos and wrote some code for it ~9 years ago.
If you are interessted I can share the ~200 lines of code which Hybrid uses since then.
I posted a simplified version 7 years ago over at videohelp:

if (heaac) { //HE-AAC
  if (nero) {
    encoderDelay = int(2336 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2585 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
    mkvDelayFix = encoderDelay;
    mkvDelayFix -= int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(794 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  }
} else if (heaacv2) { //HE-AAC V2
  if (nero) {
    encoderDelay = int(2808 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2585 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
    mkvDelayFix = encoderDelay;
    mkvDelayFix -= int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(794 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else { //faac/fdk/...
    encoderDelay = int(2048 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  }
} else {  //AAC LC
  if (nero) {
    encoderDelay = int(2624 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(1600 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else {  //faac/fdk/..
    encoderDelay = int(2048 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  }
}
delay = QString::number(inputDelay - encoderDelay);

see: ]videohelp.com
Side note: That code does not take into consideration that fdk and fhg use different sampleSizes depending on the channel count and how Hybrid would modify the result depending on the used muxer, but it shows the general complexity of the calculation.

-> Since the channel count (usually 2 or 6), the sample rate (usually 48 000Hz) is often the same the delay modifier also often is the same.

Cu Selur

[4i4oVi40]

[quote pid="13798" dateline="1633958768"]
-> Since the channel count (usually 2 or 6), the sample rate (usually 48 000Hz) is often the same the delay modifier also often is the same.
[/quote]

OK, I see. So by default (for faac, fdk, etc.) 2048 Kbps are needed for DTS-HR. And if the SR is 48 kHz (almost always), your delay formula is: 2048/48 + 0.5 ≈ 43 ms.

So this is not a bug but a feature :-) So if I have a DTS at 48 kHz sample rate converted to AAC, I'll always end up with 43 ms delay. I read your thread from 2013 https://forum.videohelp.com/threads/3576...AC-Encoder

Obviously, 43 ms is an offset of just 1 frame, so it's barely humanly possible to discern it. Nevertheless, it's useful to know where this minimal delay comes from and why it's always the same, if you use the same encoder and the same SR.

Thanks for the info.

[Selur]

40ms is one frame with 25fps which some folks notice especially if they are singers and look at themself singing in a video.
Happy the explaination helped to understand what's going on and yes, it's a feature (which like mentioned before can be disabled) not a bug.

Cu Selur

[4i4oVi40]

40ms is one frame with 25fps which some folks notice especially if they are singers and look at themself singing in a video.
Happy the explaination helped to understand what's going on and yes, it's a feature (which like mentioned before can be disabled) not a bug. 

Cu Selur

I'm a filmmaker and a video editor, so I'm also quite obsessed with syncing video and audio to the frame. But I'm also aware that the "normal" people would not care for 1 frame offset