Mercurial > hg > qm-vamp-plugins

--- a/plugins/ChromagramPlugin.cpp	Thu Nov 20 16:55:27 2008 +0000
+++ b/plugins/ChromagramPlugin.cpp	Tue Nov 25 12:55:00 2008 +0000
@@ -243,6 +243,10 @@
     if (m_chromagram) {
 	delete m_chromagram;
 	m_chromagram = new Chromagram(m_config);
+        for (int i = 0; i < m_config.BPO; ++i) {
+            m_binsums[i] = 0.0;
+        }
+        m_count = 0;
     }
 }
--- a/plugins/ConstantQSpectrogram.cpp	Thu Nov 20 16:55:27 2008 +0000
+++ b/plugins/ConstantQSpectrogram.cpp	Tue Nov 25 12:55:00 2008 +0000
@@ -236,6 +236,10 @@
     if (m_cq) {
 	delete m_cq;
 	m_cq = new ConstantQ(m_config);
+        m_bins = m_cq->getK();
+        m_cq->sparsekernel();
+        m_step = m_cq->gethop();
+        m_block = m_cq->getfftlength();
     }
 }

@@ -276,7 +280,7 @@
     d.hasFixedBinCount = true;
     d.binCount = m_bins;

-//    std::cerr << "Bin count " << d.binCount << std::endl;
+    std::cerr << "Bin count " << d.binCount << std::endl;

     const char *names[] =
 	{ "C", "C#", "D", "D#", "E", "F", "F#", "G", "G#", "A", "A#", "B" };
@@ -339,11 +343,13 @@
     double *cqre = new double[m_bins];
     double *cqim = new double[m_bins];

+//    std::cout << "in:" << std::endl;
     for (size_t i = 0; i <= m_block/2; ++i) {
 	real[i] = inputBuffers[0][i*2];
 	if (i > 0) real[m_block - i] = real[i];
         imag[i] = inputBuffers[0][i*2+1];
         if (i > 0) imag[m_block - i] = imag[i];
+//        std::cout << real[i] << "," << imag[i] << " ";
     }

     m_cq->process(real, imag, cqre, cqim);
@@ -351,14 +357,17 @@
     delete[] real;
     delete[] imag;

+//    std::cout << "\nout:" << std::endl;
     Feature feature;
     feature.hasTimestamp = false;
     for (int i = 0; i < m_bins; ++i) {
         double re = cqre[i];
         double im = cqim[i];
+//        std::cout << re << "," << im << ":";
         if (isnan(re)) re = 0.0;
         if (isnan(im)) im = 0.0;
         double value = sqrt(re * re + im * im);
+//        std::cout << value << " ";
 	feature.values.push_back(value);
     }
     feature.label = "";
--- a/qm-vamp-plugins.n3	Thu Nov 20 16:55:27 2008 +0000
+++ b/qm-vamp-plugins.n3	Tue Nov 25 12:55:00 2008 +0000
@@ -7,7 +7,7 @@
 @prefix af:       <http://purl.org/ontology/af/> .
 @prefix foaf:     <http://xmlns.com/foaf/0.1/> .
 @prefix cc:       <http://web.resource.org/cc/> .
-@prefix :         <> .
+@prefix :         <#> .

 <>  a   vamp:PluginDescription ;
     foaf:maker          <http://www.vamp-plugins.org/doap.rdf#template-generator> ;
--- a/qm-vamp-plugins.txt	Thu Nov 20 16:55:27 2008 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,623 +0,0 @@
-
-QM Vamp Plugins
-===============
-
-Vamp audio feature extraction plugins from the Centre for Digital
-Music at Queen Mary, University of London.
-
-http://www.elec.qmul.ac.uk/digitalmusic/
-
-Version 1.4.
-
-For more information about Vamp plugins, see http://www.vamp-plugins.org/ .
-
-
-Note Onset Detector
-===================
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-onsetdetector]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-onsetdetector
-
-Note Onset Detector analyses a single channel of audio and estimates
-the onset times of notes within the music -- that is, the times at
-which notes and other audible events begin.
-
-It calculates an onset likelihood function for each spectral frame,
-and picks peaks in a smoothed version of this function.  The plugin is
-non-causal, returning all results at the end of processing.
-
-Parameters
-----------
-
-*Onset Detection Function Type* -- The method used to calculate the
-onset likelihood function.  The most versatile method is the default,
-"Complex Domain" (see reference, Duxbury et al 2003).  "Spectral
-Difference" may be appropriate for percussive recordings, "Phase
-Deviation" for non-percussive music, and "Broadband Energy Rise" (see
-reference, Barry et al 2005) for identifying percussive onsets in
-mixed music.
-
-*Onset Detector Sensitivity* -- Sensitivity level for peak detection
-in the onset likelihood function.  The higher the sensitivity, the
-more onsets will (rightly or wrongly) be detected.  The peak picker
-does not have a simple threshold level; instead, this parameter
-controls the required "steepness" of the slopes in the smoothed
-detection function either side of a peak value, in order for that peak
-to be accepted as an onset.
-
-*Adaptive Whitening* -- This option evens out the temporal and
-frequency variation in the signal, which can yield improved
-performance in onset detection, for example in audio with big
-variations in dynamics.
-
-Outputs
--------
-
-*Note Onsets* -- The detected note onset times, returned as a single
-feature with timestamp but no value for each detected note.
-
-*Onset Detection Function* -- The raw note onset likelihood function
-that was calculated as the first step of the detection process.
-
-*Smoothed Detection Function* -- The note onset likelihood function
-following median filtering.  This is the function from which
-sufficiently steep peak values are picked and classified as onsets.
-
-
-References and Credits
-----------------------
-
-*Basic detection methods*: C. Duxbury, J. P. Bello, M. Davies and
-M. Sandler, _Complex domain Onset Detection for Musical Signals_. In
-Proceedings of the 6th Conference on Digital Audio Effects
-(DAFx-03). London, UK. September 2003.
-
-*Adaptive whitening*: D. Stowell and M. D. Plumbley, _Adaptive
-whitening for improved real-time audio onset detection_. In
-Proceedings of the International Computer Music Conference (ICMC'07),
-August 2007.
-
-*Percussion onset detector*: D. Barry, D. Fitzgerald, E. Coyle and
-B. Lawlor, _Drum Source Separation using Percussive Feature Detection
-and Spectral Modulation_. ISSC 2005.
-
-The Note Onset Detector Vamp plugin was written by Chris Duxbury, Juan
-Pablo Bello and Christian Landone.
-
-
-
-Tempo and Beat Tracker
-======================
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-tempotracker]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-tempotracker
-
-Tempo and Beat Tracker analyses a single channel of audio and
-estimates the positions of metrical beats within the music (the
-equivalent of a human listener tapping their foot to the beat).
-
-Parameters
-----------
-
-*Onset Detection Function Type* -- The method used to calculate the
-onset likelihood function.  The most versatile method is the default,
-"Complex Domain" (see reference, Duxbury et al 2003).  "Spectral
-Difference" may be appropriate for percussive recordings, "Phase
-Deviation" for non-percussive music, and "Broadband Energy Rise" (see
-reference, Barry et al 2005) for identifying percussive onsets in
-mixed music.
-
-*Adaptive Whitening* -- This option evens out the temporal and
-frequency variation in the signal, which can yield improved
-performance in onset detection, for example in audio with big
-variations in dynamics.
-
-Outputs
--------
-
-*Beats* -- The estimated beat locations, returned as a single feature,
-with timestamp but no value, for each beat, labelled with the
-corresponding estimated tempo at that beat.
-
-*Onset Detection Function* -- The raw note onset likelihood function
-used in beat estimation.
-
-*Tempo* -- The estimated tempo, returned as a feature each time the
-estimated tempo changes, with a single value for the tempo in beats
-per minute.
-
-References and Credits
-----------------------
-
-*Beat tracking method*: M. E. P. Davies and M. D. Plumbley.
-_Context-dependent beat tracking of musical audio_. In IEEE
-Transactions on Audio, Speech and Language Processing. Vol. 15, No. 3,
-pp1009-1020, 2007.  See also M. E. P. Davies and M. D. Plumbley.
-_Beat Tracking With A Two State Model_. In Proceedings of the IEEE
-International Conference on Acoustics, Speech and Signal Processing
-(ICASSP 2005), Vol. 3, pp241-244 Philadelphia, USA, March 19-23, 2005.
-
-*Onset detection methods*: C. Duxbury, J. P. Bello, M. Davies and
-M. Sandler, _Complex domain Onset Detection for Musical Signals_. In
-Proceedings of the 6th Conference on Digital Audio Effects
-(DAFx-03). London, UK. September 2003.
-
-*Adaptive whitening*: D. Stowell and M. D. Plumbley, _Adaptive
-whitening for improved real-time audio onset detection_. In
-Proceedings of the International Computer Music Conference (ICMC'07),
-August 2007.
-
-*Percussion onset detector*: D. Barry, D. Fitzgerald, E. Coyle and
-B. Lawlor, _Drum Source Separation using Percussive Feature Detection
-and Spectral Modulation_. ISSC 2005.
-
-The Tempo and Beat Tracker Vamp plugin was written by Matthew Davies
-and Christian Landone.
-
-
-Key Detector
-============
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-keydetector]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-keydetector
-
-Key Detector analyses a single channel of audio and continuously
-estimates the key of the music by comparing the degree to which a
-block-by-block chromagram correlates to the stored key profiles for
-each major and minor key.
-
-The key profiles are drawn from analysis of Book I of the Well
-Tempered Klavier by J S Bach, recorded at A=440 equal temperament.
-
-Parameters
-----------
-
-*Tuning Frequency* -- The frequency of concert A in the music under
-analysis.
-
-*Window Length* -- The number of chroma analysis frames taken into
-account for key estimation.  This controls how eager the key detector
-will be to return short-duration tonal changes as new key changes (the
-shorter the window, the more likely it is to detect a new key change).
-
-Outputs
--------
-
-*Tonic Pitch* -- The tonic pitch of each estimated key change,
-returned as a single-valued feature at the point where the key change
-is detected, with value counted from 1 to 12 where C is 1, C# or Db is
-2, and so on up to B which is 12.
-
-*Key Mode* -- The major or minor mode of the estimated key, where
-major is 0 and minor is 1.
-
-*Key* -- The estimated key for each key change, returned as a
-single-valued feature at the point where the key change is detected,
-with value counted from 1 to 24 where 1-12 are the major keys and
-13-24 are the minor keys, such that C major is 1, C# major is 2, and
-so on up to B major which is 12; then C minor is 13, Db minor is 14,
-and so on up to B minor which is 24.
-
-*Key Strength Plot* -- A grid representing the ongoing key
-"probability" throughout the music.  This is returned as a feature for
-each chroma frame, containing 25 bins.  Bins 1-12 are the major keys
-from C upwards; bins 14-25 are the minor keys from C upwards.  The
-13th bin is unused: it just provides space between the first and
-second halves of the feature if displayed in a single plot.
-
-The outputs are also labelled with pitch or key as text.
-
-References and Credits
-----------------------
-
-*Method*: see K. Noland and M. Sandler. _Signal Processing Parameters
-for Tonality Estimation_. In Proceedings of Audio Engineering Society
-122nd Convention, Vienna, 2007.
-
-The Key Detector Vamp plugin was written by Katy Noland and Christian
-Landone.
-
-Tonal Change
-------------
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-tonalchange]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-tonalchange
-
-Tonal Change analyses a single channel of audio, detecting harmonic
-changes such as chord boundaries.
-
-Parameters
-----------
-
-*Gaussian smoothing* -- The window length for the internal smoothing
-operation, in chroma analysis frames.  This controls how eager the
-tonal change detector will be to identify very short-term tonal
-changes.  The default value of 5 is quite short, and may lead to more
-(not always meaningful) results being returned; for many purposes a
-larger value, closer to the maximum of 20, may be appropriate.
-
-*Chromagram minimum pitch* -- The MIDI pitch value (0-127) of the
-minimum pitch included in the internal chromagram analyis.
-
-*Chromagram maximum pitch* -- The MIDI pitch value (0-127) of the
-maximum pitch included in the internal chromagram analyis.
-
-*Chromagram tuning frequency* -- The frequency of concert A in the
-music under analysis.
-
-Outputs
--------
-
-*Transform to 6D Tonal Content Space* -- A representation of the
-musical content in a six-dimensional tonal space onto which the
-algorithm maps 12-bin chroma vectors extracted from the audio.
-
-*Tonal Change Detection Function* -- A function representing the
-estimated likelihood of a tonal change occurring in each spectral
-frame.
-
-*Tonal Change Positions* -- The resulting estimated positions of tonal
-changes.
-
-References and Credits
-----------------------
-
-*Method*: C. A. Harte, M. Gasser, and M. Sandler. _Detecting harmonic
-change in musical audio_.  In Proceedings of the 1st ACM workshop on
-Audio and Music Computing Multimedia, Santa Barbara, 2006.
-
-The Tonal Change Vamp plugin was wrtitten by Chris Harte and Martin
-Gasser.
-
-Segmenter
-=========
-
-*System identifier* -- [vamp:qm-vamp-plugins:qm-segmenter]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-segmenter
-
-Segmenter divides a single channel of music up into structurally
-consistent segments.  It returns a numeric value (the segment type)
-for each moment at which a new segment starts.
-
-For music with clearly tonally distinguishable sections such as verse,
-chorus, etc., segments with the same type may be expected to be
-similar to one another in some structural sense.  For example,
-repetitions of the chorus are likely to share a segment type.
-
-The plugin only attempts to identify similar segments; it does not
-attempt to label them.  For example, it makes no attempt to tell you
-which segment is the chorus.
-
-Note that this plugin does a substantial amount of processing after
-receiving all of the input audio data, before it produces any results.
-
-Method
-------
-
-The method relies upon structural/timbral similarity to obtain the
-high-level song structure.  This is based on the assumption that the
-distributions of timbre features are similar over corresponding
-structural elements of the music.
-
-The algorithm works by obtaining a frequency-domain representation of
-the audio signal using a Constant-Q transform, a Chromagram or
-Mel-Frequency Cepstral Coefficients (MFCC) as underlying features (the
-particular feature is selectable as a parameter).  The extracted
-features are normalised in accordance with the MPEG-7 standard (NASE
-descriptor), which means the spectrum is converted to decibel scale
-and each spectral vector is normalised by the RMS energy envelope.
-The value of this envelope is stored for each processing block of
-audio. This is followed by the extraction of 20 principal components
-per block using PCA, yielding a sequence of 21 dimensional feature
-vectors where the last element in each vector corresponds to the
-energy envelope.
-
-A 40-state Hidden Markov Model is then trained on the whole sequence
-of features, with each state of the HMM corresponding to a specific
-timbre type. This process partitions the timbre-space of a given track
-into 40 possible types. The important assumption of the model is that
-the distribution of these features remain consistent over a structural
-segment. After training and decoding the HMM, the song is assigned a
-sequence of timbre-features according to specific timbre-type
-distributions for each possible structural segment.
-
-The segmentation itself is computed by clustering timbre-type
-histograms. A series of histograms are created over a sliding window
-which are grouped into M clusters by an adapted soft k-means
-algorithm. Each of these clusters will correspond to a specific
-segment-type of the analyzed song. Reference histograms, iteratively
-updated during clustering, describe the timbre distribution for each
-segment. The segmentation arises from the final cluster assignments.
-
-Parameters
-----------
-
-*Number of segment-types* -- The maximum number of clusters
-(segment-types) to be returned.  The default is 10. Unlike many
-clustering algorithms, the constrained clustering used in this plugin
-does not produce too many clusters or vary significantly even if this
-is set too high. However, this parameter can be useful for limiting
-the number of expected segment-types.
-
-*Feature Type* -- The type of spectral feature used for segmentation.
-The default Hybrid (using a Constant-Q spectrogram) is generally
-effective for modern studio recordings, while the Chromatic (a
-chromagram) option may be preferable for live, acoustic, or older
-recordings, in which repeated sections may be less consistent in
-sound.  Also available is a timbral feature using Mel-frequency
-cepstral coefficients, which is more likely to result in
-classification by instrumentation rather than musical content.
-
-*Minimum segment duration* -- The approximate expected minimum
-duration for a segment, from 1 to 15 seconds.  Changing this parameter
-may help the plugin to find musical sections rather than just
-following changes in the sound of the music, and also avoid wasting a
-segment-type cluster for timbrally distinct but too-short segments.
-The default of 4 seconds usually produces good results.
-
-Outputs
--------
-
-*Segmentation* -- The estimated segment boundaries, returned as a
-single feature with one value at each segment boundary, with the value
-representing the segment type number for the segment starting at that
-boundary.
-
-References and Credits
-----------------------
-
-*Method*: M. Levy and M. Sandler. _Structural segmentation of musical
-audio by constrained clustering_. IEEE Transactions on Audio, Speech,
-and Language Processing, February 2008.
-
-Note that this plugin does not implemented the beat-sychronous aspect
-of the segmentation method described in the paper.
-
-The Segmenter Vamp plugin was written by Mark Levy.  Thanks to George
-Fazekas for providing much of this documentation.
-
-
-Similarity
-==========
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-similarity]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-similarity
-
-Similarity treats each channel of its audio input as a separate
-"track", and estimates how similar the tracks are to one another using
-a selectable similarity measure.
-
-The plugin also returns the intermediate data used as a basis of the
-similarity measure; it can therefore be used on a single channel of
-input (with the resulting intermediate data then being applied in some
-other similarity or clustering algorithm, for example) if desired, as
-well as with multiple inputs.
-
-Because of the way this plugin handles multiple inputs, by assuming
-that each channel represents a separate piece of music, it may not be
-appropriate for use directly in a general-purpose host (unless you
-actually want to do something like compare two stereo channels for
-timbral similarity, which is unlikely).
-
-Parameters
-----------
-*Feature Type* -- The underlying audio feature used for the similarity
-measure.  The available features are Timbre (in which the distance
-between tracks is a symmetrised Kullback-Leibler divergence between
-Gaussian-modelled MFCC means and variances across each track, for the
-first 20 MFCCs including C0); Chroma (KL divergence of mean chroma
-histogram); Rhythm (cosine distance between "beat spectrum" measures
-derived from a short sampled section of the track); and combined
-"Timbre and Rhythm" and "Chroma and Rhythm" features.
-
-Outputs
--------
-
-*Distance Matrix* -- A matrix of the distance measures between input
-channels, returned as a series of vector features timestamped at
-one-second intervals.  The distance from channel i to channel j
-appears as the j'th bin of the feature at time i.
-
-*Distance from First Channel* -- A single vector feature, timestamped
-at time zero, containing the distances between the first input channel
-and each of the input channels (including the first channel itself at
-bin 0, which should have zero distance).
-
-*Ordered Distances from First Channel* -- A pair of vector features,
-at times 0 and 1 second.  The feature at time 0 contains the 1-based
-indices of the input channels in the order of similarity to the first
-input channel (so its first bin should always contain 1, as the first
-channel is most similar to itself).  The feature at time 1 contains,
-in bin n, the distance between the first input channel and the channel
-with index found at bin n of the feature at time 0.
-
-*Feature Means* -- A series of vector features containing the mean
-values of each of the feature bins across the duration of each of the
-input channels.  This output returns one feature for each input
-channel, timestamped at one-second intervals.  The number of bins for
-each feature depends on the feature type; it will be 20 for MFCC
-features and 12 for chroma features.  No features will be returned on
-this output if the feature type is purely rhythmic.
-
-*Feature Variances* -- Just as Feature Means, but variances.
-
-*Beat Spectra* -- A series of vector features containing the rhythmic
-autocorrelation profiles (beat spectra) for each of the input
-channels.  This output returns one 512-bin feature for each input
-channel, timestamped at one-second intervals.  No features will be
-returned on this output if the feature type contains no rhythm
-component.
-
-References and Credits
-----------------------
-
-*Timbral similarity*: M. Levy and M. Sandler. _Lightweight measures
-for timbral similarity of musical audio_. In Proceedings of the 1st
-ACM workshop on Audio and Music Computing Multimedia, Santa Barbara,
-2006.
-
-*Combined rhythmic and timbral similarity*: K. Jacobson. _A
-Multifaceted Approach to Music Similarity_. In Proceedings of the
-Seventh International Conference on Music Information Retrieval
-(ISMIR), 2006.
-
-The Similarity Vamp plugin was written by Mark Levy, Kurt Jacobson and
-Chris Cannam.
-
-
-Constant-Q Spectrogram
-======================
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-constantq]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-constantq
-
-Constant-Q Spectrogram calculates a spectrogram based on a short-time
-windowed constant Q spectral transform.  This is a spectrogram in
-which the ratio of centre frequency to resolution is constant for each
-frequency bin.  The frequency bins correspond to the frequencies of
-"musical notes" rather than being linearly spaced in frequency as they
-are for the conventional DFT spectrogram.
-
-The pitch range and the number of frequency bins per octave may be
-adjusted using the plugin's parameters.  Note that the plugin's
-preferred step and block sizes are defined by these parameters, and
-the plugin will not accept any other block size than its preferred
-value.
-
-Parameters
-----------
-
-*Minimum Pitch* -- The MIDI pitch value (0-127) corresponding to the lowest
-frequency to be included in the constant-Q transform.
-
-*Maximum Pitch* -- The MIDI pitch value (0-127) corresponding to the
-lowest frequency to be included in the constant-Q transform.
-
-*Tuning Frequency* -- The frequency of concert A in the
-music under analysis.
-
-*Bins per Octave* -- The number of constant-Q transform bins to be
-computed per octave.
-
-*Normalized* -- Whether to normalize each output column to unit
-maximum.
-
-Outputs
--------
-
-*Constant-Q Spectrogram* -- The calculated spectrogram, as a single
-feature per process block containing one bin for each pitch included
-in the spectrogram's range.
-
-References and Credits
-----------------------
-
-*Principle*: J. Brown. _Calculation of a constant Q spectral
-transform_. Journal of the Acoustical Society of America, 89(1):
-425-434, 1991.
-
-The Constant-Q Spectrogram Vamp plugin was written by Christian
-Landone.
-
-
-Chromagram
-==========
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-chromagram]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-chromagram
-
-Chromagram calculates a constant Q spectral transform (as in the
-Constant Q Spectrogram plugin) and then wraps the frequency bin values
-into a single octave, with each bin containing the sum of the
-magnitudes from the corresponding bin in all octaves.  The number of
-values in each feature vector returned by the plugin is therefore the
-same as the number of bins per octave configured for the underlying
-constant Q transform.
-
-The pitch range and the number of frequency bins per octave for the
-transform may be adjusted using the plugin's parameters.  Note that
-the plugin's preferred step and block sizes depend on these
-parameters, and the plugin will not accept any other block size than
-its preferred value.
-
-Parameters
-----------
-
-*Minimum Pitch* -- The MIDI pitch value (0-127) corresponding to the
-lowest frequency to be included in the constant-Q transform used in
-calculating the chromagram.
-
-*Maximum Pitch* -- The MIDI pitch value (0-127) corresponding to the
-lowest frequency to be included in the constant-Q transform used in
-calculating the chromagram.
-
-*Tuning Frequency* -- The frequency of concert A in the
-music under analysis.
-
-*Bins per Octave* -- The number of constant-Q transform bins to be
-computed per octave, and thus the total number of bins present in the
-resulting chromagram.
-
-*Normalized* -- Whether to normalize each output column. Normalization
-may be to unit sum or unit maximum.
-
-Outputs
--------
-
-*Chromagram* -- The calculated chromagram, as a single feature per
-process block containing the number of bins given in the bins per
-octave parameter.
-
-References and Credits
-----------------------
-The Chromagram Vamp plugin was written by Christian Landone.
-
-
-Mel-Frequency Cepstral Coefficients
-===================================
-
-*System identifier* --    [vamp:qm-vamp-plugins:qm-mfcc]
-*RDF URI* -- http://vamp-plugins.org/rdf/plugins/qm-vamp-plugins#qm-mfcc
-
-Mel-Frequency Cepstral Coefficients calculates MFCCs from a single
-channel of audio.  These coefficients, derived from a cosine transform
-of the mapping of an audio spectrum onto a frequency scale modelled on
-human auditory response, are widely used in speech recognition, music
-classification and other tasks.
-
-Parameters
-----------
-
-*Number of Coefficients* -- The number of MFCCs to return.  Commonly
-used values include 13 or the default 20.  This number includes C0 if
-requested (see Include C0 below).
-
-*Power for Mel Amplitude Logs* -- An optional power value to which the
-spectral amplitudes should be raised before applying the cosine
-transform.  Values greater than 1 may in principle reduce the
-contribution of noise to the results.  The default is 1.
-
-*Include C0* -- Whether to include the "zero'th" coefficient, which
-simply reflects the overall signal power across the Mel frequency
-bands.
-
-Outputs
--------
-
-*Coefficients* -- The MFCC values, returned as one vector feature per
-processing block.
-
-*Means of Coefficients* -- The overall means of the MFCC bins, as a
-single vector feature with time 0 that is returned when processing is
-complete.
-
-References and Credits
-----------------------
-
-*MFCCs in music*: See B. Logan. _Mel-Frequency Cepstral Coefficients
-for Music Modeling_. In Proceedings of the First International
-Symposium on Music Information Retrieval (ISMIR), 2000.
-
-The Mel-Frequency Cepstral Coefficients Vamp plugin was written by
-Nicolas Chetry and Chris Cannam.
-