2019:Audio Fingerprinting - Revision history

Chung-Che Wang: /* Special notes */

2019-11-04T23:43:08Z

‎Special notes

Chung-Che Wang at 14:34, 30 July 2019

2019-07-30T14:34:16Z

Yun Hao: Created page with "== Description == This task is audio fingerprinting, also known as query by (exact but noisy) examples. Several companies have launched services based on such technology, incl..."

2019-03-07T22:15:01Z

Created page with "== Description == This task is audio fingerprinting, also known as query by (exact but noisy) examples. Several companies have launched services based on such technology, incl..."

New page

== Description ==
This task is audio fingerprinting, also known as query by (exact but noisy) examples. Several companies have launched services based on such technology, including Shazam, Soundhound, Intonow, Viggle, etc. Though the technology has been around for years, there is no benchmark dataset for evaluation. This task is the first step toward building an extensive corpus for evaluating methodologies in audio fingerprinting.

== Data ==
=== Database ===
10,000 songs (*.mp3) in the database, in which there is exact one song corresponding to each query. (That is, there is no out-of-vocabulary query in the query set.) 965 of the files are from GTZAN data set, all the others are mainly English and Chinese pop songs. This data set is hidden and not available for download. (Note that there are possibly different numbers of channels (mono and stereo), sampling rates, and bit resolutions for these files.)

The GTZAN data set were purified according to [1][2]. Exact repetitions were considered by the following principles:
* If none of the songs in a repetition set has corresponding queries, then nothing is removed from the database.
* If one of the songs in a repetition set has corresponding queries, then all the other songs (which have no corresponding queries) were removed from the database.
* If two or more of the songs in a repetition set has corresponding queries, then only one song (which has corresponding queries) was kept in the database. Note that if a query clip corresponds to a removed song, then the query's ground truth is modified to the kept song.

=== Query set ===
The query set has two parts:
* 4630 clips of wav format: These are hidden and not available for download
* 1062 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via [http://mirlab.org/dataSet/public/queryPublic_George.rar this link]

All the query set is mono recordings of 8-12 sec, with 44.1 KHz sampling rate and 16-bit resolution. The set was obtained via different brands of smartphones, at various locations with various kinds of environmental noise.

== Evaluation Procedures ==
The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.

== Submission Format ==
Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:

1. Database Builder

Command format:
builder %fileList4db% %dir4db%
where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.mp3. For example:
./AFP/database/000001.mp3
./AFP/database/000002.mp3
./AFP/database/000003.mp3
./AFP/database/000004.mp3
...

The output file(s), which containing all the information of the database to be used for audio fingerprinting, should be placed placed into the directory %dir4db%. The total size of the database file(s) is restricted to a certain amount, as explained next.

2. Matcher

Command format:
matcher %fileList4query% %dir4db% %resultFile%
where %fileList4query% is a file containing the list of query clips. For example:
./AFP/query/q000001.wav
./AFP/query/q000002.wav
./AFP/query/q000003.wav
./AFP/query/q000004.wav
...

The result file gives retrieved result for each query, with the format:

%queryFilePath% %dbFilePath%

where these two fields are separated by a tab. Here is a more specific example:

./AFP/query/q000001.wav ./AFP/database/0000004.mp3
./AFP/query/q000002.wav ./AFP/database/0000054.mp3
./AFP/query/q000003.wav ./AFP/database/0001002.mp3
..

== Time and hardware limits ==
Due to the fact that more features extracted for AFP almost always lead to better accuracy, we need to put hard limits on runtime and storage. (The limits of runtime and storage also put a limit of memory usage implicitly.) The time/storage limits of different steps are shown in the following table:
{| class="wikitable" |-
! Steps !! Time limit !! Storage limit
|-
| builder || 24 hours || 50KB for 1 minute of music. Assuming that the duration is 4 mins in average, then the total storage for 10,000 songs should be around 50*10000*4/1000000 = 2GB.
|-
| matcher || 24 hours || None
|}
Submissions that exceed these limitations may not receive a result.

== Potential Participants ==

== Discussion ==
name / email

== Bibliography ==

== References ==

[1] Bob L. Sturm, ``The State of the Art Ten Years After a State of the Art: Future Research in Music Information Retrieval,'' J. New Music Research, vol. 43, no. 2, pp. 147–172, 2014.

[2] Faults in the GTZAN Music Genre Dataset, available at http://imi.aau.dk/~bst/research/GTZANtable2/ , 2014.

@@ Line 72: / Line 72: @@
 == Special notes ==
-* In this year, we will run participants' submissions on Linux without Matlab. C/Python source or executable are most welcome.
+* We will run participants' submissions on Linux without Matlab. C/Python source or executable are most welcome.
 * To run multiple submissions in the same time conveniently, writing temporary files in directories of database audio files (i.e. paths in %file_list_for_db%) is not allowed. Please write temporary files (like *.wav files or any other intermediate formats) only in ./tmp or ./temp . Note that if any file is required by matcher and is produced (written, copied, and so on) by builder, then it is considered as part of database and should be putted in %dir_for_db%.
 * Please check the existence of folders (%dir_for_db%, ./tmp, and ./temp) in the builder before reading any audio. If any of the intended folders are not exist, please create them automatically.
@@ Line 78: / Line 78: @@
 * ffmpeg is available on the system but the version is not guaranteed. If a certain version is needed, please include it within the submission and use something like "./ffmpeg" to call it.
 * Sampling rate of query files is 44.1 KHz, other formats like 8 KHz will not be provided.
+* Actually some out-of-vocabulary queries are listed in the %query_file_path%, but only those who have correspond song in the database (i.e. 5692 of them) are considered while computing the accuracy. Besides, since we will used a very small set to test participants' submissions before running on the whole set, participants are encouraged to output something in %result_file% even if queries are likely to be unseen.
 * Participants will be asked to modify the submission if any of the above specifications are not followed.

@@ Line 14: / Line 14: @@
 The query set has two parts:
 * 4630 clips of wav format: These are hidden and not available for download
-* 1062 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via [http://mirlab.org/dataSet/public/queryPublic_George.rar this link]
+* 1062 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via [https://drive.google.com/open?id=1elI15BomiiNfCXLxpBjhdI3nB6bN9UEp this link]
 All the query set is mono recordings of 8-12 sec, with 44.1 KHz sampling rate and 16-bit resolution. The set was obtained via different brands of smartphones, at various locations with various kinds of environmental noise.
@@ Line 27: / Line 27: @@
 Command format:
-  builder %fileList4db% %dir4db%
+  builder %file_list_for_db% %dir_for_db%
-where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.mp3. For example:
+where %file_list_for_db% is a file containing the input list of database audio files, with name convention as uniqueKey.mp3. For example:
   ./AFP/database/000001.mp3
   ./AFP/database/000002.mp3
@@ Line 35: / Line 35: @@
   ...
-The output file(s), which containing all the information of the database to be used for audio fingerprinting, should be placed placed into the directory %dir4db%. The total size of the database file(s) is restricted to a certain amount, as explained next.
+The output file(s), which containing all the information of the database to be used for audio fingerprinting, should be placed into the directory %dir_for_db%. The total size of the database file(s) is restricted to a certain amount, as explained next.
 . Matcher
 Command format:
-  matcher %fileList4query% %dir4db% %resultFile%
+  matcher %file_list_for_query% %dir_for_db% %result_file%
-where %fileList4query% is a file containing the list of query clips. For example:
+where %file_list_for_query% is a file containing the list of query clips. For example:
   ./AFP/query/q000001.wav
   ./AFP/query/q000002.wav
@@ Line 50: / Line 50: @@
 The result file gives retrieved result for each query, with the format:
-  %queryFilePath%	%dbFilePath%
+  %query_file_path%	%db_file_path%
 where these two fields are separated by a tab. Here is a more specific example:
@@ Line 60: / Line 60: @@
 == Time and hardware limits ==
 Due to the fact that more features extracted for AFP almost always lead to better accuracy, we need to put hard limits on runtime and storage. (The limits of runtime and storage also put a limit of memory usage implicitly.) The time/storage limits of different steps are shown in the following table:
 {| class="wikitable" |-
@@ Line 69: / Line 70: @@
 |}
 Submissions that exceed these limitations may not receive a result.
 == Potential Participants ==