[time-nuts] Audio format with embedded timestamps?

[Tim Shoppa]

Thank you Chris! The clue in to "BWF" was able to let me Google up some
additional information that taught me more about BWF support in software
like Audacity, and then I found the proposals for BWF and label support in
Audacity with some source code and other tools:

http://wiki.audacityteam.org/wiki/Importing_Timestamp_Information

This appears to be on the development edge of Audacity rather than well
supported.

I have some long (24 hour) WAV files and will see if I can come to any
determination about the offset and spread of the sampling rate. e.g. if the
sampling rate nominally 44100, how precise is that in my PC's hardware? I
would bet this is tied to a crystal in the audio section of the sound card
and thus completely independent of any ntpd stabilatization being done to
the system clock.

I recall that 10ppm over 24 hours works out to 1 second. So if the sound
card crystal is good to 10ppm, that's about a second of drift after a day,
and that's not too horribly incompatible with the 1 second timestamp
resolution at the start of the BWF.

Tim N3QE

On Fri, Dec 2, 2016 at 12:20 PM, Chris Caudle <chris at chriscaudle.org> 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.
>
> --
> Chris Caudle
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>