[LAD] precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...

From: Jörn Nettingsmeier <nettings@email-addr-hidden-hochschule.de>
Date: Sat May 22 2010 - 12:49:55 EEST

hi *!

i need to re-synchronize two recordings of the same event that for
technical reasons had to be done with unsynchronized clocks. i'm
assuming for the sake of sanity that both clocks were perfectly stable.

my approach is this: in ardour, align some unique feature (a click in
this case) at the very beginning of the recordings to within a few
samples. set a mark1. then, identify another unique feature close to the
end, set mark2 to its position in the reference clock file and mark3 in
the file that needs to be resampled. read the frame positions or the
markers from session.ardour.

sample rate ratio is then

  (mark2 - mark1) / (mark3 - mark1).

i compute a value of precisely 1.00020678091, and i'm now looking for a
resampler that will do the right thing here.

unfortunately, both zita-resampler and libsamplerate seem to represent
the sample rate ratio internally as a fraction of two integers, which
means that in my case, it will be rounded to 44100/44107. this is not
acceptable for the usecase at hand, as the offset after 4 hours of
recording would be too large. due to the massive amount of data to be
processed, slicing the material into smaller chunks to reduce the error
is not an option.

is there a hard technical reason for the behaviour of the resamplers?
would it make sense for this bear of very little brain to dig into the
code and try to convince them to perform resampling at ratios with full
double precision, or is such an undertaking bound to fail?

thanks,

jörn

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat May 22 16:15:01 2010

This archive was generated by hypermail 2.1.8 : Sat May 22 2010 - 16:15:02 EEST