shithub: libsamplerate

Info  •  Files  •  Log  •  Branches

Update FAQ with Q/A on lossi-ness of resampling process.

--- a/doc/faq.html

+++ b/doc/faq.html

@@ -63,7 +63,10 @@

 	than its input?</A><BR><BR>

 <A HREF="#Q002">Q2 : On Unix/Linux/MacOSX, what is the best way of detecting

 	the presence and location of libsamplerate and its header file using

-	autoconf?</A><BR>

+	autoconf?</A><BR><BR>

+<A HREF="#Q003">Q3 : If I upsample and downsample to the original rate, for

+	example 44.1->96->44.1, do I get an identical signal as the one before the

+	up/down resampling?</A><BR><BR>

 <HR>

 </P>

 <!-- ========================================================================= -->

@@ -151,6 +154,31 @@

         Pkgconfig directory : ......... /usr/local/lib/pkgconfig

 </pre>

+

+<!-- ========================================================================= -->

+<A NAME="Q003"></A>

+<H2><BR><B>Q3 : If I upsample and downsample to the original rate, for

+	example 44.1->96->44.1, do I get an identical signal as the one before the

+	up/down resampling?</B></H2>

+<P>

+The short answer is that for the general case, no, you don't.

+The long answer is that for some signals, with some converters, you will

+get very, very close.

+</P>

+<P>

+In order to resample correctly (ie using the <B>SRC_SINC_*</B> converters,

+filtering needs to be applied, regardless of whether its upsampling or 

+downsampling.

+This filter needs to attenuate all frequencis above 0.5 times the minimum of

+the source and desination sample rate (call this fshmin).

+Since the filter is has to achieve full attemuation at this point, it has to

+start rolling off a some point before this point. Its this rolloff of the very

+highest frequencies which causes some of the loss.

+</P>

+<P>

+The other factor is that the filter itself can introduce transient artifacts

+which causes the output to be different to the input.

+</P>

 <!-- <A HREF="mailto:[email protected]">For the spam bots</A> -->