i find the distance between songs using MFCCs as the feature.
Using mirquery, the song that i hummed didn't come out as one of
the top few rankings. Which means that the dist between the song
that i hummed and the song that i want to retrieve didn't have
the shortest distance using MFCCs. So i'm not very sure what the
reason could be.
On Wed, Jan 13, 2010 at 11:53 PM, Olivier Lartillot
<olartillot@xxxxxxxxx <mailto:olartillot@xxxxxxxxx>> wrote:
Hi Sarah,
Le 12.1.2010 à 18.02, sarah lam a écrit :
Hi Oliver and the rest of the gang
*Question on MFCC*
/mirmfcc(..., 'Rank’, N) /computes the coefficients of
rank(s) /N/. The default value is /N /= 1:13
I'm very puzzled as to why N must be a range and why it
can't be a discrete number.
I'm just guessing that perhaps there might not be enough
signal information if only a single coefficient is being used.
N can be a single value, no problem. However, it is true
that in current release 1.2.3, there is a bug in the
graphical representation and also in mirgetdata, when
computing mirmfcc with frame decomposition: the vector is
erroneously transposed. This will be corrected in the next
release.
*Question on Query by Humming*
When the original wav is used as the query, mirdist()
returns the queried song with the shortest distance.
mirdist only returns distances. I guess you meant
mirquery(), right?
However when I recorded my humming as the query, mirdist()
did not work as well.
And i really do not think i'm singing out of tune.
Is it because there might be too much background music and
therefore just humming the melody is not good enough?
Please note that mirdist(x,Y) is nothing more than the
computation of the distance between x and Y where x and Y
related to one given *feature*. So all depends on the
feature you are using. Besides, current distances used in
mirdist do not take into account for instance the distance
between pitch trajectories between songs (and query). So
query by humming using MIRtoolbox would require some further
thoughts.
Regards,
Olivier
