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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
