Use a video codec in a container to record your audio?

On 01/12/2016 9:19 AM, Tim Shoppa wrote:

I think you have answered your own question.  Use SMPTE.  The video
container file can hold audio.

One other idea:  Use a stereo audio format and record your audio to one
track and a time code (like IRIG) on the other track.  IRIG works even on
analog multitrack tape recorders.  Use it the same way on digital
multitrack recordings.  Google IRIG Time Code.

On Thu, Dec 1, 2016 at 6:19 AM, Tim Shoppa tshoppa@gmail.com wrote:

--

Chris Albertson
Redondo Beach, California

On Thu, December 1, 2016 8:19 am, Tim Shoppa wrote:

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

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@chriscaudle.org wrote:

On 12/2/16 9:20 AM, Chris Caudle wrote:

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.

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@gmail.com wrote:

--

Chris Albertson
Redondo Beach, California

On 12/2/2016 8:01 PM, jimlux wrote:

That would be useful to me, thanks. Please send the code to i2phd (at) weaksignals.com
or you can of course place it in a publicly accessible repository.

TNX

73  Alberto  I2PHD