How do you find out true audio delay value in mkv?

[trumpet205]

According to this,

When you add that muxed file to mmg again the delay input field is left empty. Similarly MediaInfo may show delay values that are actually different than the ones you've specified. A delay you enter is not stored in some header field. Instead all the timestamps are modified by that value. So if that leads to whole packets being dropped you might even see totally confusing values reported from tools like MediaInfo (which isn't a bug in those tools either...

Let's take an AC3 track for example. Those often have packets with a duration of 32ms. Now if you offset that by -40ms mkvmerge subtracts those 40ms from all timestamps. The very first two timestamps would then be at -40ms and -8ms; however, Matroska doesn't allow negative timestamps. Therefore the first two packets will be dropped. The new first packet is the old third packet at the new timestamp 24ms (old timestamp 64ms, subtract delay 40ms = 24ms). MediaInfo would then report a positive offset of 24ms.

Source: https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg

Delay relative to video shown under Mediainfo is merely the first postive timestamp after it was adjusted with delay value. Since mkv doesn't allow negative timestamp, how do I find out the true audio delay value?

There is an option with mkvextract that allows me to extract timecode_v2, would it be possible to tell actual delay vaule from that?

[Deleted User 11865]

In the example above, the actual delay would be 24ms - the two first AC-3 packets were dropped (poof, gone), so you're left with 24ms of silence (delay) and then the first audio packet.

[trumpet205]

But is it permantly dropped, even when you demux the audio file?

I have a mkv file ripped by MakeMKV that has a positlve delay of 792 ms. I demux the FLAC and use Audacity to manually add 792 ms of silence to the beginning of audio tracks. Mux it back with mkvmerge with 0 ms of delay and it is synced with video. It looks to me that when you demux it timestamp is returned to normal?

[Deleted User 11865]

But is it permantly dropped, even when you demux the audio file?

Yes. Dropped means dropped, not skipped (AFAIK, there is no "skip X packets flag in Matroska, so a "soft drop" is impossible).

I have a mkv file ripped by MakeMKV that has a positlve delay of 792 ms. I demux the FLAC and use Audacity to manually add 792 ms of silence to the beginning of audio tracks. Mux it back with mkvmerge with 0 ms of delay and it is synced with video. It looks to me that when you demux it timestamp is returned to normal?

That is correct. Raw audio streams usually have no timestamps, so the initial delay as well as any other delays are actually forgotten when demuxing.

So you have:

1) extracted FLAC stream, first packet starts at time 0, the rest is continuous

2) re-encoded stream with 792ms of silence prepended

3) remux with +0ms delay - the first packets from (1) starts at 179ms only because of (2)

You should also note, that if there non-encoded silence in the middle of the file (which I've seen on some BD special with seamless branching, from e.g. the Dark Knight, IIRC), demuxing to a raw stream will lose this, so A/V sync will be lost.

The workaround is to extract a timecode file for the track you're demuxing and use it when remuxing. So you'd do

1) mkvextract tracks TID:some_file.flac

2) mkvextract timecodes_v2 TID:some_file.txt

3) Audacity prepend +AAAms new_file.flac

4) mkvmerge -o outfile.mkv [other options and tracks] --timecodes 0:some_file.txt --sync 0:-AAA new_file.flac [other tracks]

The timecode file will re-introduce delays present in the source MKV file, but the sync option will offset all timestamps by the amount of silence you prepended using Audacity, so that the first audio timestamp will be +0ms.