I have an mkv file that has the following for an audio stream:
Audio #1
ID : 1
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Codec ID : A_EAC3
Duration : 45 min 8 s
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : 16 s 0 ms
Stream size : 82.7 MiB (2%)
Language : French
Service kind : Complete Main
Default : Yes
Forced : No
The section I am curious about is the delay relative to video. I have trimmed out the first 16 seconds by re-encoding the video using ffmpeg, but if I use the original file as a source for the audio it still adds a 16s delay to the new file.
How do I copy the audio from the original file but exclude the delay? When I load the file in mkvmerge it does not show a delay of 16000ms in the GUI for this track that I can clear. So I am wondering if there is a setting somewhere else that I am meant to be clearing so it doesn’t copy the delay?
There’s an FAQ entry about this topic that roughly explains why this happens as it does. Please take a look at it. If it’s still unclear to you afterwards, just ask again.
Okay, thanks. That helps explain why the delay/offset isn’t shown in the GUI but I am still a little bit confused about the best way to copy over the audio track without copying over the 16s delay as well.
Is it better if I demux the audio track and add that back into the GUI or would adding a -16000ms delay using the original file achieve the same result?
Both should be roughly equivalent. Extracting always loses the timecode information, therefore the initial delay will be lost as well. The drawback is that any potential gap in somewhere in the middle would also be lost. Such (short) gaps might be created when appending two or more files. Apart from that they’re still possible but encountered rarely.
The alternative is to try to specify a negative delay of the same amount that the first audio packet is offset relatively to the first video packet. Ideally you should not just use whatever MediaInfo shows but examine the timecodes yourself, e.g. with mkvinfo -s yourfile.mkv, as I’m not sure if MediaInfo rounds somewhere. This is important as using too big a negative value would result in the first audio frame having a negative timecode, and packets with negative timecodes are simply dropped during remux — meaning you could lose one or more audio packets if you’re not careful & input wrong values. The advantage is that the timecode information of all frames is kept intact (with your offset applied, of course), meaning the gap situation mentioned above would not be an issue.
Okay, so assuming I am interpreting this output correctly it looks like data for track 1 (the track with a delay) does indeed start at exactly 16s. So it looks like I can use an exact offset of -16000ms if I want to use the original file.
