* a
protocol that encodes time information in an audio stream
* a format for specifying time (HH:MM:SS:FF)
Except for video editors, the HH:MM:SS:FF format is completely
irrelevant. Just think seconds. What the time code does is to
define a relation between a transport position in seconds and a
particular sample. Once you have this mapping, the format of
the timecode does not matter at all.
wrong scenario. suppose i want to store the point
in time where (say)
a zero crossing happens. SMPTE will not allow me to do that. i have to
store it as a sample position.
Again, why use the HH:MM:SS:FF format ? If you divide the 'sample
position' by the sample rate, you get a time in seconds. Conversely,
given a time in seconds, you can find the sample. This has nothing to
do with SMPTE or any other particular time code format.
For JACK I'd rather work with samples. And, as you say, this can
easily be converted to seconds dividing by the nominal sample rate.
If for a SMPTE synced JACK we would have the SMPTE frames mapped to
samples in the transport info I think everybody would be happy.
--ms