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
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
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
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
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
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Linux-audio-dev mailing list