remove gst-libs from gst-plugins module as it is in gst-plugins-base now

Original commit message from CVS:
remove gst-libs from gst-plugins module as it is in gst-plugins-base now

1 files changed, 0 insertions, 62 deletions

diff --git a/gst-libs/gst/resample/README b/gst-libs/gst/resample/README
deleted file mode 100644
index f7db1105..00000000
--- a/gst-libs/gst/resample/README
+++ /dev/null
@@ -1,62 +0,0 @@
-
-This is a snapshot of my current work developing an audio
-resampling library.  While working on this library, I started
-writing lots of general purpose functions that should really
-be part of a larger library.  Rather than have a constantly
-changing library, and since the current code is capable, I
-decided to freeze this codebase for use with gstreamer, and
-move active development of the code elsewhere.
-
-The algorithm used is based on Shannon's theorem, which says
-that you can recreate an input signal from equidistant samples
-using a sin(x)/x filter; thus, you can create new samples from
-the regenerated input signal.  Since sin(x)/x is expensive to
-evaluate, an interpolated lookup table is used.  Also, a
-windowing function (1-x^2)^2 is used, which aids the convergence
-of sin(x)/x for lower frequencies at the expense of higher.
-
-There is one tunable parameter, which is the filter length.
-Longer filter lengths are obviously slower, but more accurate.
-There's not much reason to use a filter length longer than 64,
-since other approximations start to dominate.  Filter lengths
-as short as 8 are audially acceptable, but should not be
-considered for serious work.
-
-Performance:  A PowerPC G4 at 400 Mhz can resample 2 audio
-channels at almost 10x speed with a filter length of 64, without
-using Altivec extensions.  (My goal was 10x speed, which I almost
-reached.  Maybe later.)
-
-Limitations: Currently only supports streams in the form of
-interleaved signed 16-bit samples.
-
-The test.c program is a simple regression test.  It creates a
-test input pattern (1 sec at 48 khz) that is a frequency ramp
-from 0 to 24000 hz, and then converts it to 44100 hz using a
-filter length of 64.  It then compares the result to the same
-pattern generated at 44100 hz, and outputs the result to the
-file "out".
-
-A graph of the correct output should have field 2 and field 4
-almost equal (plus/minus 1) up to about sample 40000 (which
-corresponds to 20 khz), and then field 2 should be close to 0
-above that.  Running the test program will print to stdout
-something like the following:
-
-  time 0.112526
-  average error 10k=0.4105 22k=639.34
-
-The average error is RMS error over the range [0-10khz] and
-[0-22khz], and is expressed in sample values, for an input
-amplitude of 16000.  Note that RMS errors below 1.0 can't
-really be compared, but basically this shows that below
-10 khz, the resampler is nearly perfect.  Most of the error
-is concentrated above 20 khz.
-
-If the average error is significantly larger after modifying
-the code, it's probably not good.
-
-
-
-dave...
-