You are correct about the sample rate being tied to the crystal on the
audio interface. But some audio interferes used in recording studios
have a way to use a centralized bit rate clock. That clock is distributed
to all the audio interfaces to keep them bit synchronized. Not everyone
uses this. Maybe most don't because not everyone things in matters. But
these do exist and the clocks, I've seem clocks with Rubidium oscillators
inside. So if you do need an auto interface who's sample rate in "time nuts
accurate" you can buy them off the shelf. Quite a few of them do accept an
external clock
On Fri, Dec 2, 2016 at 10:02 AM, Tim Shoppa <tshoppa at gmail.com> wrote:
> 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.
> >
> _______________________________________________
> 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.
>
--
Chris Albertson
Redondo Beach, California