using ffmpeg to add a delay to an AC3 track

[NikolaiYourin]

Hi all, I'm trying to add a 170ms delay to an AC3 audio track (stereo, 48kHz, 224kbps) using ffmpeg, but neither of the following seems to work:

Method 1: the concat filter (seems preferable, since it does not re-encode the input)

ffmpeg -f lavfi -i "anullsrc=channel_layout=stereo:sample_rate=48000" -b:a 224k -t 170ms silence.ac3

^^ the actual duration is 192ms - the thing seems to think in terms of 32ms chunks, so you can have either 160 or 192ms, but not 170 (32ms is also the shortest possible duration here, which is quite a lot when it comes to audio delays)

ffmpeg -i "concat:silence.ac3|input.ac3" -acodec copy output.ac3

The resulting audio track is just as out of sync with the video as the original one.

Method 2: adelay

ffmpeg -i input.ac3 -af "adelay=170ms:all=true" output.ac3

Doesn't seem to have any effect, it is out of sync again.

***
I must be doing something wrong here, but can't figure out what.

[ProWo]

Try my clever FFmpeg-GUI, Multiplex section. It's easy.

[Selur]

@NikolaiYourin: If you just want a sync output stream you could use 'itsoffset' to delay the video stream. (see: https://www.ffmpeg.org/ffmpeg-all.html#Main-options)
I have used method 1 successfully in the past. What does your muxing call look like? (you did extract the video before and you are try to mux raw streams right?)
@ProWo: Does you gui allow to add silence or does it just add the delay upon muxing using "-itsoffset" ?

[ProWo]

@ProWo: Does you gui allow to add silence or does it just add the delay upon muxing using "-itsoffset" ?

Yes, the muxing delay only

[sekininsha]

I use 'eac3to' in your GUI UsEac3to ... or also 'ffmpeg' in 'a/v recode' button
eac3to:

[Attachment 55524 - Click to enlarge]

ffmpeg: add -af "adelay=160|160"


[Attachment 55525 - Click to enlarge]


[Attachment 55526 - Click to enlarge]

[hello_hello]

sekininsha,
I case you're not aware, and I don't know if all formats are supported this way, but for ac3 sources at least, if you don't specify a bitrate and the output is ac3, eac3to won't re-encode. It'll still add a delay by adding silent audio, but it doesn't re-encode the rest. The main difference is, without re-encoding, the delay can only be applied in increments the size of an audio frame, but it's close enough.

Edit: After posting I realised the bitrate specified in your screenshot was the same as the source bitrate, in which case eac3to shouldn't re-encode (unless you specify other options that force it to).

Without re-encoding:

eac3to v3.34
command line: "C:\MeGUI\tools\eac3to\eac3to.exe" "E:\test.ac3" "E:\testing.ac3" 66ms  
------------------------------------------------------------------------------
AC3, 5.1 channels, 0:21:35, 384kbps, 48kHz, dialnorm: -27dB
Removing AC3 dialog normalization...
Applying (E-)AC3 delay...
A remaining delay of +2ms could not be fixed.
Creating file "E:\testing.ac3"...
eac3to processing took 2 seconds.
Done.

[Attachment 55527 - Click to enlarge]

The same sort of thing applies when extracting audio from a container such as MKV.
I tend to use MeGUI's HD Streams Extractor for that. Eac3to will detect any container audio delay and remove it by adding silence as it extracts. It'll also fix any gaps in the audio stream by adding silence, should there be any.


[Attachment 55528 - Click to enlarge]

[NikolaiYourin]

I have used method 1 successfully in the past.

Well, you would think something this straightforward would work without a hitch.
There is no raw video stream, I was going to fix the audio and then mux it back into the .MKV, but I didn't even get to the muxing stage - a quick check with MPC-HC revealed that the new audio track was out of sync.

ffmpeg: add -af "adelay=160|160"

That is not much different from my original command line #2. I just tried it and it did not seem to delay the audio one bit.

[sneaker]

The resulting audio track is just as out of sync with the video as the original one.

Maybe your assumption about the problem being a constant negative 170ms delay is not correct to begin with?

[sambat]

I found that listing the video file twice on the line got me to understand better what I had to do to get the audio synced with the video.

This file, the audio leads the video (will be applying a 500m/s offset).
With two appearences of the same video on the command line(video 0 and video 1) the offset applies to the file listed after the offset command (in this case file 1)
Muxer uses the video from file 0 (which is simply copied) and the audio from file 1 which now has the offset.


ffmpeg -i bbt.mp4 -itsoffset 0.500 -i bbt.mp4 -vcodec copy -acodec copy -map 0:v -map 1:a output_bbt.mp4

[manono]

I just use DelayCut. It's designed for that and only that.

[NikolaiYourin]

Maybe your assumption about the problem being a constant negative 170ms delay is not correct to begin with?

Maybe something else within the .mkv is at fault here, I don't know what to think anymore. I have four versions of the audio track in question:
- the original built into the .mkv
- one with 192ms of silence prepended to it (ffmpeg / concat)
- another one with 352ms of silence
- and yet another one made with "delaycut -startdelay 192 -same input.ac3"

And the funny thing is that they are all out of sync by the same amount. Setting the delay to -170ms in MPC-HC brings all four of them in perfect sync with the video. Go figure.

[Selur]

In case you did not extract the video stream before muxing, but use the mkv itself it might be a problem with time codes or 'stretch' flags,..

[NikolaiYourin]

In case you did not extract the video stream before muxing, but use the mkv itself it might be a problem with time codes or 'stretch' flags,..

Something must be seriously wrong with that mkv. For the problem to go away, I had to extract all the elementary streams and mux a new mkv from scratch, without touching the original one. And that was enough to fix it - everything is in sync now, with no delays whatsoever.
Thank you all guys, and sorry for the noise.