[Matroska-devel] Re: Timestamp precision in matroska files

[Steve Lhomme]

Christian HJ Wiesner wrote:

> Steve Lhomme wrote:
> There is one flaw in this example :
> 
> The only purpose of the timestamp accuracy is to allow to determine a 
> specific sample in a block by the timestamp attached to the start of the 
> block.
> 
> 1 / 44100 =  22,6 µs , means every single sample is 22,6 µs long , or    
> Ts ( duration of each sample ) = 22,6 µs
> 
> So, the minimal required accuracy to determine a specific sample from a 
> timestamp is  1/2 Ts = 11,3 µs
> 
> So, if your timestamp is accurate to 10 µs or less, you can say with 
> 100% certainty what sample you have to load, by using rounding. 
> Remember, we dont need the starting timestamp of this one sample with a 
> precision of 0,5 ns , all we need to know is, if we have a timestamp  
> xxxx , what sample corresponds to it.

Ah !!! Finally someone with a real good explanation.

You're totally right.

There is still the rounding problem. If your timecode scale is 11,338 ns 
(10^9/(2*44100) = 11,337.868480725623582766439909297)

Here is a table corresponding to the Sample #, tick #, reconstituted 
timecode , real timecode

1       0           0            0
2       2      22,676       22,676
3       4      45,352       45,351
4       6      68,028       68,028
5       8      90,704       90,703
6      10     113,380      113,379
...
999  2000  22,676,000   22,675,737
1000 2002  22,698,676   22,698,413
1001 2004  22,721,352   22,721,088

You see that there is a difference of 264ns every 1,000 samples. So 
after 100,000 samples (2.5s) there is 26,400ns or 2 ticks or 1 sample !!
You lose the sample accuracy using timecode after just 2s.

But hopefully, reality is a bit better. The timecode for an audio track 
can be expressed in float :
TimecodeScale (integer) * TrackTimecodeScale (float) * Timecode

So if you have :
TimecodeScale      = 1,000,000
TrackTimecodeScale = 0,022675736961
Timecode           = X

And the approximation of the float will hopefully avoid the rounding 
problem.

I'll make a little C program to verify (with C double float) at what 
"tick" the reconstitued timecode is too different that the real timecode 
(different by more than half of the duration of a sample).