MIREX Wiki - User contributions [en]

2014:Audio Beat Tracking

2014-06-17T19:58:10Z

Jose R. Zapata: /* Potential Participants */

== Description ==
The text of this section was copied from the 2012 Wiki. Please add your comments and discussion at the bottom of this page.

The aim of the automatic beat tracking task is to track each beat locations in a collection of sound files. Unlike the Audio Tempo Extraction task, which aim is to detect tempi for each file, the beat tracking task aims at detecting all beat locations in recordings. The algorithms will be evaluated in terms of their accuracy in predicting beat locations annotated by a group of listeners.

== Data ==
=== Collections ===
The original 2006 dataset contains 160 30-second excerpts (WAV format) used for the Audio Tempo and Beat contests in 2006. Beat locations have been annotated in each excerpt by 40 different listeners (39 listeners for a few excerpts. The length of each excerpt is 30 seconds. These audio recordings were selected to provide a stable tempo value, a wide distribution of tempi values, and a large variety of instrumentation and musical styles. About 20% of the files contain non-binary meters, and a small number of examples contain changing meters. One disadvantage of using this set for beat tracking is that the tempi are rather stable and this set will not test beat-tracking algorithms in their ability to track tempo changes.

The second collection is comprised of 367 Chopin Mazurkas, represented as full audio tracks (WAV format). The Mazurka dataset contains tempo changes so it will evaluate the ability of algorithms to track these.

The third collection was assembled and donated in 2012. This dataset contains 217 excerpts around 40s each, of which 19 are "easy" and the remaining 198 are "hard". The harder excerpts were drawn from the following musical styles: Romantic music, ﬁlm soundtracks, blues, chanson and solo guitar.

This dataset has been designed for radically new techniques which can contend with challenging beat tracking situations like: quiet accompaniment, expressive timing, changes in time signature, slow tempo, poor sound quality etc. So, if your beat tracker likes a 4/4 time-signature with a steady tempo and needs clear percussive onsets, don't expect it to do very well!
But don't be deterred, this is for the good of beat tracking.

You can read in detail about how the dataset was made here:
[http://dx.doi.org/10.1109/TASL.2012.2205244 ''Selective Sampling for Beat Tracking Evaluation'']

=== Audio Formats ===

The data are monophonic sound files, with the associated onset times and data about the annotation robustness.

* CD-quality (PCM, 16-bit, 44100 Hz)
* single channel (mono)
* file length between 2 and 36 seconds (total time: 14 minutes)

== Submission Format ==
Submissions to this task will have to conform to a specified format detailed below. Submissions should be packaged and contain at least two files: The algorithm itself and a README containing contact information and detailing, in full, the use of the algorithm.

=== Input Data ===
Participating algorithms will have to read audio in the following format:

* Sample rate: 44.1 KHz
* Sample size: 16 bit
* Number of channels: 1 (mono)
* Encoding: WAV

=== Output Data ===

The beat tracking algorithms will return beat-times in an ASCII text file for each input .wav audio file. The specification of this output file is immediately below.

=== Output File Format (Audio Beat tracking) ===

The Beat Tracking output file format is an ASCII text format. Each beat time is specified, in seconds, on its own line. Specifically,

<beat time(in seconds)>\n

where \n denotes the end of line. The < and > characters are not included. An example output file would look something like:

0.243
0.486
0.729

=== Algorithm Calling Format ===

The submitted algorithm must take as arguments a SINGLE .wav file to perform the onset detection on as well as the full output path and filename of the output file. The ability to specify the output path and file name is essential. Denoting the input .wav file path and name as %input and the output file path and name as %output, a program called foobar could be called from the command-line as follows:

foobar %input %output
foobar -i %input -o %output

Moreover, if your submission takes additional parameters, such as a detection threshold, foobar could be called like:

foobar .1 %input %output
foobar -param1 .1 -i %input -o %output

If your submission is in MATLAB, it should be submitted as a function. Once again, the function must contain String inputs for the full path and names of the input and output files. Parameters could also be specified as input arguments of the function. For example:

foobar('%input','%output')
foobar(.1,'%input','%output')

=== README File ===

A README file accompanying each submission should contain explicit instructions on how to to run the program (as well as contact information, etc.). In particular, each command line to run should be specified, using %input for the input sound file and %output for the resulting text file.

For instance, to test the program foobar with different values for parameters param1, the README file would look like:

foobar -param1 .1 -i %input -o %output
foobar -param1 .15 -i %input -o %output
foobar -param1 .2 -i %input -o %output
foobar -param1 .25 -i %input -o %output
foobar -param1 .3 -i %input -o %output
...

For a submission using MATLAB, the README file could look like:

matlab -r "foobar(.1,'%input','%output');quit;"
matlab -r "foobar(.15,'%input','%output');quit;"
matlab -r "foobar(.2,'%input','%output');quit;"
matlab -r "foobar(.25,'%input','%output');quit;"
matlab -r "foobar(.3,'%input','%output');quit;"
...

The different command lines to evaluate the performance of each parameter set over the whole database will be generated automatically from each line in the README file containing both '%input' and '%output' strings.

== Evaluation Procedures ==

The evaluation methods are taken from the beat evaluation toolbox and
are described in the following technical report:

M. E. P. Davies, N. Degara and M. D. Plumbley. "Evaluation methods for musical audio beat tracking algorithms". [http://www.elec.qmul.ac.uk/people/markp/2009/DaviesDegaraPlumbley09-evaluation-tr.pdf ''Technical Report C4DM-TR-09-06'']. This link now works! :)

For further details on the specifics of the methods please refer to the
paper. However, here is a brief summary with appropriate references:

*'''F-measure''' - the standard calculation as used in onset evaluation but
with a 70ms window.

S. Dixon, "Onset detection revisited," in ''Proceedings of 9th
International Conference on Digital Audio Effects (DAFx)'', Montreal,
Canada, pp. 133-137, 2006.

S. Dixon, "Evaluation of audio beat tracking system beatroot," ''Journal
of New Music Research'', vol. 36, no. 1, pp. 39-51, 2007.

*'''Cemgil''' - beat accuracy is calculated using a Gaussian error function
with 40ms standard deviation.

A. T. Cemgil, B. Kappen, P. Desain, and H. Honing, "On tempo tracking:
Tempogram representation and Kalman filtering," ''Journal Of New Music
Research'', vol. 28, no. 4, pp. 259-273, 2001

*'''Goto''' - binary decision of correct or incorrect tracking based on
statistical properties of a beat error sequence.

M. Goto and Y. Muraoka, "Issues in evaluating beat tracking systems," in
''Working Notes of the IJCAI-97 Workshop on Issues in AI and Music -
Evaluation and Assessment'', 1997, pp. 9-16.

*'''PScore''' - McKinney's impulse train cross-correlation method as used in
2006.

M. F. McKinney, D. Moelants, M. E. P. Davies, and A. Klapuri,
"Evaluation of audio beat tracking and music tempo extraction
algorithms," ''Journal of New Music Research'', vol. 36, no. 1, pp. 1-16,
2007.

*'''CMLc''', '''CMLt''', '''AMLc''', '''AMLt''' - continuity-based evaluation methods based on
the longest continuously correctly tracked section.

S. Hainsworth, "Techniques for the automated analysis of musical audio,"
Ph.D. dissertation, Department of Engineering, Cambridge University,
2004.

A. P. Klapuri, A. Eronen, and J. Astola, "Analysis of the meter of
acoustic musical signals," IEEE Transactions on Audio, Speech and
Language Processing, vol. 14, no. 1, pp. 342-355, 2006.

*'''D''', '''Dg''' - information based criteria based on analysis of a beat error
histogram (note the results are measured in 'bits' and not percentages),
see the technical report for a description.

== Relevant Development Collections ==
You can find it here:

https://www.music-ir.org/evaluation/MIREX/data/2006/beat/

User: beattrack Password: b34trx

https://www.music-ir.org/evaluation/MIREX/data/2006/tempo/

User: tempo Password: t3mp0

Data has been uploaded in both .tgz and .zip format.

== Time and hardware limits ==
Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions will be imposed.

A hard limit of 12 hours will be imposed on analysis times. Submissions exceeding this limit may not receive a result.

== Potential Participants ==
name / email

Jose R. Zapata / joser.zapata (at) upb.edu.co

== Discussion ==
name / email

2014:Audio Downbeat Estimation

2014-06-17T19:57:11Z

Jose R. Zapata: /* Potential Participants */

== Description ==

'''This task is new for 2014!'''

This text has been adapted from the Audio Beat Tracking Wiki page. Please add your comments and discussion at the bottom of this page.

The aim of the automatic downbeat estimation task is to identify the locations of downbeats in a collection of sound files. While this is similar to the Audio Beat Tracking task, here the aim is to find the first beat of each bar (measure) rather than all beat times. Algorithms are '''not''' required to estimate beat times or time-signature in addition to downbeats.

Submitted algorithms will be evaluated in terms of their accuracy in finding downbeat locations (only) as annotated by musical experts across several diverse datasets.

== Data ==

=== Collections ===
'''Ballroom'''
The ballroom dataset contains eight different dance styles (Cha Cha, Jive, Quickstep, Rumba, Samba, Tango, Viennese Waltz and Waltz). It consists of '''697''' excerpts of 30s in duration.
The dataset contains two different meters 3/4 and 4/4 - but all pieces have constant meter. For further information see Dixon et al (2004) and Krebs et al (2013).
Note, we are using the ground truth annotations from Krebs et al. (2013) available at https://github.com/CPJKU/BallroomAnnotations

'''Isophonics (Beatles only)'''
The Beatles dataset from the Centre for Digital Music at Queen Mary, University of London (http://www.isophonics.net/), as also used for Audio Chord Estimation in MIREX for many years.
This dataset contains '''179''' complete songs (all except Revolution 9), the majority of which are in 4/4.
For further information see Mauch et al (2009).

'''Turkish Data'''
The Turkish corpus is an extended version of the annotated data used in Srinivasamurthy et al. (2014). It includes '''82''' excerpts of one
minute length each, and each piece belongs to one of three
rhythm classes that are referred to as usul in Turkish Art
music. 32 pieces are in the 9/8-usul Aksak, 20 pieces
in the 10/8-usul Curcuna, and 30 samples in the 8/8-usul
Düyek.

'''Cretan Data'''
The corpus of Cretan music consists of '''42''' full length pieces of Cretan leaping dances. While there are several dances that differ in terms of their steps, the differences in
the sound are most noticeable in the melodic content, and all pieces can be considered to belong to one rhythmic style. All these dances are usually notated using a 2/4 time signature,
and the accompanying rhythmical patterns are usually played on a Cretan lute. While a variety of rhythmic patterns exist, they do not relate to a specific dance and can be
assumed to occur in all of the 42 songs in this corpus.

'''Carnatic Data'''
The Carnatic music dataset is a subset of the CompMusic [http://compmusic.upf.edu/carnatic-rhythm-dataset Carnatic Music Rhythm Dataset]. It includes '''118''' two minute long excerpts spanning four most commonly used tālas (the rhythmic framework of Carnatic music, consisting of time cycles) of Carnatic music. There are 30 examples in each of ādi tāla (8 beats/cycle), rūpaka tāla (3 beats/cycle) and miśra chāpu tāla (7 beats/cycle), and 28 examples in khaṇḍa chāpu tāla (5 beats/cycle). The beats of the tāla in miśra chāpu and khaṇḍa chāpu are non-uniform, but for consistency with other datasets, a uniform beat pulse was obtained by interpolating the non-uniformly spaced beat locations. The recordings consist of both vocal and instrumental music recordings representative of the present day performance practice. All recordings contain percussion accompaniment, mainly the Mridangam.

'''HJDB''' (to be confirmed)
The HJDB dataset contains '''236''' excerpts of Hardcore, Jungle and Drum and Bass music between 30s and 2 minutes in length. All excerpts are in 4/4 and have a constant tempo.
For further information see Hockman et al (2012).

In total this makes '''1354''' excerpts (of which 259 are full length songs).

=== Audio Formats ===

The data are monophonic sound files

* CD-quality (PCM, 16-bit, 44100 Hz) for all except Ballroom (originally lower quality, but resampled to 44100 Hz)
* single channel (mono)

== Submission Format ==
Submissions to this task will have to conform to a specified format detailed below. Submissions should be packaged and contain at least two files: The algorithm itself and a README containing contact information and detailing, in full, the use of the algorithm.

=== Input Data ===
Participating algorithms will have to read audio in the following format:

* Sample rate: 44.1 KHz
* Sample size: 16 bit
* Number of channels: 1 (mono)
* Encoding: WAV

=== Output Data ===

The downbeat estimation algorithms will return downbeat times in an ASCII text file for each input .wav audio file. The specification of this output file is immediately below.

=== Output File Format (Audio Downbeat Estimation) ===

The downbeat output file format is an ASCII text format. Each downbeat time is specified, in seconds, on its own line. Specifically,

<downbeat time (in seconds)>\n

where \n denotes the end of line. The < and > characters are not included. An example output file would look something like:

0.243
1.486
2.729

=== Algorithm Calling Format ===

The submitted algorithm must take as arguments a SINGLE .wav file to perform the downbeat estimation as well as the full output path and filename of the output file. The ability to specify the output path and file name is essential. Denoting the input .wav file path and name as %input and the output file path and name as %output, a program called foobar could be called from the command-line as follows:

foobar %input %output
foobar -i %input -o %output

Moreover, if your submission takes additional parameters, such as a detection threshold, foobar could be called like:

foobar .1 %input %output
foobar -param1 .1 -i %input -o %output

If your submission is in MATLAB, it should be submitted as a function. Once again, the function must contain String inputs for the full path and names of the input and output files. Parameters could also be specified as input arguments of the function. For example:

foobar('%input','%output')
foobar(.1,'%input','%output')

=== README File ===

A README file accompanying each submission should contain explicit instructions on how to to run the program (as well as contact information, etc.). In particular, each command line to run should be specified, using %input for the input sound file and %output for the resulting text file.

For instance, to test the program foobar with different values for parameters param1, the README file would look like:

foobar -param1 .1 -i %input -o %output
foobar -param1 .15 -i %input -o %output
foobar -param1 .2 -i %input -o %output
foobar -param1 .25 -i %input -o %output
foobar -param1 .3 -i %input -o %output
...

For a submission using MATLAB, the README file could look like:

matlab -r "foobar(.1,'%input','%output');quit;"
matlab -r "foobar(.15,'%input','%output');quit;"
matlab -r "foobar(.2,'%input','%output');quit;"
matlab -r "foobar(.25,'%input','%output');quit;"
matlab -r "foobar(.3,'%input','%output');quit;"
...

The different command lines to evaluate the performance of each parameter set over the whole database will be generated automatically from each line in the README file containing both '%input' and '%output' strings.

== Evaluation Procedures ==

For the evalution procedure we will use
*'''F-measure''' - the standard calculation as used in onset and beat tracking evaluation with a +/-70ms window, see Dixon (2007).

Given the high diversity of musical styles included in the task, results will be reported per each invidiual dataset.

== Time and hardware limits ==
Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions will be imposed.

A hard limit of 24 hours will be imposed on analysis times. Submissions exceeding this limit may not receive a result.

== Potential Participants ==
name / email

Jose R. Zapata / joser.zapata (at) upb.edu.co

== Discussion ==
name / email

= Bibliography =

S. Dixon, F. Gouyon and G. Widmer, [http://ismir2004.ismir.net/proceedings/p093-page-509-paper165.pdf Towards Characterisation of Music via Rhythmic Patterns], In Proceedings of the 5th International Conference on Music Information Retrieval (ISMIR 2004), pp 509-516.

S. Dixon, [http://www.eecs.qmul.ac.uk/~simond/pub/2007/jnmr07.pdf Evaluation of audio beat tracking system BeatRoot], Journal of New Music Research, vol. 36, no. 1, pp. 39-51, 2007.

J. A. Hockman, M. E. P. Davies, I. Fujinaga.[http://ismir2012.ismir.net/event/papers/169-ismir-2012.pdf ONE IN THE JUNGLE: Downbeat Detection in Hardcore, Jungle, and Drum and Bass], In Proceedings of 13th International Society for Music Information Retrieval Conference (ISMIR), Porto, Portugal pp. 169-174, 2012.

F. Krebs, S. Boeck, and G. Widmer, [http://www.cp.jku.at/research/papers/Krebs_etal_ISMIR_2013.pdf Rhythmic Pattern Modeling for Beat- and Downbeat Tracking in Musical Audio], In Proceedings of 14th International Society for Music Information Retrieval Conference (ISMIR), Curitiba, Brazil, 2013.

M. Mauch, C. Cannam, M. E. P. Davies, S. Dixon, C. Harte, S. Kolozali and D. Tidhar, [http://ismir2009.ismir.net/proceedings/LBD-18.pdf OMRAS2 Metadata Project 2009], Late-breaking session at the 10th International Conference on Music Information Retrieval, 2009.

A. Srinivasamurthy, A. Holzapfel, and Xavier Serra, [http://www.tandfonline.com/doi/full/10.1080/09298215.2013.879902 In Search of Automatic Rhythm Analysis Methods for Turkish and Indian Art Music], Journal of New Music Research, vol. 43, no. 1, pp. 94-114, 2014.

2014:Audio Downbeat Estimation

2014-06-17T19:56:51Z

Jose R. Zapata: /* Potential Participants */

== Description ==

'''This task is new for 2014!'''

This text has been adapted from the Audio Beat Tracking Wiki page. Please add your comments and discussion at the bottom of this page.

The aim of the automatic downbeat estimation task is to identify the locations of downbeats in a collection of sound files. While this is similar to the Audio Beat Tracking task, here the aim is to find the first beat of each bar (measure) rather than all beat times. Algorithms are '''not''' required to estimate beat times or time-signature in addition to downbeats.

Submitted algorithms will be evaluated in terms of their accuracy in finding downbeat locations (only) as annotated by musical experts across several diverse datasets.

== Data ==

=== Collections ===
'''Ballroom'''
The ballroom dataset contains eight different dance styles (Cha Cha, Jive, Quickstep, Rumba, Samba, Tango, Viennese Waltz and Waltz). It consists of '''697''' excerpts of 30s in duration.
The dataset contains two different meters 3/4 and 4/4 - but all pieces have constant meter. For further information see Dixon et al (2004) and Krebs et al (2013).
Note, we are using the ground truth annotations from Krebs et al. (2013) available at https://github.com/CPJKU/BallroomAnnotations

'''Isophonics (Beatles only)'''
The Beatles dataset from the Centre for Digital Music at Queen Mary, University of London (http://www.isophonics.net/), as also used for Audio Chord Estimation in MIREX for many years.
This dataset contains '''179''' complete songs (all except Revolution 9), the majority of which are in 4/4.
For further information see Mauch et al (2009).

'''Turkish Data'''
The Turkish corpus is an extended version of the annotated data used in Srinivasamurthy et al. (2014). It includes '''82''' excerpts of one
minute length each, and each piece belongs to one of three
rhythm classes that are referred to as usul in Turkish Art
music. 32 pieces are in the 9/8-usul Aksak, 20 pieces
in the 10/8-usul Curcuna, and 30 samples in the 8/8-usul
Düyek.

'''Cretan Data'''
The corpus of Cretan music consists of '''42''' full length pieces of Cretan leaping dances. While there are several dances that differ in terms of their steps, the differences in
the sound are most noticeable in the melodic content, and all pieces can be considered to belong to one rhythmic style. All these dances are usually notated using a 2/4 time signature,
and the accompanying rhythmical patterns are usually played on a Cretan lute. While a variety of rhythmic patterns exist, they do not relate to a specific dance and can be
assumed to occur in all of the 42 songs in this corpus.

'''Carnatic Data'''
The Carnatic music dataset is a subset of the CompMusic [http://compmusic.upf.edu/carnatic-rhythm-dataset Carnatic Music Rhythm Dataset]. It includes '''118''' two minute long excerpts spanning four most commonly used tālas (the rhythmic framework of Carnatic music, consisting of time cycles) of Carnatic music. There are 30 examples in each of ādi tāla (8 beats/cycle), rūpaka tāla (3 beats/cycle) and miśra chāpu tāla (7 beats/cycle), and 28 examples in khaṇḍa chāpu tāla (5 beats/cycle). The beats of the tāla in miśra chāpu and khaṇḍa chāpu are non-uniform, but for consistency with other datasets, a uniform beat pulse was obtained by interpolating the non-uniformly spaced beat locations. The recordings consist of both vocal and instrumental music recordings representative of the present day performance practice. All recordings contain percussion accompaniment, mainly the Mridangam.

'''HJDB''' (to be confirmed)
The HJDB dataset contains '''236''' excerpts of Hardcore, Jungle and Drum and Bass music between 30s and 2 minutes in length. All excerpts are in 4/4 and have a constant tempo.
For further information see Hockman et al (2012).

In total this makes '''1354''' excerpts (of which 259 are full length songs).

=== Audio Formats ===

The data are monophonic sound files

* CD-quality (PCM, 16-bit, 44100 Hz) for all except Ballroom (originally lower quality, but resampled to 44100 Hz)
* single channel (mono)

== Submission Format ==
Submissions to this task will have to conform to a specified format detailed below. Submissions should be packaged and contain at least two files: The algorithm itself and a README containing contact information and detailing, in full, the use of the algorithm.

=== Input Data ===
Participating algorithms will have to read audio in the following format:

* Sample rate: 44.1 KHz
* Sample size: 16 bit
* Number of channels: 1 (mono)
* Encoding: WAV

=== Output Data ===

The downbeat estimation algorithms will return downbeat times in an ASCII text file for each input .wav audio file. The specification of this output file is immediately below.

=== Output File Format (Audio Downbeat Estimation) ===

The downbeat output file format is an ASCII text format. Each downbeat time is specified, in seconds, on its own line. Specifically,

<downbeat time (in seconds)>\n

where \n denotes the end of line. The < and > characters are not included. An example output file would look something like:

0.243
1.486
2.729

=== Algorithm Calling Format ===

The submitted algorithm must take as arguments a SINGLE .wav file to perform the downbeat estimation as well as the full output path and filename of the output file. The ability to specify the output path and file name is essential. Denoting the input .wav file path and name as %input and the output file path and name as %output, a program called foobar could be called from the command-line as follows:

foobar %input %output
foobar -i %input -o %output

Moreover, if your submission takes additional parameters, such as a detection threshold, foobar could be called like:

foobar .1 %input %output
foobar -param1 .1 -i %input -o %output

If your submission is in MATLAB, it should be submitted as a function. Once again, the function must contain String inputs for the full path and names of the input and output files. Parameters could also be specified as input arguments of the function. For example:

foobar('%input','%output')
foobar(.1,'%input','%output')

=== README File ===

A README file accompanying each submission should contain explicit instructions on how to to run the program (as well as contact information, etc.). In particular, each command line to run should be specified, using %input for the input sound file and %output for the resulting text file.

For instance, to test the program foobar with different values for parameters param1, the README file would look like:

foobar -param1 .1 -i %input -o %output
foobar -param1 .15 -i %input -o %output
foobar -param1 .2 -i %input -o %output
foobar -param1 .25 -i %input -o %output
foobar -param1 .3 -i %input -o %output
...

For a submission using MATLAB, the README file could look like:

matlab -r "foobar(.1,'%input','%output');quit;"
matlab -r "foobar(.15,'%input','%output');quit;"
matlab -r "foobar(.2,'%input','%output');quit;"
matlab -r "foobar(.25,'%input','%output');quit;"
matlab -r "foobar(.3,'%input','%output');quit;"
...

The different command lines to evaluate the performance of each parameter set over the whole database will be generated automatically from each line in the README file containing both '%input' and '%output' strings.

== Evaluation Procedures ==

For the evalution procedure we will use
*'''F-measure''' - the standard calculation as used in onset and beat tracking evaluation with a +/-70ms window, see Dixon (2007).

Given the high diversity of musical styles included in the task, results will be reported per each invidiual dataset.

== Time and hardware limits ==
Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions will be imposed.

A hard limit of 24 hours will be imposed on analysis times. Submissions exceeding this limit may not receive a result.

== Potential Participants ==
name / email

Jose R. Zapata / joserr.zapata (at) upb.edu.co

== Discussion ==
name / email

= Bibliography =

S. Dixon, F. Gouyon and G. Widmer, [http://ismir2004.ismir.net/proceedings/p093-page-509-paper165.pdf Towards Characterisation of Music via Rhythmic Patterns], In Proceedings of the 5th International Conference on Music Information Retrieval (ISMIR 2004), pp 509-516.

S. Dixon, [http://www.eecs.qmul.ac.uk/~simond/pub/2007/jnmr07.pdf Evaluation of audio beat tracking system BeatRoot], Journal of New Music Research, vol. 36, no. 1, pp. 39-51, 2007.

J. A. Hockman, M. E. P. Davies, I. Fujinaga.[http://ismir2012.ismir.net/event/papers/169-ismir-2012.pdf ONE IN THE JUNGLE: Downbeat Detection in Hardcore, Jungle, and Drum and Bass], In Proceedings of 13th International Society for Music Information Retrieval Conference (ISMIR), Porto, Portugal pp. 169-174, 2012.

F. Krebs, S. Boeck, and G. Widmer, [http://www.cp.jku.at/research/papers/Krebs_etal_ISMIR_2013.pdf Rhythmic Pattern Modeling for Beat- and Downbeat Tracking in Musical Audio], In Proceedings of 14th International Society for Music Information Retrieval Conference (ISMIR), Curitiba, Brazil, 2013.

M. Mauch, C. Cannam, M. E. P. Davies, S. Dixon, C. Harte, S. Kolozali and D. Tidhar, [http://ismir2009.ismir.net/proceedings/LBD-18.pdf OMRAS2 Metadata Project 2009], Late-breaking session at the 10th International Conference on Music Information Retrieval, 2009.

A. Srinivasamurthy, A. Holzapfel, and Xavier Serra, [http://www.tandfonline.com/doi/full/10.1080/09298215.2013.879902 In Search of Automatic Rhythm Analysis Methods for Turkish and Indian Art Music], Journal of New Music Research, vol. 43, no. 1, pp. 94-114, 2014.

2014:Audio Downbeat Estimation

2014-06-17T19:56:29Z

Jose R. Zapata:

== Description ==

'''This task is new for 2014!'''

This text has been adapted from the Audio Beat Tracking Wiki page. Please add your comments and discussion at the bottom of this page.

The aim of the automatic downbeat estimation task is to identify the locations of downbeats in a collection of sound files. While this is similar to the Audio Beat Tracking task, here the aim is to find the first beat of each bar (measure) rather than all beat times. Algorithms are '''not''' required to estimate beat times or time-signature in addition to downbeats.

Submitted algorithms will be evaluated in terms of their accuracy in finding downbeat locations (only) as annotated by musical experts across several diverse datasets.

== Data ==

=== Collections ===
'''Ballroom'''
The ballroom dataset contains eight different dance styles (Cha Cha, Jive, Quickstep, Rumba, Samba, Tango, Viennese Waltz and Waltz). It consists of '''697''' excerpts of 30s in duration.
The dataset contains two different meters 3/4 and 4/4 - but all pieces have constant meter. For further information see Dixon et al (2004) and Krebs et al (2013).
Note, we are using the ground truth annotations from Krebs et al. (2013) available at https://github.com/CPJKU/BallroomAnnotations

'''Isophonics (Beatles only)'''
The Beatles dataset from the Centre for Digital Music at Queen Mary, University of London (http://www.isophonics.net/), as also used for Audio Chord Estimation in MIREX for many years.
This dataset contains '''179''' complete songs (all except Revolution 9), the majority of which are in 4/4.
For further information see Mauch et al (2009).

'''Turkish Data'''
The Turkish corpus is an extended version of the annotated data used in Srinivasamurthy et al. (2014). It includes '''82''' excerpts of one
minute length each, and each piece belongs to one of three
rhythm classes that are referred to as usul in Turkish Art
music. 32 pieces are in the 9/8-usul Aksak, 20 pieces
in the 10/8-usul Curcuna, and 30 samples in the 8/8-usul
Düyek.

'''Cretan Data'''
The corpus of Cretan music consists of '''42''' full length pieces of Cretan leaping dances. While there are several dances that differ in terms of their steps, the differences in
the sound are most noticeable in the melodic content, and all pieces can be considered to belong to one rhythmic style. All these dances are usually notated using a 2/4 time signature,
and the accompanying rhythmical patterns are usually played on a Cretan lute. While a variety of rhythmic patterns exist, they do not relate to a specific dance and can be
assumed to occur in all of the 42 songs in this corpus.

'''Carnatic Data'''
The Carnatic music dataset is a subset of the CompMusic [http://compmusic.upf.edu/carnatic-rhythm-dataset Carnatic Music Rhythm Dataset]. It includes '''118''' two minute long excerpts spanning four most commonly used tālas (the rhythmic framework of Carnatic music, consisting of time cycles) of Carnatic music. There are 30 examples in each of ādi tāla (8 beats/cycle), rūpaka tāla (3 beats/cycle) and miśra chāpu tāla (7 beats/cycle), and 28 examples in khaṇḍa chāpu tāla (5 beats/cycle). The beats of the tāla in miśra chāpu and khaṇḍa chāpu are non-uniform, but for consistency with other datasets, a uniform beat pulse was obtained by interpolating the non-uniformly spaced beat locations. The recordings consist of both vocal and instrumental music recordings representative of the present day performance practice. All recordings contain percussion accompaniment, mainly the Mridangam.

'''HJDB''' (to be confirmed)
The HJDB dataset contains '''236''' excerpts of Hardcore, Jungle and Drum and Bass music between 30s and 2 minutes in length. All excerpts are in 4/4 and have a constant tempo.
For further information see Hockman et al (2012).

In total this makes '''1354''' excerpts (of which 259 are full length songs).

=== Audio Formats ===

The data are monophonic sound files

* CD-quality (PCM, 16-bit, 44100 Hz) for all except Ballroom (originally lower quality, but resampled to 44100 Hz)
* single channel (mono)

== Submission Format ==
Submissions to this task will have to conform to a specified format detailed below. Submissions should be packaged and contain at least two files: The algorithm itself and a README containing contact information and detailing, in full, the use of the algorithm.

=== Input Data ===
Participating algorithms will have to read audio in the following format:

* Sample rate: 44.1 KHz
* Sample size: 16 bit
* Number of channels: 1 (mono)
* Encoding: WAV

=== Output Data ===

The downbeat estimation algorithms will return downbeat times in an ASCII text file for each input .wav audio file. The specification of this output file is immediately below.

=== Output File Format (Audio Downbeat Estimation) ===

The downbeat output file format is an ASCII text format. Each downbeat time is specified, in seconds, on its own line. Specifically,

<downbeat time (in seconds)>\n

where \n denotes the end of line. The < and > characters are not included. An example output file would look something like:

0.243
1.486
2.729

=== Algorithm Calling Format ===

The submitted algorithm must take as arguments a SINGLE .wav file to perform the downbeat estimation as well as the full output path and filename of the output file. The ability to specify the output path and file name is essential. Denoting the input .wav file path and name as %input and the output file path and name as %output, a program called foobar could be called from the command-line as follows:

foobar %input %output
foobar -i %input -o %output

Moreover, if your submission takes additional parameters, such as a detection threshold, foobar could be called like:

foobar .1 %input %output
foobar -param1 .1 -i %input -o %output

If your submission is in MATLAB, it should be submitted as a function. Once again, the function must contain String inputs for the full path and names of the input and output files. Parameters could also be specified as input arguments of the function. For example:

foobar('%input','%output')
foobar(.1,'%input','%output')

=== README File ===

A README file accompanying each submission should contain explicit instructions on how to to run the program (as well as contact information, etc.). In particular, each command line to run should be specified, using %input for the input sound file and %output for the resulting text file.

For instance, to test the program foobar with different values for parameters param1, the README file would look like:

foobar -param1 .1 -i %input -o %output
foobar -param1 .15 -i %input -o %output
foobar -param1 .2 -i %input -o %output
foobar -param1 .25 -i %input -o %output
foobar -param1 .3 -i %input -o %output
...

For a submission using MATLAB, the README file could look like:

matlab -r "foobar(.1,'%input','%output');quit;"
matlab -r "foobar(.15,'%input','%output');quit;"
matlab -r "foobar(.2,'%input','%output');quit;"
matlab -r "foobar(.25,'%input','%output');quit;"
matlab -r "foobar(.3,'%input','%output');quit;"
...

The different command lines to evaluate the performance of each parameter set over the whole database will be generated automatically from each line in the README file containing both '%input' and '%output' strings.

== Evaluation Procedures ==

For the evalution procedure we will use
*'''F-measure''' - the standard calculation as used in onset and beat tracking evaluation with a +/-70ms window, see Dixon (2007).

Given the high diversity of musical styles included in the task, results will be reported per each invidiual dataset.

== Time and hardware limits ==
Due to the potentially high number of participants in this and other audio tasks, hard limits on the runtime of submissions will be imposed.

A hard limit of 24 hours will be imposed on analysis times. Submissions exceeding this limit may not receive a result.

== Potential Participants ==
name / email
Jose R. Zapata / joserr.zapata (at) upb.edu.co

== Discussion ==
name / email

= Bibliography =

S. Dixon, F. Gouyon and G. Widmer, [http://ismir2004.ismir.net/proceedings/p093-page-509-paper165.pdf Towards Characterisation of Music via Rhythmic Patterns], In Proceedings of the 5th International Conference on Music Information Retrieval (ISMIR 2004), pp 509-516.

S. Dixon, [http://www.eecs.qmul.ac.uk/~simond/pub/2007/jnmr07.pdf Evaluation of audio beat tracking system BeatRoot], Journal of New Music Research, vol. 36, no. 1, pp. 39-51, 2007.

J. A. Hockman, M. E. P. Davies, I. Fujinaga.[http://ismir2012.ismir.net/event/papers/169-ismir-2012.pdf ONE IN THE JUNGLE: Downbeat Detection in Hardcore, Jungle, and Drum and Bass], In Proceedings of 13th International Society for Music Information Retrieval Conference (ISMIR), Porto, Portugal pp. 169-174, 2012.

F. Krebs, S. Boeck, and G. Widmer, [http://www.cp.jku.at/research/papers/Krebs_etal_ISMIR_2013.pdf Rhythmic Pattern Modeling for Beat- and Downbeat Tracking in Musical Audio], In Proceedings of 14th International Society for Music Information Retrieval Conference (ISMIR), Curitiba, Brazil, 2013.

M. Mauch, C. Cannam, M. E. P. Davies, S. Dixon, C. Harte, S. Kolozali and D. Tidhar, [http://ismir2009.ismir.net/proceedings/LBD-18.pdf OMRAS2 Metadata Project 2009], Late-breaking session at the 10th International Conference on Music Information Retrieval, 2009.

A. Srinivasamurthy, A. Holzapfel, and Xavier Serra, [http://www.tandfonline.com/doi/full/10.1080/09298215.2013.879902 In Search of Automatic Rhythm Analysis Methods for Turkish and Indian Art Music], Journal of New Music Research, vol. 43, no. 1, pp. 94-114, 2014.

2014:Task Captains

2014-06-17T19:55:21Z

Jose R. Zapata:

Like ISMIR 2013, we are prepared to improve the distribution of tasks for the upcoming MIREX 2014. To do so, we really need leaders to help us organize and run each task.

To volunteer to lead one or more tasks, please add your name in the "Captains" column.

What does it mean to lead a task?
* Update wiki pages as needed
* Communicate with submitters and troubleshooting submissions
* Execution and evaluation of submissions
* Publishing final results

Due to the proprietary nature of much of the data, the submission system, evaluation framework, and most of the datasets will continue to be hosted by IMIRSEL. However, we are prepared to provide access to task organizers to manage and run submissions on the IMIRSEL systems.

{| class="wikitable" style="margin-left: 20px"
!ID !! Task !! Captain(s)
|-
|abt
|[[2014:Audio Beat Tracking]]
|Fu-Hai Frank Wu, Jose R. Zapata
|-
|ace
|[[2014:Audio Chord Estimation]]
|Johan Pauwels
|-
|act
|[[2014:Audio Classification (Train/Test) Tasks]]
|
|-
|acs
|[[2014:Audio Cover Song Identification]]
|
|-
|ade
|[[2014:Audio Downbeat Estimation]]
|Matthew Davies, Sebastian Böck, Florian Krebs
|-
|akd
|[[2014:Audio Key Detection]]
|Johan Pauwels
|-
|ame
|[[2014:Audio Melody Extraction]]
|KETI
|-
|ams
|[[2014:Audio Music Similarity and Retrieval]]
|
|-
|aod
|[[2014:Audio Onset Detection]]
|Sebastian Böck
|-
|ate
|[[2014:Audio Tempo Estimation]]
|Aggelos Gkiokas
|-
|atg
|[[2014:Audio Tag Classification]]
|Priya Arora (we need more task captains in this task.)
|-
|mf0
|[[2014:Multiple Fundamental Frequency Estimation & Tracking]]
|
|-
|qbsh
|[[2014:Query by Singing/Humming]]
|KETI
|-
|qbt
|[[2014:Query by Tapping]]
| CCRMA
|-
|scofo
|[[2014:Real-time Audio to Score Alignment (a.k.a Score Following)]]
|
|-
|sms
|[[2014:Symbolic Melodic Similarity]]
|
|-
|struct
|[[2014:Structural Segmentation]]
|
|-
|drts
|[[2014:Discovery of Repeated Themes & Sections]]
|Tom Collins
|-
|kgc
|[[2014:Audio K-POP Genre Classification]]
|IMIRSEL (Kahyun Choi, Peter Organisciak)
|-
|kmc
|[[2014:Audio K-POP Mood Classification]]
|IMIRSEL (Kahyun Choi, Peter Organisciak)
|}