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)
^^ 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)Code:ffmpeg -f lavfi -i "anullsrc=channel_layout=stereo:sample_rate=48000" -b:a 224k -t 170ms silence.ac3
The resulting audio track is just as out of sync with the video as the original one.Code:ffmpeg -i "concat:silence.ac3|input.ac3" -acodec copy output.ac3
Method 2: adelay
Doesn't seem to have any effect, it is out of sync again.Code:ffmpeg -i input.ac3 -af "adelay=170ms:all=true" output.ac3
I must be doing something wrong here, but can't figure out what.
+ Reply to Thread
Results 1 to 13 of 13
@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" ?users currently on my ignore list: deadrats, Stears555
Last edited by sekininsha; 15th Oct 2020 at 19:03.責任者
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).
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]
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.
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
- 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.
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,..users currently on my ignore list: deadrats, Stears555
Thank you all guys, and sorry for the noise.