https://music-ir.org/mirex/w/api.php?action=feedcontributions&feedformat=atom&user=Jyh-Shing+Roger+Jang 2026-04-29T20:13:43Z User contributions MediaWiki 1.31.1 https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10358 2014-08-12T15:08:55Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) 1,000 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.)<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/000001.mp3<br /> ./AFP/database/000002.mp3<br /> ./AFP/database/000003.mp3<br /> ./AFP/database/000004.mp3<br /> ...<br /> <br /> 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.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q000001.wav<br /> ./AFP/query/q000002.wav<br /> ./AFP/query/q000003.wav<br /> ./AFP/query/q000004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q000001.wav ./AFP/database/0000004.mp3<br /> ./AFP/query/q000002.wav ./AFP/database/0000054.mp3<br /> ./AFP/query/q000003.wav ./AFP/database/0001002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/50 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 4.8 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/50 = 13.33 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 5 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 5*5692/3600 = 7.91 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10357 2014-08-12T14:56:06Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) 1,000 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.)<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/000001.mp3<br /> ./AFP/database/000002.mp3<br /> ./AFP/database/000003.mp3<br /> ./AFP/database/000004.mp3<br /> ...<br /> <br /> 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.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q000001.wav<br /> ./AFP/query/q000002.wav<br /> ./AFP/query/q000003.wav<br /> ./AFP/query/q000004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q000001.wav ./AFP/database/0000004.mp3<br /> ./AFP/query/q000002.wav ./AFP/database/0000054.mp3<br /> ./AFP/query/q000003.wav ./AFP/database/0001002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/50 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 4.8 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/50 = 13.33 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10356 2014-08-12T14:43:35Z

<p>Jyh-Shing Roger Jang: /* Submission Format */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) 1,000 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.)<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/000001.mp3<br /> ./AFP/database/000002.mp3<br /> ./AFP/database/000003.mp3<br /> ./AFP/database/000004.mp3<br /> ...<br /> <br /> 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.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q000001.wav<br /> ./AFP/query/q000002.wav<br /> ./AFP/query/q000003.wav<br /> ./AFP/query/q000004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q000001.wav ./AFP/database/0000004.mp3<br /> ./AFP/query/q000002.wav ./AFP/database/0000054.mp3<br /> ./AFP/query/q000003.wav ./AFP/database/0001002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10355 2014-08-12T14:39:47Z

<p>Jyh-Shing Roger Jang: /* Query set */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) 1,000 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.)<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10354 2014-08-12T14:38:27Z

<p>Jyh-Shing Roger Jang: /* Database */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) 1,000 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.)<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10350 2014-08-07T01:01:33Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> 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:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10349 2014-08-07T00:48:27Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the database in average. For a database of 10000 songs, the total time should around 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be around 50*10000*4/1000000 = 2GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10348 2014-08-07T00:46:27Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the databse in average. For a database of 10000 songs, the total time should be less than 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be less than 50*10000*4/1000000=2 GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5692 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10347 2014-08-07T00:45:48Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the databse in average. For a database of 10000 songs, the total time should be less than 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be less than 50*10000*4/1000000=2 GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5719 queries of around 10 seconds, the total query time should be around 2*5692/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10346 2014-08-07T00:43:25Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the databse in average. For a database of 10000 songs, the total time should be less than 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be less than 50*10000*4/1000000=2 GB.)<br /> |-<br /> | matcher || 2 secs for each query of around 10 seconds (Thus for 5719 queries of around 10 seconds, the total query time should be around 2*5719/3600 = 3.2 hours.) || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10345 2014-08-07T00:39:39Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the databse in average. For a database of 10000 songs, the total time should be less than 10000*4/60/100 = 6.7 hours.) || 50KB for 1 minute of music. (For a database of 10000 songs, the total storage for database should be less than 50*10000*4/1000000=2 GB.)<br /> |-<br /> | matcher || 10 hours || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10344 2014-08-07T00:33:18Z

<p>Jyh-Shing Roger Jang: /* Time and hardware limits */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4630 clips of wav format: These are hidden and not available for download<br /> * 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] <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> <br /> 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 size of the database file(s) is restricted to a certain amount, as explained next.<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dir4db% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 1/100 of real time (For instance, if a music clip has a duration of 4 minutes, it should take 2.4 sec to construct the databse in average. For a database of 10000 songs, the total time should be less than 10000*4/60/100 = 6.7 hours.) || 3 GB for the database file(s)<br /> |-<br /> | matcher || 10 hours || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10333 2014-07-27T07:11:50Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 24 hours || 3 GB for the database file %afpDb%<br /> |-<br /> | matcher || 10 hours || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10332 2014-07-27T07:11:16Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage limit<br /> |-<br /> | builder || 24 hours || 3 GB for %afpDb%<br /> |-<br /> | matcher || 10 hours || None<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10331 2014-07-27T07:08:43Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the fact that more features extracted for AFP almsot always lead to better accuracy, we need to hard limits for memory and runtime. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10330 2014-07-27T07:05:43Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> <br /> %queryFilePath% %dbFilePath%<br /> <br /> where these two fields are separated by a tab. Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10329 2014-07-27T07:05:11Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query, with the format:<br /> %queryFilePath% %dbFilePath%<br /> where these two fields are separated by a tab.<br /> <br /> Here is a more specific example:<br /> <br /> ./AFP/query/q0001.wav ./AFP/database/00004.mp3<br /> ./AFP/query/q0002.wav ./AFP/database/00054.mp3<br /> ./AFP/query/q0003.wav ./AFP/database/01002.mp3<br /> ..<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10328 2014-07-27T06:57:28Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dbName%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> The output file %dbName% contains all the information of the database to be used for audio fingerprinting. (The size of the database file is restricted to a certain amount, as explained next.)<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %fileList4query% %dbName% %resultFile%<br /> where %fileList4query% is a file containing the list of query clips. For example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10327 2014-07-27T06:49:44Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %fileList4db% %dir4db%<br /> where %fileList4db% is a file containing the input list of database audio files, with name convention as uniqueKey.wav. For example:<br /> ./AFP/database/00001.mp3<br /> ./AFP/database/00002.mp3<br /> ./AFP/database/00003.mp3<br /> ./AFP/database/00004.mp3<br /> ...<br /> Output file(s) should be placed into %db_dir%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %db_dir% %file.query.list% %resultFile%<br /> where %db_dir% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10326 2014-07-27T06:43:28Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) clips of wav format: These are hidden and not available for download<br /> * 1264 clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> 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 smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the query set (two parts), with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %db_dir%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %db_dir%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %db_dir% %file.query.list% %resultFile%<br /> where %db_dir% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10325 2014-07-25T16:18:19Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) 10-sec clips of wav format: These are hidden and not available for download<br /> * 1264 10-sec clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These mono recordings, with 44.1 KHz sampling rate and 16-bit resolution, were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %db_dir%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %db_dir%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %db_dir% %file.query.list% %resultFile%<br /> where %db_dir% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10324 2014-07-25T16:16:14Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) 10-sec clips of wav format: These are hidden and not available for download<br /> * 1264 10-sec clips of wav format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These mono recordings, with 44.1 KHz sampling rate and 16-bit resolution, were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %db_dir%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %db_dir%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10323 2014-07-25T16:08:34Z

<p>Jyh-Shing Roger Jang: /* Evaluation Procedures */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) 10-sec clips of mp3 format: These are hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is based on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10322 2014-07-25T16:07:57Z

<p>Jyh-Shing Roger Jang: /* Query set */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 (???) 10-sec clips of mp3 format: These are hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is baesd on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10321 2014-07-25T16:01:24Z

<p>Jyh-Shing Roger Jang: /* Submission Format */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 10-second clips of mp3 format: This is hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is baesd on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, which includes the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10320 2014-07-25T16:00:15Z

<p>Jyh-Shing Roger Jang: /* Submission Format */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 10-second clips of mp3 format: This is hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is baesd on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of the algorithm, including the following two parts:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10319 2014-07-25T15:58:30Z

<p>Jyh-Shing Roger Jang: /* Evaluation Procedures */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 10-second clips of mp3 format: This is hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> The evaluation is baesd on the two parts of the query set, with top-1 hit rate being the performance index.<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10318 2014-07-25T15:57:25Z

<p>Jyh-Shing Roger Jang: /* Query set */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 10-second clips of mp3 format: This is hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: These recordings are noisy versions of George's music genre dataset. You can download the query set via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10317 2014-07-25T15:54:48Z

<p>Jyh-Shing Roger Jang: /* Query */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query set ===<br /> The query set has two parts:<br /> * 4000 10-second clips of mp3 format: This is hidden and not available for download<br /> * 1264 10-sec clips of mp3 format: This is open and available for download via this link <br /> <br /> These recordings were obtained via different brands of smartphone, at various locations with various kinds of environmental noise.<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10316 2014-07-25T15:50:35Z

<p>Jyh-Shing Roger Jang: /* Database */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.) This dataset is hidden and not available for download.<br /> <br /> === Query ===<br /> * 1,264 10-second clips<br /> * mono, 44.1 kHz, 16 bit resolution<br /> * Recorded by variety brand of smartphones, containing noise<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10315 2014-07-25T15:49:23Z

<p>Jyh-Shing Roger Jang: /* Database */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 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.)<br /> <br /> === Query ===<br /> * 1,264 10-second clips<br /> * mono, 44.1 kHz, 16 bit resolution<br /> * Recorded by variety brand of smartphones, containing noise<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10314 2014-07-25T15:47:22Z

<p>Jyh-Shing Roger Jang: /* Description */</p> <hr /> <div>== Description ==<br /> 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.<br /> <br /> == Data ==<br /> === Database ===<br /> * 10,000 songs (*.mp3) in the database<br /> <br /> === Query ===<br /> * 1,264 10-second clips<br /> * mono, 44.1 kHz, 16 bit resolution<br /> * Recorded by variety brand of smartphones, containing noise<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10313 2014-07-25T15:46:34Z

<p>Jyh-Shing Roger Jang: /* Description */</p> <hr /> <div>== Description ==<br /> 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 audio fingerprinting.<br /> <br /> == Data ==<br /> === Database ===<br /> * 10,000 songs (*.mp3) in the database<br /> <br /> === Query ===<br /> * 1,264 10-second clips<br /> * mono, 44.1 kHz, 16 bit resolution<br /> * Recorded by variety brand of smartphones, containing noise<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2014:Audio_Fingerprinting&diff=10312 2014-07-25T15:41:17Z

<p>Jyh-Shing Roger Jang: /* Database */</p> <hr /> <div>== Description ==<br /> This task requires the query by using exact but noisy recordings.<br /> <br /> == Data ==<br /> === Database ===<br /> * 10,000 songs (*.mp3) in the database<br /> <br /> === Query ===<br /> * 1,264 10-second clips<br /> * mono, 44.1 kHz, 16 bit resolution<br /> * Recorded by variety brand of smartphones, containing noise<br /> <br /> == Evaluation Procedures ==<br /> Top-1 hit rate<br /> <br /> == Submission Format ==<br /> Participants are required to submit a breakdown version of algorithm. The two parts are:<br /> <br /> 1. Database Builder<br /> <br /> Command format:<br /> builder %file.db.list% %dir_db%<br /> where %file.db.list% is the input list of database audio files named as uniq_key.wav For example:<br /> ./AFP/database/00001.wav<br /> ./AFP/database/00002.wav<br /> ./AFP/database/00003.wav<br /> ./AFP/database/00004.wav<br /> ...<br /> Output file(s) should be placed into %dir_db%<br /> <br /> 2. Matcher<br /> <br /> Command format:<br /> matcher %dir_db% %file.query.list% %resultFile%<br /> where %dir_db% is the directory for the built database.<br /> <br /> %file.query.list% is the input list of query clips, for example:<br /> ./AFP/query/q0001.wav<br /> ./AFP/query/q0002.wav<br /> ./AFP/query/q0003.wav<br /> ./AFP/query/q0004.wav<br /> ...<br /> <br /> The result file gives retrieved result for each query. The format should be:<br /> %main_query_file_name% %main_top_1_candiate_file_name%<br /> <br /> For example:<br /> <br /> q0001 00204<br /> q0002 08964<br /> q0003 05566<br /> ...<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions are specified. The time/storage limits of different steps are shown in the following table:<br /> {| class=&quot;wikitable&quot; |-<br /> ! Steps !! Time limit !! Storage (hard disk) limit<br /> |-<br /> | builder || 24 hours || 3 GB<br /> |-<br /> | matcher || 10 hours || N/A<br /> |}<br /> Submissions that exceed these limitations may not receive a result.<br /> <br /> == Potential Participants ==<br /> <br /> == Discussion ==<br /> name / email<br /> <br /> = Bibliography =</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2013:Query_by_Singing/Humming&diff=9152 2013-02-17T04:05:12Z

<p>Jyh-Shing Roger Jang: </p> <hr /> <div>== Description ==<br /> <br /> The text of this section is copied from the 2010 page. Please add your comments and discussions for 2013. <br /> <br /> <br /> The goal of the Query-by-Singing/Humming (QBSH) task is the evaluation of MIR systems that take as query input queries sung or hummed by real-world users. More information can be found in:<br /> <br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2008:Query_by_Singing/Humming]]<br /> * [[2007:Query_by_Singing/Humming]]<br /> * [[2006:Query_by_Singing/Humming]]<br /> <br /> <br /> <br /> === Subtask 1: Classic QBSH evaluation ===<br /> This is the classic QBSH problem where we need to find the ground-truth midi from a user's singing or humming.<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from MIR-QBSH and IOACAS corpora described below.<br /> * '''Database''': ground-truth and noise MIDI files(which are monophonic). Comprised of ground-truth MIDIs from MIR-QBSH corpus (48), and IOACAS corpus (106), along with a cleaned version of Essen Database(2000+ MIDIs which are not available to the participator) <br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> === Subtask 2: Variants QBSH evaluation ===<br /> This is based on Prof. Downie's idea that queries are variants of &quot;ground-truth&quot; midi. In fact, this becomes more important since user-contributed singing/humming is an important part of the song database to be searched, as evidenced by the QBSH search service at [http://www.midomi.com/ www.midomi.com].<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from Roger Jang's corpus and IOACAS corpus.<br /> * '''Database''': human singing/humming snippets (.wav) from all available corpora (excluding the query input being searched).<br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> To make algorithms able to share intermediate steps, participants are encouraged to submit separate tracker and matcher modules instead of integrated ones, which is according to Rainer Typke's suggestion. So trackers and matchers from different submissions could work together with the same pre-defined interface and thus for us it's possible to find the best combination.<br /> <br /> == Data ==<br /> Currently we have 2 publicly available corpora for QBSH:<br /> <br /> * Roger Jang's [http://mirlab.org/dataSet/public/MIR-QBSH-corpus.rar MIR-QBSH corpus] which is comprised of 4431 queries along with 48 ground-truth MIDI files. All queries are from the beginning of references. Manually labeled pitch for each recording is available. <br /> <br /> * [http://mirlab.org/dataSet/public/IOACAS_QBH.rar IOACAS corpus] comprised of 759 queries and 298 monophonic ground-truth MIDI files (with MIDI 0 or 1 format). There are no &quot;singing from beginning&quot; guarantee.<br /> <br /> The noise MIDI will be the 5000+ Essen collection(can be accessed from http://www.esac-data.org/).<br /> <br /> To build a large test set which can reflect real-world queries, it is suggested that every participant makes a contribution to the evaluation corpus. Sometimes this is hard in practice. So we shall adopt &quot;no hidden dataset&quot; policy if there are not enough user-contributed copora.<br /> <br /> == Evaluation Corpus Contribution ==<br /> Every participant will be asked to contribute 100~200 wave queries (8k 16bits) as well as the ground truth MIDI as test data. <br /> <br /> A simple tool for recording query data will be public soon. You may need to have .NET 2.0 or above installed in your system in order to run this program. The generated files conform to the format used in the IOACAS corpus. Of course you are also welcomed to use your own program to record the query data.<br /> <br /> If there are not enough user-contributed corpora, then we shall adopt &quot;no hidden dataset&quot; policy for QBSH task as usual.<br /> <br /> == Submission Format ==<br /> <br /> === Breakdown Version ===<br /> 1. Database indexing/building. Command format should look like this: <br /> <br /> indexing %dbMidi.list% %dir_workspace_root%<br /> <br /> where %dbMidi.list% is the input list of database midi files named as uniq_key.mid. For example: <br /> <br /> ./QBSH/midiDatabase/00001.mid<br /> ./QBSH/midiDatabase/00002.mid<br /> ./QBSH/midiDatabase/00003.mid<br /> ./QBSH/midiDatabase/00004.mid<br /> ...<br /> <br /> Output indexed files are placed into %dir_workspace_root%. (For task 2, %dbMidi.list% is in fact a list of wav files in the database.)<br /> <br /> 2. Pitch tracker. Command format: <br /> <br /> pitch_tracker %queryWave.list% %dir_query_pitch%<br /> <br /> where %queryWave.list% looks like <br /> <br /> queryWave/query_00001.wav<br /> queryWave/query_00002.wav<br /> queryWave/query_00003.wav<br /> ...<br /> <br /> Each input file dir_query/query_xxxxx.wav in %queryWave.list% outputs a corresponding transcription %dir_query_pitch%/query_xxxxx.pitch which gives the pitch sequence in midi note scale with the resolution of 10ms: <br /> <br /> 0<br /> 0<br /> 62.23<br /> 62.25<br /> 62.21<br /> ...<br /> <br /> Thus a query with x seconds should output a pitch file with 100*x lines. Places of silence/rest are set to be 0. <br /> <br /> 3. Pitch matcher. Command format: <br /> <br /> pitch_matcher %dbMidi.list% %queryPitch.list% %resultFile%<br /> <br /> where %queryPitch.list% looks like <br /> <br /> queryPitch/query_00001.pitch<br /> queryPitch/query_00002.pitch<br /> queryPitch/query_00003.pitch<br /> ...<br /> <br /> and the result file gives top-10 candidates(if has) for each query: <br /> <br /> queryPitch/query_00001.pitch: 00025 01003 02200 ... <br /> queryPitch/query_00002.pitch: 01547 02313 07653 ... <br /> queryPitch/query_00003.pitch: 03142 00320 00973 ... <br /> ...<br /> <br /> === Integrated Version ===<br /> If you want to pack everything together, the command format should be much simpler:<br /> <br /> qbshProgram %dbMidi.list% %queryWave.list% %resultFile% %dir_workspace_root%<br /> <br /> You can use %dir_workspace_root% to store any temporary indexing/database structures. The result file should have the same format as mentioned previously. (For task 2, %dbMidi.list% is in fact a list of wav files in the database to be retrieved.)<br /> <br /> === Packaging submissions ===<br /> All submissions should be statically linked to all libraries (the presence of <br /> dynamically linked libraries cannot be guarenteed).<br /> <br /> All submissions should include a README file including the following the <br /> information:<br /> <br /> * Command line calling format for all executables and an example formatted set of commands<br /> * Number of threads/cores used or whether this should be specified on the command line<br /> * Expected memory footprint<br /> * Expected runtime<br /> * Any required environments (and versions), e.g. python, java, bash, matlab.<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of particpants in this and other audio tasks,<br /> hard limits on the runtime of submissions are specified. <br /> <br /> A hard limit of 72 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.<br /> <br /> == Potential Participants ==</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2013:Query_by_Singing/Humming&diff=9151 2013-02-17T04:00:04Z

<p>Jyh-Shing Roger Jang: /* Subtask 1: Classic QBSH evaluation */</p> <hr /> <div>== Description ==<br /> <br /> The text of this section is copied from the 2010 page. Please add your comments and discussions for 2013. <br /> <br /> <br /> The goal of the Query-by-Singing/Humming (QBSH) task is the evaluation of MIR systems that take as query input queries sung or hummed by real-world users. More information can be found in:<br /> <br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2008:Query_by_Singing/Humming]]<br /> * [[2007:Query_by_Singing/Humming]]<br /> * [[2006:Query_by_Singing/Humming]]<br /> <br /> <br /> <br /> === Subtask 1: Classic QBSH evaluation ===<br /> This is the classic QBSH problem where we need to find the ground-truth midi from a user's singing or humming.<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from MIR-QBSH and IOACAS corpora described below.<br /> * '''Database''': ground-truth and noise MIDI files(which are monophonic). Comprised of ground-truth MIDIs from MIR-QBSH corpus (48), and IOACAS corpus (106), along with a cleaned version of Essen Database(2000+ MIDIs which are not available to the participator) <br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> === Subtask 2: Variants QBSH evaluation ===<br /> This is based on Prof. Downie's idea that queries are variants of &quot;ground-truth&quot; midi. In fact, this becomes more important since user-contributed singing/humming is an important part of the song database to be searched, as evidenced by the QBSH search service at [http://www.midomi.com/ www.midomi.com].<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from Roger Jang's corpus and ThinkIT corpus.<br /> * '''Database''': human singing/humming snippets (.wav) from all available corpora (excluding the query input being searched).<br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> To make algorithms able to share intermediate steps, participants are encouraged to submit separate tracker and matcher modules instead of integrated ones, which is according to Rainer Typke's suggestion. So trackers and matchers from different submissions could work together with the same pre-defined interface and thus for us it's possible to find the best combination.<br /> <br /> == Data ==<br /> Currently we have 2 publicly available corpora for QBSH:<br /> <br /> * Roger Jang's [http://mirlab.org/dataSet/public/MIR-QBSH-corpus.rar MIR-QBSH corpus] which is comprised of 4431 queries along with 48 ground-truth MIDI files. All queries are from the beginning of references. Manually labeled pitch for each recording is available. <br /> <br /> * [http://mirlab.org/dataSet/public/IOACAS_QBH.rar IOACAS corpus] comprised of 759 queries and 298 monophonic ground-truth MIDI files (with MIDI 0 or 1 format). There are no &quot;singing from beginning&quot; guarantee.<br /> <br /> The noise MIDI will be the 5000+ Essen collection(can be accessed from http://www.esac-data.org/).<br /> <br /> To build a large test set which can reflect real-world queries, it is suggested that every participant makes a contribution to the evaluation corpus. Sometimes this is hard in practice. So we shall adopt &quot;no hidden dataset&quot; policy if there are not enough user-contributed copora.<br /> <br /> == Evaluation Corpus Contribution ==<br /> Every participant will be asked to contribute 100~200 wave queries (8k 16bits) as well as the ground truth MIDI as test data. <br /> <br /> A simple tool for recording query data will be public soon. You may need to have .NET 2.0 or above installed in your system in order to run this program. The generated files conform to the format used in the ThinkIT corpus. Of course you are also welcomed to use your own program to record the query data.<br /> <br /> If there are not enough user-contributed corpora, then we shall adopt &quot;no hidden dataset&quot; policy for QBSH task as usual.<br /> <br /> == Submission Format ==<br /> <br /> === Breakdown Version ===<br /> 1. Database indexing/building. Command format should look like this: <br /> <br /> indexing %dbMidi.list% %dir_workspace_root%<br /> <br /> where %dbMidi.list% is the input list of database midi files named as uniq_key.mid. For example: <br /> <br /> ./QBSH/midiDatabase/00001.mid<br /> ./QBSH/midiDatabase/00002.mid<br /> ./QBSH/midiDatabase/00003.mid<br /> ./QBSH/midiDatabase/00004.mid<br /> ...<br /> <br /> Output indexed files are placed into %dir_workspace_root%. (For task 2, %dbMidi.list% is in fact a list of wav files in the database.)<br /> <br /> 2. Pitch tracker. Command format: <br /> <br /> pitch_tracker %queryWave.list% %dir_query_pitch%<br /> <br /> where %queryWave.list% looks like <br /> <br /> queryWave/query_00001.wav<br /> queryWave/query_00002.wav<br /> queryWave/query_00003.wav<br /> ...<br /> <br /> Each input file dir_query/query_xxxxx.wav in %queryWave.list% outputs a corresponding transcription %dir_query_pitch%/query_xxxxx.pitch which gives the pitch sequence in midi note scale with the resolution of 10ms: <br /> <br /> 0<br /> 0<br /> 62.23<br /> 62.25<br /> 62.21<br /> ...<br /> <br /> Thus a query with x seconds should output a pitch file with 100*x lines. Places of silence/rest are set to be 0. <br /> <br /> 3. Pitch matcher. Command format: <br /> <br /> pitch_matcher %dbMidi.list% %queryPitch.list% %resultFile%<br /> <br /> where %queryPitch.list% looks like <br /> <br /> queryPitch/query_00001.pitch<br /> queryPitch/query_00002.pitch<br /> queryPitch/query_00003.pitch<br /> ...<br /> <br /> and the result file gives top-10 candidates(if has) for each query: <br /> <br /> queryPitch/query_00001.pitch: 00025 01003 02200 ... <br /> queryPitch/query_00002.pitch: 01547 02313 07653 ... <br /> queryPitch/query_00003.pitch: 03142 00320 00973 ... <br /> ...<br /> <br /> === Integrated Version ===<br /> If you want to pack everything together, the command format should be much simpler:<br /> <br /> qbshProgram %dbMidi.list% %queryWave.list% %resultFile% %dir_workspace_root%<br /> <br /> You can use %dir_workspace_root% to store any temporary indexing/database structures. The result file should have the same format as mentioned previously. (For task 2, %dbMidi.list% is in fact a list of wav files in the database to be retrieved.)<br /> <br /> === Packaging submissions ===<br /> All submissions should be statically linked to all libraries (the presence of <br /> dynamically linked libraries cannot be guarenteed).<br /> <br /> All submissions should include a README file including the following the <br /> information:<br /> <br /> * Command line calling format for all executables and an example formatted set of commands<br /> * Number of threads/cores used or whether this should be specified on the command line<br /> * Expected memory footprint<br /> * Expected runtime<br /> * Any required environments (and versions), e.g. python, java, bash, matlab.<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of particpants in this and other audio tasks,<br /> hard limits on the runtime of submissions are specified. <br /> <br /> A hard limit of 72 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.<br /> <br /> == Potential Participants ==</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2013:Query_by_Singing/Humming&diff=9150 2013-02-17T03:51:04Z

<p>Jyh-Shing Roger Jang: /* Subtask 1: Classic QBSH evaluation */</p> <hr /> <div>== Description ==<br /> <br /> The text of this section is copied from the 2010 page. Please add your comments and discussions for 2013. <br /> <br /> <br /> The goal of the Query-by-Singing/Humming (QBSH) task is the evaluation of MIR systems that take as query input queries sung or hummed by real-world users. More information can be found in:<br /> <br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2008:Query_by_Singing/Humming]]<br /> * [[2007:Query_by_Singing/Humming]]<br /> * [[2006:Query_by_Singing/Humming]]<br /> <br /> <br /> <br /> === Subtask 1: Classic QBSH evaluation ===<br /> This is the classic QBSH problem where we need to find the ground-truth midi from a user's singing or humming.<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from two corpora described below.<br /> * '''Database''': ground-truth and noise MIDI files(which are monophonic). Comprised of 48+106 Roger Jang's and ThinkIT's ground-truth along with a cleaned version of Essen Database(2000+ MIDIs which are used last year) <br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> === Subtask 2: Variants QBSH evaluation ===<br /> This is based on Prof. Downie's idea that queries are variants of &quot;ground-truth&quot; midi. In fact, this becomes more important since user-contributed singing/humming is an important part of the song database to be searched, as evidenced by the QBSH search service at [http://www.midomi.com/ www.midomi.com].<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from Roger Jang's corpus and ThinkIT corpus.<br /> * '''Database''': human singing/humming snippets (.wav) from all available corpora (excluding the query input being searched).<br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> To make algorithms able to share intermediate steps, participants are encouraged to submit separate tracker and matcher modules instead of integrated ones, which is according to Rainer Typke's suggestion. So trackers and matchers from different submissions could work together with the same pre-defined interface and thus for us it's possible to find the best combination.<br /> <br /> == Data ==<br /> Currently we have 2 publicly available corpora for QBSH:<br /> <br /> * Roger Jang's [http://mirlab.org/dataSet/public/MIR-QBSH-corpus.rar MIR-QBSH corpus] which is comprised of 4431 queries along with 48 ground-truth MIDI files. All queries are from the beginning of references. Manually labeled pitch for each recording is available. <br /> <br /> * [http://mirlab.org/dataSet/public/IOACAS_QBH.rar IOACAS corpus] comprised of 759 queries and 298 monophonic ground-truth MIDI files (with MIDI 0 or 1 format). There are no &quot;singing from beginning&quot; guarantee.<br /> <br /> The noise MIDI will be the 5000+ Essen collection(can be accessed from http://www.esac-data.org/).<br /> <br /> To build a large test set which can reflect real-world queries, it is suggested that every participant makes a contribution to the evaluation corpus. Sometimes this is hard in practice. So we shall adopt &quot;no hidden dataset&quot; policy if there are not enough user-contributed copora.<br /> <br /> == Evaluation Corpus Contribution ==<br /> Every participant will be asked to contribute 100~200 wave queries (8k 16bits) as well as the ground truth MIDI as test data. <br /> <br /> A simple tool for recording query data will be public soon. You may need to have .NET 2.0 or above installed in your system in order to run this program. The generated files conform to the format used in the ThinkIT corpus. Of course you are also welcomed to use your own program to record the query data.<br /> <br /> If there are not enough user-contributed corpora, then we shall adopt &quot;no hidden dataset&quot; policy for QBSH task as usual.<br /> <br /> == Submission Format ==<br /> <br /> === Breakdown Version ===<br /> 1. Database indexing/building. Command format should look like this: <br /> <br /> indexing %dbMidi.list% %dir_workspace_root%<br /> <br /> where %dbMidi.list% is the input list of database midi files named as uniq_key.mid. For example: <br /> <br /> ./QBSH/midiDatabase/00001.mid<br /> ./QBSH/midiDatabase/00002.mid<br /> ./QBSH/midiDatabase/00003.mid<br /> ./QBSH/midiDatabase/00004.mid<br /> ...<br /> <br /> Output indexed files are placed into %dir_workspace_root%. (For task 2, %dbMidi.list% is in fact a list of wav files in the database.)<br /> <br /> 2. Pitch tracker. Command format: <br /> <br /> pitch_tracker %queryWave.list% %dir_query_pitch%<br /> <br /> where %queryWave.list% looks like <br /> <br /> queryWave/query_00001.wav<br /> queryWave/query_00002.wav<br /> queryWave/query_00003.wav<br /> ...<br /> <br /> Each input file dir_query/query_xxxxx.wav in %queryWave.list% outputs a corresponding transcription %dir_query_pitch%/query_xxxxx.pitch which gives the pitch sequence in midi note scale with the resolution of 10ms: <br /> <br /> 0<br /> 0<br /> 62.23<br /> 62.25<br /> 62.21<br /> ...<br /> <br /> Thus a query with x seconds should output a pitch file with 100*x lines. Places of silence/rest are set to be 0. <br /> <br /> 3. Pitch matcher. Command format: <br /> <br /> pitch_matcher %dbMidi.list% %queryPitch.list% %resultFile%<br /> <br /> where %queryPitch.list% looks like <br /> <br /> queryPitch/query_00001.pitch<br /> queryPitch/query_00002.pitch<br /> queryPitch/query_00003.pitch<br /> ...<br /> <br /> and the result file gives top-10 candidates(if has) for each query: <br /> <br /> queryPitch/query_00001.pitch: 00025 01003 02200 ... <br /> queryPitch/query_00002.pitch: 01547 02313 07653 ... <br /> queryPitch/query_00003.pitch: 03142 00320 00973 ... <br /> ...<br /> <br /> === Integrated Version ===<br /> If you want to pack everything together, the command format should be much simpler:<br /> <br /> qbshProgram %dbMidi.list% %queryWave.list% %resultFile% %dir_workspace_root%<br /> <br /> You can use %dir_workspace_root% to store any temporary indexing/database structures. The result file should have the same format as mentioned previously. (For task 2, %dbMidi.list% is in fact a list of wav files in the database to be retrieved.)<br /> <br /> === Packaging submissions ===<br /> All submissions should be statically linked to all libraries (the presence of <br /> dynamically linked libraries cannot be guarenteed).<br /> <br /> All submissions should include a README file including the following the <br /> information:<br /> <br /> * Command line calling format for all executables and an example formatted set of commands<br /> * Number of threads/cores used or whether this should be specified on the command line<br /> * Expected memory footprint<br /> * Expected runtime<br /> * Any required environments (and versions), e.g. python, java, bash, matlab.<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of particpants in this and other audio tasks,<br /> hard limits on the runtime of submissions are specified. <br /> <br /> A hard limit of 72 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.<br /> <br /> == Potential Participants ==</div>

Jyh-Shing Roger Jang https://music-ir.org/mirex/w/index.php?title=2013:Query_by_Singing/Humming&diff=9149 2013-02-17T03:48:03Z

<p>Jyh-Shing Roger Jang: /* Description */</p> <hr /> <div>== Description ==<br /> <br /> The text of this section is copied from the 2010 page. Please add your comments and discussions for 2013. <br /> <br /> <br /> The goal of the Query-by-Singing/Humming (QBSH) task is the evaluation of MIR systems that take as query input queries sung or hummed by real-world users. More information can be found in:<br /> <br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2009:Query_by_Singing/Humming]]<br /> * [[2008:Query_by_Singing/Humming]]<br /> * [[2007:Query_by_Singing/Humming]]<br /> * [[2006:Query_by_Singing/Humming]]<br /> <br /> <br /> <br /> === Subtask 1: Classic QBSH evaluation ===<br /> This is the classic QBSH problem where we need to find the ground-truth midi from a user's singing or humming.<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from Roger Jang's corpus and ThinkIT corpus.<br /> * '''Database''': ground-truth and noise MIDI files(which are monophonic). Comprised of 48+106 Roger Jang's and ThinkIT's ground-truth along with a cleaned version of Essen Database(2000+ MIDIs which are used last year) <br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> === Subtask 2: Variants QBSH evaluation ===<br /> This is based on Prof. Downie's idea that queries are variants of &quot;ground-truth&quot; midi. In fact, this becomes more important since user-contributed singing/humming is an important part of the song database to be searched, as evidenced by the QBSH search service at [http://www.midomi.com/ www.midomi.com].<br /> * '''Queries''': human singing/humming snippets (.wav). Queries are from Roger Jang's corpus and ThinkIT corpus.<br /> * '''Database''': human singing/humming snippets (.wav) from all available corpora (excluding the query input being searched).<br /> * '''Output''': top-10 candidate list. <br /> * '''Evaluation''': Top-10 hit rate (1 point is scored for a hit in the top 10 and 0 is scored otherwise).<br /> <br /> To make algorithms able to share intermediate steps, participants are encouraged to submit separate tracker and matcher modules instead of integrated ones, which is according to Rainer Typke's suggestion. So trackers and matchers from different submissions could work together with the same pre-defined interface and thus for us it's possible to find the best combination.<br /> <br /> == Data ==<br /> Currently we have 2 publicly available corpora for QBSH:<br /> <br /> * Roger Jang's [http://mirlab.org/dataSet/public/MIR-QBSH-corpus.rar MIR-QBSH corpus] which is comprised of 4431 queries along with 48 ground-truth MIDI files. All queries are from the beginning of references. Manually labeled pitch for each recording is available. <br /> <br /> * [http://mirlab.org/dataSet/public/IOACAS_QBH.rar IOACAS corpus] comprised of 759 queries and 298 monophonic ground-truth MIDI files (with MIDI 0 or 1 format). There are no &quot;singing from beginning&quot; guarantee.<br /> <br /> The noise MIDI will be the 5000+ Essen collection(can be accessed from http://www.esac-data.org/).<br /> <br /> To build a large test set which can reflect real-world queries, it is suggested that every participant makes a contribution to the evaluation corpus. Sometimes this is hard in practice. So we shall adopt &quot;no hidden dataset&quot; policy if there are not enough user-contributed copora.<br /> <br /> == Evaluation Corpus Contribution ==<br /> Every participant will be asked to contribute 100~200 wave queries (8k 16bits) as well as the ground truth MIDI as test data. <br /> <br /> A simple tool for recording query data will be public soon. You may need to have .NET 2.0 or above installed in your system in order to run this program. The generated files conform to the format used in the ThinkIT corpus. Of course you are also welcomed to use your own program to record the query data.<br /> <br /> If there are not enough user-contributed corpora, then we shall adopt &quot;no hidden dataset&quot; policy for QBSH task as usual.<br /> <br /> == Submission Format ==<br /> <br /> === Breakdown Version ===<br /> 1. Database indexing/building. Command format should look like this: <br /> <br /> indexing %dbMidi.list% %dir_workspace_root%<br /> <br /> where %dbMidi.list% is the input list of database midi files named as uniq_key.mid. For example: <br /> <br /> ./QBSH/midiDatabase/00001.mid<br /> ./QBSH/midiDatabase/00002.mid<br /> ./QBSH/midiDatabase/00003.mid<br /> ./QBSH/midiDatabase/00004.mid<br /> ...<br /> <br /> Output indexed files are placed into %dir_workspace_root%. (For task 2, %dbMidi.list% is in fact a list of wav files in the database.)<br /> <br /> 2. Pitch tracker. Command format: <br /> <br /> pitch_tracker %queryWave.list% %dir_query_pitch%<br /> <br /> where %queryWave.list% looks like <br /> <br /> queryWave/query_00001.wav<br /> queryWave/query_00002.wav<br /> queryWave/query_00003.wav<br /> ...<br /> <br /> Each input file dir_query/query_xxxxx.wav in %queryWave.list% outputs a corresponding transcription %dir_query_pitch%/query_xxxxx.pitch which gives the pitch sequence in midi note scale with the resolution of 10ms: <br /> <br /> 0<br /> 0<br /> 62.23<br /> 62.25<br /> 62.21<br /> ...<br /> <br /> Thus a query with x seconds should output a pitch file with 100*x lines. Places of silence/rest are set to be 0. <br /> <br /> 3. Pitch matcher. Command format: <br /> <br /> pitch_matcher %dbMidi.list% %queryPitch.list% %resultFile%<br /> <br /> where %queryPitch.list% looks like <br /> <br /> queryPitch/query_00001.pitch<br /> queryPitch/query_00002.pitch<br /> queryPitch/query_00003.pitch<br /> ...<br /> <br /> and the result file gives top-10 candidates(if has) for each query: <br /> <br /> queryPitch/query_00001.pitch: 00025 01003 02200 ... <br /> queryPitch/query_00002.pitch: 01547 02313 07653 ... <br /> queryPitch/query_00003.pitch: 03142 00320 00973 ... <br /> ...<br /> <br /> === Integrated Version ===<br /> If you want to pack everything together, the command format should be much simpler:<br /> <br /> qbshProgram %dbMidi.list% %queryWave.list% %resultFile% %dir_workspace_root%<br /> <br /> You can use %dir_workspace_root% to store any temporary indexing/database structures. The result file should have the same format as mentioned previously. (For task 2, %dbMidi.list% is in fact a list of wav files in the database to be retrieved.)<br /> <br /> === Packaging submissions ===<br /> All submissions should be statically linked to all libraries (the presence of <br /> dynamically linked libraries cannot be guarenteed).<br /> <br /> All submissions should include a README file including the following the <br /> information:<br /> <br /> * Command line calling format for all executables and an example formatted set of commands<br /> * Number of threads/cores used or whether this should be specified on the command line<br /> * Expected memory footprint<br /> * Expected runtime<br /> * Any required environments (and versions), e.g. python, java, bash, matlab.<br /> <br /> == Time and hardware limits ==<br /> Due to the potentially high number of particpants in this and other audio tasks,<br /> hard limits on the runtime of submissions are specified. <br /> <br /> A hard limit of 72 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.<br /> <br /> == Potential Participants ==</div>

Jyh-Shing Roger Jang