precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...
22 May
2010
22 May
'10
11:49 a.m.
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
22 May
22 May
12:35 p.m.
New subject: precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...
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
12:38 p.m.
Jörn Nettingsmeier wrote:
unfortunately, both zita-resampler and libsamplerate
seem to represent
the sample rate ratio internally as a fraction of two integers,
I haven't looked at the code for zita-resampler but for libsamplerate,
what you said above, is not correct.
Sepcifically :
a) The API has an src_ratio field which is of type double floating
point. Thats how you chose your resampling ratio.
b) Internally, the time distance between samples is also calcutated
in double floating point.
The only place integers are used for time offsets is in the calculation
of the indices into the filter table and the interpolation between two
adjacent values in the table.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
12:47 p.m.
On 05/22/2010 12:38 PM, Erik de Castro Lopo wrote:
Jörn Nettingsmeier wrote:
that's good to know!
unfortunately, both zita-resampler and
libsamplerate seem to represent
the sample rate ratio internally as a fraction of two integers,
I haven't looked at the code for zita-resampler but for libsamplerate,
what you said above, is not correct. Sepcifically :
a) The API has an src_ratio field which is of type double floating
point. Thats how you chose your resampling ratio.
i found that. but when i'm trying with sndfile-resample (using the -by
parameter), i get an integer target sample rate (or at least, that's
what the output claims), which is what confused me. plus it seems that
the target sample rate in the SRC structure is an int, not a double, so
i don't understand how arbitrary ratios could be represented...
b) Internally, the time distance between samples is
also calcutated
in double floating point.
great. so it looks like a minor hack to sndfile-resample to get what i want.
best,
jörn
6:04 p.m.
On Sat, May 22, 2010 at 12:47:10PM +0200, Jörn Nettingsmeier wrote:
i found that. but when i'm trying with
sndfile-resample (using the -by
parameter), i get an integer target sample rate (or at least, that's
what the output claims), which is what confused me. plus it seems that
the target sample rate in the SRC structure is an int, not a double, so
i don't understand how arbitrary ratios could be represented...
If sndfile-resample allows you to specifiy an integer ratio,
try 266037 / 265982.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
23 May
23 May
12:52 a.m.
Jörn Nettingsmeier wrote:
I really don't think any modification is necessary.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
i found that. but when i'm trying with
sndfile-resample (using the -by
parameter), i get an integer target sample rate (or at least, that's
what the output claims),
Thats a limitation of libsndfile, not libsamplerate. libsndfile only
allows integer samplerates. Of all the sound file formats libsndfile
supports, only AIFF supports floating point sample rates.
which is what confused me. plus it seems that
the target sample rate in the SRC structure is an int, not a double, so
i don't understand how arbitrary ratios could be represented...
In sndfile-resample.c :
else if (strcmp (argv [k], "-by") == 0)
{ k ++ ;
src_ratio = atof (argv [k]) ;
}
and that value is passed unmolested to libsamplerate.
However, the samplerate of the output file is still an integer.
b)
Internally, the time distance between samples is also calcutated
in double floating point.
great. so it looks like a minor hack to sndfile-resample to get what i want.
10:51 a.m.
On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de Castro Lopo wrote:
I really don't think any modification is
necessary.
At least one: the sample rate value in the header must
remain the same.
The 'canonical' way to obtain the required result would
be to modify the input file's header to reflect the real
(and wrong) samplerate before it is resampled, then resample
it to the exact required rate.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
11:20 a.m.
fons(a)kokkinizita.net wrote:
On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de
Castro Lopo wrote:
sndfile-resample accepts a:
-by <ratio>
command line option where <ratio> is given as a floating
point value.
After the conversion is done, the sample rate in the destination
file's header.
I really don't think any modification is
necessary.
At least one: the sample rate value in the header must
remain the same. The 'canonical' way to obtain the required
result would
be to modify the input file's header to reflect the real
(and wrong) samplerate before it is resampled, then resample
it to the exact required rate.
Probably easier to fix the desination file.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
1:47 p.m.
On 05/23/2010 11:20 AM, Erik de Castro Lopo wrote:
fons(a)kokkinizita.net wrote:
yes, that's what i've used in the end. but as i said in another posting,
i've been confused about it, because the ratio is displayed rounded to 6
decimals, and the apparent target rate is an integer (i.e. the number
that ends up in the target header), even though the real sample rate is
the desired fractional value.
On Sun, May 23, 2010 at 08:52:16AM +1000, Erik de
Castro Lopo wrote:
sndfile-resample accepts a:
-by <ratio>
command line option where <ratio> is given as a floating
point value. I really don't think any modification is
necessary.
At least one: the sample rate value in the header must
remain the same. After the conversion is done, the sample rate in the
destination
file's header.
yep. sndfile-convert -override-sample-rate=44100 in.wav out.wav
did the trick for me.
best,
jörn
The 'canonical' way to obtain the
required result would
be to modify the input file's header to reflect the real
(and wrong) samplerate before it is resampled, then resample
it to the exact required rate.
Probably easier to fix the desination file. 
22 May
22 May
1:54 p.m.
On Sat, 22 May 2010, Erik de Castro Lopo wrote:
Jörn Nettingsmeier wrote:
It /is/ true for zita-resampler:
Libzita-resampler does not provide dynamically variable
resampling ratios, and requires the ratio F_out / F_in
to be ≤ 16 and reducible to the form b / a with a,
b integer, and b ≤ 1000. This includes all th
e 'standard' ratios, e.g. 96000 / 44100 = 320 / 147.[1]
Elsewhere, I think it's also stated that the intended
purpose was high-performance conversion between standard
audio sampling rates.
-gabriel
[1] http://www.kokkinizita.net/linuxaudio/zita-resampler/resampler.html
unfortunately, both zita-resampler and
libsamplerate seem to represent
the sample rate ratio internally as a fraction of two integers,
I haven't looked at the code for zita-resampler but for libsamplerate,
what you said above, is not correct.
2:49 p.m.
On 05/22/2010 12:38 PM, Erik de Castro Lopo wrote:
Jörn Nettingsmeier wrote:
sorry, i have now found the reasons for my confusion:
the console output of sndfile-resample contains a ratio in double, but
uses the default formatting of six decimals. however, the internal
precision is higher.
furthermore, sndfile-resample prints the source and target sampling
rates. however, these values are taken from libsndfile information (i.e.
the headers of the input and output files). in this context, sample
rates are limited to integers, so libsamplerate chooses the nearest
integer value to set the target sample rate in the output file header.
i found that this has nothing to do with the internal SRC state, which
is solely governed by the ratio (in double precision), not the source
and target sample rates.
sorry again for the noise, and thanks for all the helpful comments!
best,
jörn
unfortunately, both zita-resampler and
libsamplerate seem to represent
the sample rate ratio internally as a fraction of two integers,
I haven't looked at the code for zita-resampler but for libsamplerate,
what you said above, is not correct.
Sepcifically :
a) The API has an src_ratio field which is of type double floating
point. Thats how you chose your resampling ratio.
b) Internally, the time distance between samples is also calcutated
in double floating point.
The only place integers are used for time offsets is in the calculation
of the indices into the filter table and the interpolation between two
adjacent values in the table.
10:24 p.m.
On Sat, May 22, 2010 at 11:49:55AM +0200, Jörn Nettingsmeier wrote:
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?
AFAIK, the secret rabbit will do any double rate.
For zita-resampler there is a technical reason: I want to
avoid having to interpolate filter coefficients, so all of
them are precomputed. The number of coefficient sets required
in that case is b, where b/a = fs_out/fs_in reduced to the
smallest possible integer ratio. For that reason the value
of b is limited to 1000. This covers all 'common' cases.
In fact it covers 'almost all' ratios with a relative
precision of around 1e-6. For example 355/113 = pi with
a relative error smaller than 1e-7.
Future version of zita-resampler may implement arbitrary
resample ratios, either by interpolating, or more likely
by finding two such small approximations and dithering
between them, or by using a special algorithm for near-
integer ratios.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
5295
days inactive
5296
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
5 participants
participants (5)
-
Erik de Castro Lopo -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Jörn Nettingsmeier -
Stéphane Letz