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

[Stéphane Letz]

Le 22 mai 2010 à 11:49, Jörn Nettingsmeier a écrit :

> 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
> 
AFAICS libsamplerate can use double ratio: see http://www.mega-nerd.com/SRC/api_misc.html

SRC_DATA description.

Stéphane