Lacing leads to incorrect timestamps
Created by: mkver
Hello,
there is a bug in which lacing can lead to incorrect timestamps. I noticed the issue during appending of two audio streams with a delay and in such situations it probably happens often. File 1.mka has an ac3-track and two frames of 32ms audio, starting at zero. These two frames are of course laced together. 2.mka has 30 frames of 32ms; of course, they are laced. If I append 2.mka to 1.mka with a delay of 20ms, the resulting file 1+2.mka looks as expected:
Cluster-Zeitstempel: 0.000s an 5415
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 2 Bild(er), Zeitstempel 0.000s = 00:00:00.000) an 5418
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.084s = 00:00:00.084) an 9010
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.340s = 00:00:00.340) an 23354
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 3 Bild(er), Zeitstempel 0.596s = 00:00:00.596) an 37698
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
|+ Cluster an 43082
| + Cluster-Zeitstempel: 0.692s an 43089
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.692s = 00:00:00.692) an 43093
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 3 Bild(er), Zeitstempel 0.948s = 00:00:00.948) an 57437
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
|+
But if I remux this file again (without using any of the advanced options of mkvmerge; I just used the default options), the resulting file 1+2 (1).mka is wrong:
Cluster an 5408
| + Cluster-Zeitstempel: 0.000s an 5415
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.000s = 00:00:00.000) an 5418
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.276s = 00:00:00.276) an 19762
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 5 Bild(er), Zeitstempel 0.532s = 00:00:00.532) an 34106
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
|+ Cluster an 43074
| + Cluster-Zeitstempel: 0.692s an 43081
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.692s = 00:00:00.692) an 43085
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 3 Bild(er), Zeitstempel 0.948s = 00:00:00.948) an 57429
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
|+
The gap has moved from 64ms-84ms to 256ms-276ms. If I remux 1+2.mka with the "--disable-lacing"-parameter, the file (1+2 (2).mka) does not loose sync. But if I remux this file again with default values (i.e. with lacing enabled), the file 1+2 (2) (1).mka has the same timecodes as the 1+2 (1).mka, i.e. whether the source file is laced or not is irrelevant. Unfortunately there doesn't seem to be an easy workaround, because version 2 of the timecodes (which can be extracted with mkvextract) don't include the duration of the frames. But I realized this a bit late and nevertheless did it and found two issues:
If I extract the timecodes from 1+2.mka (called 1+2.txt), I get the following file:
# timecode format v2
0
32
83.994624
115.994624
147.994624
179.994624
211.994624
243.994624
275.994624
307.994624
339.999072
371.999072
403.999072
435.999072
467.999072
499.999072
531.999072
563.999072
596.00352
628.00352
660.00352
692.018208
724.018208
756.018208
788.018208
820.018208
852.018208
884.018208
916.018208
948.001824
980.001824
1012.001824
1044.001824
I presume that the usage of non-integral numbers emanates from the fact that the "Zeitstempelskalierungsfaktor" (time stamps scaling factor?) is 20832 (both files 1.mka and 2.mka originate from an ac3-file merged and cut with mkvmerge and mkvmerge chose this value out of its own). But I have choosen a delay of exactly 20ms -- shouldn't mkvmerge take this value into account when deciding which Zeitstempelskalierungsfaktor to choose and choose one so that the delay is really 20ms and not only approximately 20ms? And why is not only gap not an integral number, but the durations of the frames itself (the 32ms should be exact of I am not mistaken)? (I thought that the Zeitstempelskalierungsfaktor has been choosen in such a way to represent the durations using integral numbers.) If I now remux 1+2.mka with the timestamps from the above file, I get the following file:
Cluster an 5408
| + Cluster-Zeitstempel: 0.000s an 5415
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 1 Bild(er), Zeitstempel 0.000s = 00:00:00.000) an 5418
| + Bild mit Größe 1792
| + Blockgruppe an 7217
| + Block (Spurnummer 1, 8 Bild(er), Zeitstempel 0.032s = 00:00:00.032) an 7220
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Blockdauer: 276.003168ms an 21564
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 8 Bild(er), Zeitstempel 0.308s = 00:00:00.308) an 21568
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 3 Bild(er), Zeitstempel 0.564s = 00:00:00.564) an 35912
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Blockgruppe an 41296
| + Block (Spurnummer 1, 1 Bild(er), Zeitstempel 0.660s = 00:00:00.660) an 41299
| + Bild mit Größe 1792
| + Blockdauer: 32.018784ms an 43098
|+ Cluster an 43102
| + Cluster-Zeitstempel: 0.692s an 43109
| + SimpleBlock (Schlüsselbild, Spur Nummer 1, 7 Bild(er), Zeitstempel 0.692s = 00:00:00.692) an 43113
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Blockgruppe an 55665
| + Block (Spurnummer 1, 4 Bild(er), Zeitstempel 0.916s = 00:00:00.916) an 55668
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
| + Bild mit Größe 1792
|+
This time there is no gap at all any more; instead eight frames of audio are stretched (if the player honors the mkv-specification). But according to the specification of the timecode file version 2, the second frame of audio should be the only one to be stretched (to 51.994624 ms). This is exactly what happens if I disable lacing and remux using this timecode file. So this is another instance in which lacing is buggy. Sorry for writing such a long post.
Grüße Andi
PS: In trying to find a workaround, I tried timecodes version 3; but the documentation is a bit too terse for me. E.g. the following timecode file does not work:
# timecode format v3
Assume 0.0
0.064
gap, 0.020
0.960
What's wrong with it? And do you know another workaround for this problem until you fix this bug? My only workaround so far is to split the audio into pieces and then merge again with the right amount of delay.