[time-nuts] Audio format with embedded timestamps?

jimlux jimlux at earthlink.net
Fri Dec 2 14:01:59 EST 2016

On 12/2/16 9:20 AM, Chris Caudle wrote:
> On Thu, December 1, 2016 8:19 am, Tim Shoppa wrote:
>> Is there a common digital audio format that embeds in the digital
>> stream, a timestamp marker of real-world-clock-time that the
>> audio was recorded at?
>> At my "day job" we have many digital "system of record" phone and radio
>> recording systems. The best they do, is to timestamp the filenames they
>> generate with the start time.
> You mention timestamping files, and also digital stream.  Are you looking
> for a transport protocol, or a file format?
> For a file format, Broadcast WAV described in EBU tech report 3285 has a
> field for origination time, with a resolution of 1 second, and a time
> reference which as I understand is the location of the first sample
> referred to the previous midnight given in sample position as a 64 bit
> number.
> Presumably this give some ambiguity of the location of the ending samples
> based on the accuracy of the sample clock originally used to capture the
> samples.
> If you need transport time stamps, then the audio-over-IP protocols use
> PTP as the reference clock, so you get explicit description of the audio
> sample location referenced to the PTP epoch.

If you want to get away from existing "audio" formats (realistically, 
SMPTE/AES/EBU would be a better choice in your business, though), you 
can also look at VITA-49 Virtual Radio Transport (VRT)- it's a format 
for digitized samples from a radio with explicit time tags in the 
messages - the field is 2 32 bit words, seconds and picoseconds. 
Although I know the latter would not be sufficient for some time-nuts, 
but there is a provision for user defined extension fields in periodic 
context packets where you could provide clock offsets and calibration 

If anyone needs it, I've got python and Matlab/Octave code to read and 
decode VRT format files, although I don't support ALL possible sample 
encodings.  The standard contemplates all sorts of strange packing and 
formats - I do signed 16 bit and signed 24 bit.

In any case, it's a lightweight protocol - the header is as short as 4 
32 bit words (header word, stream id, time coarse, time fine) followed 
by however long your data packet is. And you can leave out stream id or 
time if you like.

More information about the time-nuts mailing list