[LAD] interesting blog post about syncing blender and ardour

[Fons Adriaensen]

On Fri, Sep 25, 2009 at 01:25:50PM -0400, Paul Davis wrote:

> eh? lots of people are using ardour as a playback engine driven by
> timecode, with no intention of recording the output. when you're
> editing and scrubbing/shuttling, i would have imagined that in the
> vast majority of cases you would *not* be recording what you are
> doing. what am i missing?

You wouldn't care about quality while scrubbing/shuttling. But
if the resampling is done to keep in sync with something that
is not locked to your sample clock, it does matter. 

> the code i wrote to do varispeed-sync-tracking was designed to handle
> a "wobbly" timecode source such as an ADAT tape machine. its timecode
> speed is not constant but suffers from very small motor-induced
> variation. from the experiments i did, that variation is essentially
> random, and if you played the same material twice, it would be subject
> to two different sets of timecode variations. i cannot see how
> encoding the varispeed into the on-disk material is useful in this
> case.
> 
> are you talking about something different?

Not really. Suppose you have to do this:

1. copy an audio track from a video recording,
2. do some work on it, 
3. copy the result back to the video recording.

Your (nominal) sample rate is 48k, the video is
exactly 100s long when played at the exact frame
rate.

If the the clock used by the video equipment and your
sample clock are not coherent (not derived from the
same source), there will be a relative error between
them, both in steps 1 and 3. 

Assume that in step 1 the video is running at 99%
of its nominal speed (w.r.t. your sample rate). So
it will take 101,01010101 seconds instead of 100.
That means that you need to resample to 0.99 * 48k
in order to get exactly 4800000 samples in your
recording.

WHy is this required ? Because any resampling done
in step 3 (playback) will only compensate for the
relative speed errors at that time. Suppose that
there is no relative speed error in step 3. Then
clearly your recording must have exactly 4800000
samples in order to stay in sync. 

Returning to the 'quality' point: clearly it does
not matter in step 2. And maybe you could even do
step 2 without the video and not resample at all
during this phase.

But it does matter in steps 1. and 3. as these are
in the path to the final result.

To keep things simple I've assumed constant relative
speed errors. The situation is just the same if there
is some variation (wobbling) during the length of the
track.

Ciao,

-- 
FA

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