[LAD] interesting blog post about syncing blender and ardour

Fons Adriaensen fons at kokkinizita.net
Mon Sep 21 22:41:13 UTC 2009


On Mon, Sep 21, 2009 at 05:51:23PM -0400, Paul Davis wrote:
> On Mon, Sep 21, 2009 at 12:36 PM, Fons Adriaensen <fons at kokkinizita.net> wrote:
> > On Mon, Sep 21, 2009 at 08:18:00AM -0400, Paul Davis wrote:
> >
> >> SMPTE is a low resolution time code. There is no reason to be limited
> >> by frame rates of 30 fps when defining a synchronization protocol
> >> between applications running on the same (or even two networked)
> >> computer(s). JACK transport is sample-accurate, and as such is
> >> thousands of times more accurate than SMPTE.
> >
> > While I'd agree 100% that SMPTE is not what's needed here,
> > your comments on its potential accuracy are misleading.
> >
> > The *data* contained in the SMPTE timecode is quantised
> > to frames. But SMPTE is not just that data. It is data
> > encoded into an audio signal, and this can be resolved
> > to sub-microsecond accuracy.
> 
> when rolling, sure. i'm thinking about a locate command.

Locating (while stopped) is a remote control function, which
is not the same as syncing. SMPTE in itself does not support
anything similar to a locate command, it's not a remote control
protocol but just an audio signal that can be decoded to time.

SMPTE was developed as a way to sync audio (on magnetic tape)
to optical film, and later to video. It was also used to sync
audio tape machines, e.g. two 24-tracks recorders, to each other.
In all cases the essential trick was to record it on tape as an
audio track, thereby creating a time reference that was physically
bound to the real audio tracks on the same tape. Sort of 'soft'
sprocket holes, with the extra that each such hole also was also
labeled with its number.

Most machines supporting SMPTE sync would also support locating,
by combining conventional mechanical tape motion sensing with
the timecode system, and in the sense that when the master started
rolling the slaves would chase to approximately the same location,
then start rolling, then sync accurately. This latter could take
some seconds, but once sync was established it could be very
accurate, actually better than a sample at 48 Khz. 

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.




More information about the Linux-audio-dev mailing list