[time-nuts] Audio format with embedded timestamps?

[jimlux]

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 
factors.

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.