Difference between revisions of "2009:Audio Cover Song Identification"

From MIREX Wiki
(Discussions)
(Evaluation)
 
(13 intermediate revisions by 7 users not shown)
Line 3: Line 3:
 
The text of this section is copied from the 2008 page. Please add your comments and discussions for 2009.  
 
The text of this section is copied from the 2008 page. Please add your comments and discussions for 2009.  
  
The Audio Cover Song task was a new task for MIREX 2006 and was last run in 2008. It was closely related to the [[Audio Music Similarity and Retrieval]] (AMS) task as the cover songs were embedded in the Audio Music Similarity and Retrieval test collection.  
+
The Audio Cover Song task was a new task for MIREX 2006 and was last run in 2008. It was closely related to the [[2009:Audio Music Similarity and Retrieval]] (AMS) task as the cover songs were embedded in the Audio Music Similarity and Retrieval test collection.  
  
 
==Task Description==
 
==Task Description==
Line 10: Line 10:
 
Using each of these cover song files in turn as as the "seed/query" file, we will examine the returned lists of items for the presence of the other 10 versions of the "seed/query" file.
 
Using each of these cover song files in turn as as the "seed/query" file, we will examine the returned lists of items for the presence of the other 10 versions of the "seed/query" file.
  
 +
 +
==New Dataset for 2009==
 +
On top of the previous Audio Cover Song dataset, we are going to use the  [http://www.mazurka.org.uk/ Mazurka dataset]. We are going to randomly choose 11 versions from 49 mazurkas and run it as a separate subtask. The I/O format will be the same as previous years. Systems will return a distance matrix of 539x539.
  
 
== Discussions  for 2009 ==
 
== Discussions  for 2009 ==
  
Your comments here.  
+
Is there any interest in running a general identification sub-task? That is, the input would be a reference song and a test song, and the algorithm would classify the reference/test pair as either a reference/cover or a reference/non-cover. Ultimately, this is what we want any cover song detection algorithm to do and given the rather large strides the MIR community has made on cover song detection over the past couple years, I think this new sub-task would be both challenging and meaningful. - Suman Ravuri
  
 
=== Command Line Calling Format ===
 
=== Command Line Calling Format ===
Line 79: Line 82:
 
==Evaluation==
 
==Evaluation==
  
We could employ the same measures used in [[2007:Audio Cover Song]].
+
We could employ the same measures used in [[2007:Audio_Cover_Song_Identification]].
  
 
==Potential Participants==
 
==Potential Participants==
  
* Your name here
+
* Rémi foucard & Mathieu Lagrange (Telecom ParisTech)
 +
* Suman Ravuri & Dan Ellis (International Computer Science Institute/UC Berkeley & Columbia respectively) - still interested. Mostly likely 1 algorithm with a fairly low probability (< 15%) of another algorithm.
 +
* Joan Serrà (Music Technology Group, Universitat Pompeu Fabra) - One algorithm
 +
* Teppo E. Ahonen (Dept. of Computer Science, University of Helsinki)

Latest revision as of 22:58, 19 December 2011

2009 AUDIO COVER SONG IDENTIFICATION TASK OVERVIEW

The text of this section is copied from the 2008 page. Please add your comments and discussions for 2009.

The Audio Cover Song task was a new task for MIREX 2006 and was last run in 2008. It was closely related to the 2009:Audio Music Similarity and Retrieval (AMS) task as the cover songs were embedded in the Audio Music Similarity and Retrieval test collection.

Task Description

Within the 1000 pieces in the Audio Cover Song database, there are embedded 30 different "cover songs" each represented by 11 different "versions" for a total of 330 audio files (16bit, monophonic, 22.05khz, wav). The "cover songs" represent a variety of genres (e.g., classical, jazz, gospel, rock, folk-rock, etc.) and the variations span a variety of styles and orchestrations.

Using each of these cover song files in turn as as the "seed/query" file, we will examine the returned lists of items for the presence of the other 10 versions of the "seed/query" file.


New Dataset for 2009

On top of the previous Audio Cover Song dataset, we are going to use the Mazurka dataset. We are going to randomly choose 11 versions from 49 mazurkas and run it as a separate subtask. The I/O format will be the same as previous years. Systems will return a distance matrix of 539x539.

Discussions for 2009

Is there any interest in running a general identification sub-task? That is, the input would be a reference song and a test song, and the algorithm would classify the reference/test pair as either a reference/cover or a reference/non-cover. Ultimately, this is what we want any cover song detection algorithm to do and given the rather large strides the MIR community has made on cover song detection over the past couple years, I think this new sub-task would be both challenging and meaningful. - Suman Ravuri

Command Line Calling Format

$ /path/to/submission <collection_list_file> <query_list_file> <working_directory> <output_file>
    <collection_list_file>: Text file containing 1000 full path file names for the
                            1000 audio files in the collection (including the 330 
                            query documents).
                            Example: /path/to/coversong/collection.txt
    <query_list_file>     : Text file containing the 330 full path file names for the 
                            330 query documents.
                            Example: /path/to/coversong/queries.txt
    <working_directory>   : Full path to a temporary directory where submission will 
                            have write access for caching features or calculations.
                            Example: /tmp/submission_id/
    <output_file>         : Full path to file where submission should output the similarity 
                            matrix (1000 header rows + 330 x 1000 data matrix).
                            Example: /path/to/coversong/results/submission_id.txt

Input Files

The collection lists file format will be of the form:

/path/to/audio/file/000.wav\n
/path/to/audio/file/001.wav\n
/path/to/audio/file/002.wav\n
... * 996 rows omitted * ...
/path/to/audio/file/999.wav\n

The query lists file format will be of the form:

/path/to/audio/file/182.wav\n
/path/to/audio/file/245.wav\n
/path/to/audio/file/432.wav\n
... * 326 rows omitted * ...
/path/to/audio/file/973.wav\n

For a total of 330 rows -- query ids are randomly assigned from the pool of 1000 collection ids.

Lines will be terminated by a '\n' character.

Output File

The only output will be a distance matrix file that is 330 rows by 1000 columns in the following format:


Example distance matrix 0.1 (replace this line with your system name)
1    path/to/audio/file/1.wav
2    path/to/audio/file/2.wav
3    path/to/audio/file/3.wav
...
N    path/to/audio/file/N.wav
Q/R    1        2        3        ...        N
1    0.0      1.241    0.2e-4     ...    0.4255934
2    1.241    0.000    0.6264     ...    0.2356447
3    50.2e-4  0.6264   0.0000     ...    0.3800000
...    ...    ...      ...        ...    0.7172300
5    0.42559  0.23567  0.38       ...    0.000

All distances should be zero or positive (0.0+) and should not be infinite or NaN. Values should be separated by a TAB.

As N (collection searched for covers) is 1000 and there are 330 original tracks, the distance matrix should be preceded by 1000 rows of file paths and should be composed of 1000 columns of distance (separated by tab characters) and 330 rows (one for each original track). Each row corresponds to a particular query song (the track to find covers of). Please ensure that the query songs are listed in exactly the same order as they appear in the list file you are passed.

Evaluation

We could employ the same measures used in 2007:Audio_Cover_Song_Identification.

Potential Participants

  • R├⌐mi foucard & Mathieu Lagrange (Telecom ParisTech)
  • Suman Ravuri & Dan Ellis (International Computer Science Institute/UC Berkeley & Columbia respectively) - still interested. Mostly likely 1 algorithm with a fairly low probability (< 15%) of another algorithm.
  • Joan Serr├á (Music Technology Group, Universitat Pompeu Fabra) - One algorithm
  • Teppo E. Ahonen (Dept. of Computer Science, University of Helsinki)