From 5a8afdb6d5d086797ece57285bcc3534aff1efd5 Mon Sep 17 00:00:00 2001 From: Moritz Bunkus Date: Sat, 27 Jun 2015 15:55:14 +0200 Subject: [PATCH] Updated Delay not shown in mmg (markdown) --- ...-shown-in-mmg.md => Delay-not-shown-in-the-GUI.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) rename Delay-not-shown-in-mmg.md => Delay-not-shown-in-the-GUI.md (50%) diff --git a/Delay-not-shown-in-mmg.md b/Delay-not-shown-in-the-GUI.md similarity index 50% rename from Delay-not-shown-in-mmg.md rename to Delay-not-shown-in-the-GUI.md index 27890f9..3013928 100644 --- a/Delay-not-shown-in-mmg.md +++ b/Delay-not-shown-in-the-GUI.md @@ -1,19 +1,15 @@ -# A delay set in mmg will not show up correctly in mmg or MediaInfo +# A delay set in the GUI will not show up correctly in the GUI or MediaInfo ## The problem -You merge a track with a certain offset/delay. 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. +You merge a track with a certain offset/delay. When you add that muxed file to the GUI again the delay input field is left empty. Similarly MediaInfo may show delay values that are actually different than the ones you've specified. ## Reason This is simply how the Matroska file format works. 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, see below). -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. +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. -As mkvmerge already keeps those timestamps intact when remuxing there's no need to set those 24ms offset when you add that muxed -file to mmg again. In fact it would be wrong and detrimental as then an additional offset of 24ms would be applied. +As mkvmerge already keeps those timestamps intact when remuxing there's no need to set those 24ms offset when you add that muxed file to the GUI again. In fact it would be wrong and detrimental as then an additional offset of 24ms would be applied. Categories: [merging](Category-merging), [metadata](Category-metadata)