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
_______________________________________________
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:02 2010
This archive was generated by hypermail 2.1.8 : Sat May 22 2010 - 16:15:02 EEST