[time-nuts] Timestamps in audio files?

[Magnus Danielson]

Jim,

On 12/21/2015 04:22 PM, Jim Lux wrote:
> On 12/21/15 3:19 AM, Tim Shoppa wrote:
>> As an adjunct to the thread about timestamped samples of LORAN
>> transmissions...
>>
>> Are there any standard consumer-type audio file formats, that support
>> absolute time time/datestamps? Would not have to be done continuously,
>> but
>> something like a time and date stamp inserted nearest each sample on a
>> second boundary.
>>
>> I have worked with some analog tape audio formats in the past where
>> IRIG-type timestamps were written on a separate channel or on a
>> subcarrier.
>>
>> I know of many proprietary digital recording applications that make WAV's
>> or MP3's or proprietary codec formats, where the filename includes a
>> timestamp. Much more interested in standard formats where the
>> timestamp is
>> embedded in the file itself.
>>
>
> For RF recordings, VITA49 has a standard for timestamps in the packet
> headers (4 flavors of epoch, multiple flavors of time format and precision)
>
> Video file formats seem to draw from older time code things like SMPTE
> and are "relative" (so you're always fooling around trying to figure out
> the offsets).  I spent a few days earlier this year trying to put
> absolute time subtitles on video files using all manner of tools, and it
> was frustrating (ffmpeg, vlc, etc.. all were to no avail).  Trying to
> put UTC time into embedded timecode was also pretty unproductive (most
> tools don't like to see the first frame occurring at a time very
> different from 00:00:00:00)
>
>
> In fact, in the music file world (e.g. MIDI) you see references to
> absolute and relative time, and there, they are really talking about
> time measured in seconds vs time measured in beats; e.g. whether the
> duration of something  is 1 second, or 2 quarter notes, which might be
> the same if the tempo is 120bpm.
>
>
> You might look for solutions for people trying to synchronize multiple
> multimedia streams delivered over the internet (e.g. slides and
> accompanying narration or music) because they actually have a need for
> "show this slide at time HH:MM:SS and play this sound at HH:MM:SS" kind
> of synchronization.
>
> I suspect, though, that this kind of info gets encapsulated in the
> transport layer, rather than the underlying files holding the info.

The time-code (SMPTE 12M), often referred to as LTC or VITC, often 
accompany the media. However, it's a relative timing and really not an 
absolute timing. This means that initial delays and processing delays is 
not being captured. Lip-sync is being monitored and re-established using 
delays. Lip-sync is easily lost these days, as apparent regularly.

With the SMPTE 2059-1 and 2059-2, such time may have an improved 
connection to normal wall-time, but still no real handling of delays.

Cheers,
Magnus