[Matroska-devel] RFC 80085 - Required TimecodeScale for sample accurate seeking

Paul Bryson paul at msn.com
Tue Jan 20 21:01:07 CET 2004

Status of this Memo

   This document specifies system whereby a system of rounding is specified so
as to maximize the possible TimecodeScale for efficient usage.


This document only applies to cases where a precise audio sample is required,
all other situations where the required seeking accuracy of a stream is less
than 0.5ms should ignore this document.

This has been touched on briefly before, but it needs to be finalized so that we
can add it to the specs.

When storing timecodes for an audio stream, the TimecodeScale must have an
accuracy of at least twice that of audio samplerate, otherwise there are
rounding errors that prevent you from knowing the precise location of a sample.
As was mentioned once (by Tronic I think), if you specify which direction to
round in each case, then you can decrease the TimecodeScale to the same level of
accuracy of the audio samplerate, allowing you to double your possible Cluster
size.  This also becomes useful for cases where you have a TimecodeScale of 1ms,
and you have very small audio packet sizes.

So, we just need to specify which way to round for all cases.

For instance, if the first sample of an audio packet is sample 13,824 in an
audio stream with a samplerate of 44100Hz, then your time in nanoseconds will be
(13824 / 44100) * 1000000000 = ~313469387ns

Twice the accuracy of the samplerate would be
(1 / 88200) * 1000000000 = ~11338ns
Which only gives us a maximum possible Cluster size of 743047168ns, or 0.7
seconds.  By matching the accuracy we could get a full 1.4 seconds in a cluster,
significant decreasing overhead.  But doing this, we reach rounding errors.

Matching the accuracy of the samplerate would be
(1 / 88200) * 1000000000 = ~22676ns

To store the above audio packet using a TimecodeScale of 22676, you would use:
3213061224 / 2276 = 13768.5856

So, do you store the timecode as 13768 or 13769?


More information about the Matroska-devel mailing list