Difference between revisions of "2013:Audio Chord Estimation"

From MIREX Wiki
(Created page with "The Utrecht Agreement on Chord Evaluation ===Evaluation of Chord Transcriptions=== Before the final description of the chord evaluation goes live here, please see the discu...")
 
Line 1: Line 1:
[[The Utrecht Agreement on Chord Evaluation]]
+
= Description =
  
===Evaluation of Chord Transcriptions===
+
This task requires participants to extract or transcribe a sequence of chords from an audio music recording. For many applications in music information retrieval, extracting the harmonic structure of an audio track is very desirable, for example for segmenting pieces into characteristic segments, for finding similar pieces, or for semantic analysis of music. The extraction of the harmonic structure requires the estimation of a sequence of chords that is as precise as possible. This includes the full characterisation of chords – root, quality, and bass note – as well as their chronological order, including specific onset times and durations. Audio chord estimation has a long history in MIREX, and readers interested in this history, especially with respect to evaluation methodology, should review the work of Christopher Harte (2010), Pauwels and Peeters (2013), and the [https://www.music-ir.org/mirex/wiki/The_Utrecht_Agreement_on_Chord_Evaluation “Utrecht Agreement”] on evaluation metrics.
  
Before the final description of the chord evaluation goes live here, please see the discussion based on the [[The Utrecht Agreement on Chord Evaluation]].
+
= Data =
  
== Description ==
+
Two datasets are used to evaluate chord transcription accuracy.
This task requires participants to extract or transcribe a sequence of chords from an audio music recording. For many applications in music information retrieval, extracting the harmonic structure of an audio track is very desirable, for example for segmenting pieces into characteristic segments, for finding similar pieces, or for semantic analysis of music.
 
  
The extraction of the harmonic structure requires the detection of as many chords as possible in a piece. That includes the characterisation of chords with a key and type as well as a chronological order with onset and duration of the chords.
+
; Isophonics
 +
: The collected Beatles, Queen, and Zweieck datasets from the Centre for Digital Music at Queen Mary, University of London (http://www.isophonics.net/), as used for Audio Chord Estimation in MIREX for many years. Available from http://www.isophonics.net/. See also Matthias Mauch’s dissertation (2010) and Harte et al.’s introductory paper (2005).
 +
; Billboard
 +
: An abridged version of the ''Billboard'' dataset from McGill University, including a representative sample of American popular music from the 1950s through the 1990s. Available from http://billboard.music.mcgill.ca. See also Ashley Burgoyne’s dissertation (2012) and Burgoyne et al.’s introductory paper (2011). Parsing tools for the data are available from http://hackage.haskell.org/package/billboard-parser/ and documented by De Haas and Burgoyne (2012).
  
Although some publications are available on this topic [1,2,3,4,5], comparison of the results is difficult, because different measures are used to assess the performance. To overcome this problem an accurately defined methodology is needed. This includes a repertory of the findable chords, a defined test set along with ground truth and unambiguous calculation rules to measure the performance.
+
== Training and Testing ==
  
 +
The training and testing divisions differ for the two data sets. The Isophonics has been available publicly for so long that it no longer makes sense to offer a separate training phase; as such, the entire data set will be used for testing, as in previous years. In contrast, in order to support MIREX, a portion of the ''Billboard'' ground truth has been withheld from the public. Submissions may train on all of the songs that have been publicly released so far: the MIREX servers have access to the ground-truth annotations and the original audio. Whether trained or not, all submissions will be tested against a fresh set of 200 songs that have never been released publicly.
  
== Data ==
+
The ground-truth files contain one line per unique chord, in the form <code>{start_time end_time chord}</code>, e.g.,
Three datasets are used to evaluate chord transcription accuracy:
+
<pre>...
 +
41.2631021 44.2456460 B
 +
44.2456460 45.7201230 E
 +
45.7201230 47.2061900 E:7/3
 +
47.2061900 48.6922670 A
 +
48.6922670 50.1551240 A:min/b3
 +
...</pre>
 +
Start and end times are in seconds from the start of the file. Chord labels follow the syntax proposed by C. Harte et al. (2005). Please note that the syntax has changed slightly since since it was originally described; in particular, the root is no longer implied as a voiced element of a chord so a C major chord (notes C, E and G) should be written C:(1,3,5) instead of just C:(3,5) if using the interval list representation. As before, the labels C and C:maj are equivalent to C:(1,3,5).
  
=== Beatles dataset ===
+
= Evaluation =
Christopher Harte`s Beatles dataset consisting of annotations of 12 Beatles albums.
 
  
The text annotation procedure of musical chords that was used to produce this dataset is presented in [6].  
+
To evaluate the quality of an automatic transcription, a transcription is compared to ground truth created by one or more human annotators. MIREX typically uses ''chord symbol recall'' (CSR) to estimate how well the predicted chords match the ground truth:
  
=== Queen and Zweieck dataset ===
+
<math>\textrm{CSR} =   \frac{\textrm{total duration of segments where annotation equals estimation}}  {\textrm{total duration of annotated segments}}</math>
Matthias Mauch's Queen and Zweieck dataset consisting of 38 songs from Queen and Zweieck.
 
  
=== Billboard dataset (abridged) ===
+
In previous years, MIREX has used an approximate CSR calculated by sampling both the ground-truth and the automatic annotations every 10 ms and dividing the number of correctly annotated samples by the total number of samples. Following Christopher Harte (2010, §8.1.2), however, we can view the ground-truth and estimated annotations as continuous segmentations of the audio and calculate the CSR by considering the cumulative length of the correctly overlapping segments. This way of calculating the CSR is more precise, as the precision of the frame-based method is limited by the frame length, and computationally more efficient, as it reduces the number of segment comparisons. Because pieces of music come in a wide variety of lengths, we will weight the CSR by the length of the song when computing an average for a given corpus. This final number is referred to as the ''weighted chord symbol recall'' (WCSR).
An abridged version of Ashley Burgoyne's Billboard dataset [9], consisting of about 200 songs for training (previously published) and 200 songs for testing (to be published for the first time at ISMIR).
 
  
===Example ground-truth file ===
+
== Chord Vocabularies ==
The ground-truth files take the form:
 
  
...
+
[chord-eval]
41.2631021 44.2456460 B
 
44.2456460 45.7201230 E
 
45.7201230 47.2061900 E:7/3
 
47.2061900 48.6922670 A
 
48.6922670 50.1551240 A:min/b3
 
...
 
  
 +
We propose a set of single chord evaluation measures for MIREX that extends the previous iterations of MIREX and combines it with evaluation measures proposed in the literature, providing a more complete assessment of the transcription quality. Following Pauwels and Peeters (2013), we suggest using the CSR with five different chord vocabulary mappings.
  
== Evaluation ==
+
In each of these calculations, the full chord descriptions of either the estimated or the ground-truth transcriptions, which might contain complex chord annotations, would be mapped to the following classes:
  
 +
# Chord root note only;
 +
# Major and minor: {<code>N, maj, min</code>};
 +
# Seventh chords: {<code>N, maj, min, maj7, min7, 7</code>};
 +
# Major and minor with inversions: {<code>N, maj, min, maj/3, min/b3, maj/5, min/5</code>}; or
 +
# Seventh chords with inversions: {<code>N, maj, min, maj7, min7, 7, maj/3, min/b3, maj7/3, min7/b3, 7/3, maj/5, min/5, maj7/5, min7/5, 7/5, maj7/7, min7/b7, 7/b7</code>}.
  
 +
With the exception of no-chords, calculating the vocabulary mapping involves examining the root note, the bass note, and the relative interval structure of the chord labels. A mapping exists if both the root notes and bass notes match, and the structure of the output label is the largest possible subset of the input label given the vocabulary. For instance, in the major and minor case, <code>G:7(#9)</code> is mapped to <code>G:maj</code> because the interval set of <code>G:maj</code>, {<code>1,3,5</code>}, is a subset of the interval set of the <code>G:7(#9)</code>, {<code>1,3,5,b7,#9</code>}. In the seventh-chord case, <code>G:7(#9)</code> is mapped to <code>G:7</code> instead because the interval set of <code>G:7</code> {<code>1, 3, 5, b7</code>} is also a subset of <code>G:7(#9)</code> but is larger than <code>G:maj</code>. If a chord cannot be represented by a certain class, e.g., mapping a <code>D:aug</code> or <code>F:sus4(9)</code> to {<code>maj, min</code>}, the chord is excluded from the evaluation if it occurs in the ground-truth, and it is considered a mismatch if it occurs in an estimated annotation.
  
=== Segmentation Score ===
+
{|
 
+
|+ Most frequent chord qualities in the McGill ''Billboard'' corpus.
The segmentation score will be calculated using directional hamming distance as described in [8]. An over-segmentation value (m) and an under-segmentation value (f) will be calculated and the final segmentation score will be calculated using the worst case from these two i.e:
+
! Quality
 
+
! Freq. (%)
segmentation score = 1 - max(m,f)
+
! Cum. Freq (%)
 
+
|-  
m and f are not independent of each other so combining them this way ensures that a good score in one does not hide a bad score in the other. The combined segmentation score can take values between 0 and 1 with 0 being the worst and 1 being the best result.-- Chrish 17:05, 9 September 2009 (UTC)
+
|maj
 
+
|52
=== Frame-based recall ===
+
|52
 
 
 
 
For recall evaluation, we may define a different chord dictionary for each level of evaluation (dyads, triads, tetrads etc). Each dictionary is a text file containing chord shorthands / interval lists of the chords that will be considered in that evaluation. The following dictionaries are proposed:
 
 
 
For dyad comparison of major/minor chords only:
 
 
 
N<br>
 
X:maj<br>
 
X:min<br>
 
 
 
For comparison of standard triad chords:
 
 
 
N<br>
 
X:maj<br>
 
X:min<br>
 
X:aug<br>
 
X:dim<br>
 
X:sus2<br>
 
X:sus4<br>
 
 
 
For comparison of tetrad (quad) chords (currently only for the Beatles and Queen and Zweieck datasets):
 
 
 
N <br>
 
X:maj <br>
 
X:min<br>
 
X:aug<br>
 
X:dim<br>
 
X:sus2<br>
 
X:sus4<br>
 
X:maj7<br>
 
X:7<br>
 
X:maj(9)<br>
 
X:aug(7) <br>
 
X:min(7)<br>
 
X:min7<br>
 
X:min(9)<br>
 
X:dim(7)<br>
 
X:hdim7 <br>
 
X:sus4(7)<br>
 
X:sus4(b7)<br>
 
X:dim7<br>
 
 
 
 
 
For each evaluation level, the ground truth annotation is compared against the dictionary. Any chord label not belonging to the current dictionary will be replaced with an "X" in a local copy of the annotation and will not be included in the recall calculation.
 
 
 
Note that the level of comparison in terms of intervals can be varied. For example, in a triad evaluation we can consider the first three component intervals in the chord so that a major (1,3,5) and a major7 (1,3,5,7) will be considered the same chord. For a tetrad (quad) evaluation, we would consider the first 4 intervals so major and major7 would then be considered to be different chords.
 
 
 
For the maj/min evaluation (using the first example dictionary), using an interval comparison of 2 (dyad) will compare only the first two intervals of each chord label. This would map augmented and diminished chords to major and minor respectively (and any other symbols that had a major 3rd or minor 3rd as their first interval). Using an interval comparison of 3 with the same dictionary would keep only those chords that have major and minor triads as their first 3 intervals so augmented and diminished chords would be removed from the evaluation.
 
 
 
After the annotation has been "filtered" using a given dictionary, it can be compared against the machine generated estimates output by the algorithm under test. The chord sequences described in the annotation and estimate text files are sampled at a given frame rate (in this case 10ms per frame) to give two sequences of chord frames which may be compared directly with each other. For calculating a hit or a miss, the chord labels from the current frame in each sequence will be compared.  Chord comparison is done by converting each chord label into an ordered list of pitch classes then comparing the two lists element by element. If the lists match to the required number of intervals then a hit is recorded, otherwise the estimate is considered a miss. It should be noted that, by converting to pitch classes in the comparison, this evaluation ignores enharmonic pitch and interval spellings so the following chords (slightly silly example just for illustration) will all evaluate as identical:
 
 
 
C:maj = Dbb:maj = C#:(b1,b3,#4)
 
 
 
 
 
Basic recall calculation algorithm:
 
 
 
1) filter annotated transcription using chord dictionary for a defined number of intervals
 
 
 
2) sample annotated transcription and machine estimated transcription at 10ms intervals to create a sequence of annotation frames and estimate frames
 
 
 
3) start at the first frame
 
 
 
4) get chord label for current annotation frame and estimate frame
 
 
 
5) check annotation label:<br>
 
 
 
IF symbol is 'X' (i.e. non-dictionary) <br>
 
 
 
THEN ignore frame (record number of ignored frames)<br>
 
 
 
ELSE compare annotated/estimated chords for the predefined number of intervals <br>
 
increment hit count if chords match<br>
 
 
 
ENDIF
 
 
 
6) increment frame count
 
 
 
7) go back to 4 until final chord frame
 
--[[User:Chrish|Chrish]] 17:05, 9 September 2009 (UTC)
 
 
 
 
 
== Submission Format ==
 
 
 
=== Audio Format ===
 
Audio tracks will be encoded as 44.1 kHz 16bit mono WAV files.
 
 
 
 
 
=== I/O Format ===
 
The expected output chord transcription file for participating algorithms is that proposed by Christopher Harte [6].
 
 
 
Hence, algorithms should output text files with a similar format to that used in the ground truth transcriptions. That is to say, they should be flat text files with chord segment labels and times arranged thus:
 
 
 
start_time end_time chord_label
 
 
 
with elements separated by white spaces, times given in seconds, chord labels corresponding to the syntax described in [6] and one chord segment per line.  
 
 
 
The chord root is given as a natural (A|B|C|D|E|F|G) followed by optional sharp or flat modifiers (#|b). For the evaluation process we may assume enharmonic equivalence for chord roots. For a given chord type on root X, the chord labels can be given as a list of intervals or as a shorthand notation as shown in the following table:
 
 
 
{|border="1" cellpadding="5" cellspacing="0" align="center"
 
|-
 
!NAME
 
!INTERVALS
 
!SHORTHAND
 
|-
 
|-*Triads:
 
|-
 
|-
 
|major
 
|X:(1,3,5)
 
|X or X:maj
 
 
|-
 
|-
 +
|min
 +
|13
 +
|65
 
|-
 
|-
|minor
+
|7
|X:(1,b3,5)
+
|10
|X:min
+
|75
 
|-
 
|-
 +
|min7
 +
|8
 +
|83
 
|-
 
|-
|diminished
+
|maj7
|X:(1,b3,b5)
+
|3
|X:dim
+
|86
 
|-
 
|-
 +
|5
 +
|2
 +
|88
 
|-
 
|-
|augmented
+
|1
|X:(1,3,#5)
+
|2
|X:aug
+
|90
 
|-
 
|-
 +
|maj(9)
 +
|1
 +
|91
 
|-
 
|-
|suspended4
+
|maj6
|X:(1,4,5)
+
|1
|X:sus4
+
|92
 
|-
 
|-
 +
|sus4
 +
|1
 +
|93
 
|-
 
|-
|possible 6th triad:
+
|sus7
|
+
|1
|
+
|94
 
|-
 
|-
 +
|sus9
 +
|1
 +
|94
 
|-
 
|-
|suspended2
+
|7(#9)
|X:(1,2,5)
+
|1
|X:sus2
+
|95
 
|-
 
|-
|-
+
|min9
|*Quads:
+
|1
|
+
|96
|
 
|-
 
|-
 
|major-major7
 
|X:(1,3,5,7)
 
|X:maj7
 
|-
 
|-
 
|major-minor7
 
|X:(1,3,5,b7)
 
|X:7
 
|-
 
|-
 
|major-add9
 
|X:(1,3,5,9)
 
|X:maj(9)
 
|-
 
|-
 
|major-major7-#5
 
|X:(1,3,#5,7)
 
|X:aug(7)
 
|-
 
|-
 
|minor-major7
 
|X:(1,b3,5,7)
 
|X:min(7)
 
|-
 
|-
 
|minor-minor7
 
|X:(1,b3,5,b7)
 
|X:min7
 
|-
 
|-
 
|minor-add9
 
|X:(1,b3,5,9)
 
|X:min(9)
 
|-
 
|-
 
|minor 7/b5 (ambiguous - could be either of the following)
 
|
 
|
 
|-
 
|-
 
|minor-major7-b5
 
|X:(1,b3,b5,7)
 
|X:dim(7)
 
|-
 
|-
 
|minor-minor7-b5  (a half diminished-7th)
 
|X:(1,b3,b5,b7)
 
|X:hdim7
 
|-
 
|-
 
|sus4-major7
 
|X:(1,4,5,7)
 
|X:sus4(7)
 
|-
 
|-
 
|sus4-minor7
 
|X:(1,4,5,b7)
 
|X:sus4(b7)
 
|-
 
|-
 
|omitted from list on wiki:
 
|
 
|
 
|-
 
|-
 
|diminished7
 
|X:(1,b3,b5,bb7)
 
|X:dim7
 
|-
 
|-
 
|No Chord
 
|N
 
|
 
 
|}
 
|}
  
 +
Our recommendations are motivated by the frequencies of chord qualities in the ''Billboard'' corpus (see table above), which is a balanced sample of American popular music from the 1950s through the 1990s (J.A. Burgoyne, Wild, and Fujinaga 2011). Pure major and minor chords alone account for 65 percent of all chords encountered, whereas augmented and diminished triads account for 0.2 percent or less of the corpus each. Our arguments for our particular seventh-chord vocabulary as opposed to the set of all tetrads follows similar reasoning; our proposed vocabulary accounts for 86 percent of all chords, whereas no other standard type of seventh chord accounts for more than 0.2 percent of the corpus. In future years, the table suggests that we might consider introducing vocabularies including power chords, and possibly suspended chords or added sixths and ninths as well.
  
Please note that two things have changed in the syntax since it was originally described in [6]. The first change is that the root is no longer implied as a voiced element of a chord so a C major chord (notes C, E and G) should be written C:(1,3,5) instead of just C:(3,5) if using the interval list representation. As before, the labels C and C:maj are equivalent to C:(1,3,5). The second change is that the shorthand label "sus2" (intervals 1,2,5) has been added to the available shorthand list.--[[User:Chrish|Chrish]] 17:05, 9 September 2009 (UTC)
+
== Chord Segmentation ==
  
We still accept participants who would only like to be evaluated on major/minor chords and want to use the number format which is an integer chord id on range 0-24, where values 0-11  denote the C major, C# major, ..., B major  and  12-23 denote the C minor, C# minor, ..., B minor and        24    denotes silence or no-chord segments. '''Please note that the format is still the same'''
+
Besides CSR, the chord transcription literature includes several other metrics for evaluating chord transcriptions, which mainly focus on the segmentation of the automatic transcription. We propose to include the directional Hamming distance in the evaluation. The directional Hamming distance is calculated by finding for each annotated segment the maximally overlapping segment in the other annotation, and then summing the differences ((S. A. Abdallah et al. 2005); (Mauch 2010, §2.3.3)). Depending on the order of application, the directional Hamming distance yields a measure of over- or under segmentation. Both directions can be combined to yield an overall quality metric (Christopher Harte 2010, §8.3.2):
  
start_time end_time chord_number
+
<math>Q = 1 - \frac{\textrm{maximum of directional Hamming distances in    either direction}}      {\textrm{total duration of song}}</math>
  
Systems are supposed to print out the onset-offset times as opposed to MIREX 2008 chord output format where only onset were used.
+
= Submission Format =
  
=== Command line calling format ===
+
== Audio Format ==
  
Submissions have to conform to the specified format below:
+
Audio tracks in the training directory will be encoded as 44.1 kHz 16bit mono WAV files.
  
''extractFeaturesAndTrain  "/path/to/trainFileList.txt"  "/path/to/scratch/dir" ''
+
== I/O Format ==
  
Where fileList.txt has the paths to each wav file. The features extracted on this stage can be stored under "/path/to/scratch/dir"
+
The algorithms should output text files with a similar format to that used in the ground truth transcriptions. That is to say, they should be flat text files with chord segment labels and times arranged thus:
The ground truth files for the supervised learning will be in the same path with a ".txt" extension at the end. For example for "/path/to/trainFile1.wav", there will be a corresponding ground truth file called "/path/to/trainFile1.wav.txt" .
 
  
For testing:
+
<pre>start_time end_time chord_label</pre>
 +
with elements separated by white spaces, times given in seconds, chord labels corresponding to the syntax described by C. Harte et al. (2005), and one chord segment per line. As in all benchmarks after 2008, end times are a mandatory component of the output. For the evaluation process we will assume enharmonic equivalence for chord roots. We will no longer accept participants who would only like to be evaluated on major/minor chords and want to use the number format.
  
''doChordID.sh "/path/to/testFileList.txt"  "/path/to/scratch/dir" "/path/to/results/dir" ''
+
== Command line calling format ==
  
If there is no training, you can ignore the second argument here. In the results directory, there should be one file for each testfile with same name as the test file + .txt .
+
Submissions have to conform to the specified format below:
  
Programs can use their working directory if they need to keep temporary cache files or internal debuggin info. Stdout and stderr will be logged.
+
<pre>extractFeaturesAndTrain  &quot;/path/to/trainFileList.txt&quot;  &quot;/path/to/scratch/dir&quot;  </pre>
 +
where <code>fileList.txt</code> has the paths to each WAV file. The features extracted on this stage can be stored under <code>/path/to/scratch/dir</code>. The ground truth files for the supervised learning will be in the same path with a <code>.txt</code> extension at the end. For example for <code>/path/to/trainFile1.wav</code>, there will be a corresponding ground truth file called <code>/path/to/trainFile1.wav.txt</code>. For testing:
  
 +
<pre>doChordID.sh &quot;/path/to/testFileList.txt&quot; &quot;/path/to/scratch/dir&quot; &quot;/path/to/results/dir&quot; </pre>
 +
If there is no training, you can ignore the second argument here. In the results directory, there should be one file for each testfile with same name as the test file + <code>.txt</code>. Programs can use their working directory if they need to keep temporary cache files or internal debugging info. Standard output and standard error will be logged.
  
=== Packaging submissions ===
+
== Packaging submissions ==
All submissions should be statically linked to all libraries (the presence of dynamically linked libraries cannot be guaranteed).
 
  
All submissions should include a README file including the following information:
+
All submissions should be statically linked to all libraries (the presence of dynamically linked libraries cannot be guaranteed). All submissions should include a <code>README</code> file including the following information:
  
 
* Command line calling format for all executables and an example formatted set of commands
 
* Command line calling format for all executables and an example formatted set of commands
Line 310: Line 152:
 
* Expected memory footprint
 
* Expected memory footprint
 
* Expected runtime
 
* Expected runtime
* Any required environments (and versions), e.g. python, java, bash, matlab.
+
* Any required environments (and versions), e.g. Python, Java, bash, MATLAB.
  
 +
= Time and Hardware limits =
  
== Time and hardware limits ==
 
Due to the potentially high number of particpants in this and other audio tasks, hard limits on the runtime of submissions are specified.
 
 
 
A hard limit of 24 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.
 
A hard limit of 24 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.
  
== Discussion ==
+
= Discussion =
Please write your comments below with your name and date.
 
 
 
Somewhere in the email discussion on the MIREX list, there was a mention that the recent systems run on the Beatles/Queen/Zweieck dataset might have over-learnt the properties of this dataset. I just wondered whether, during or post-MIREX, there was any way to formally/experimentally demonstrate this? I mean, beyond making the observation that there is a "drop" in performance from an open dataset to a closed one. The issue would seem particularly pertinent with regard to this dataset since it's been public for sometime.
 
(Matthew Davies, 9th August)
 
 
 
== Potential Participants ==
 
name / email
 
 
 
 
 
== Bibliography ==
 
  
1. Harte, C.A. and Sandler, M.B. (2005). '''Automatic chord identification using a quantised chromagram.''' Proceedings of 118th Audio Engineering Society's Convention.
+
= Bibliography =
  
2. Sailer, C. and Rosenbauer K. (2006). '''A bottom-up approach to chord detection.''' Proceedings of International Computer Music Conference 2006.
+
Abdallah, Samer A., Katy Noland, Mark B. Sandler, Michael Casey, and Christophe Rhodes. 2005. “Theory and Evaluation of a Bayesian Music Structure Extractor.” In ''Proceedings of the International Society for Music Information Retrieval Conference'', 420–425.
  
3. Shenoy, A. and Wang, Y. (2005). '''Key, chord, and rythm tracking of popular music recordings.''' Computer Music Journal 29(3), 75-86.
+
Burgoyne, J. A., J. Wild, and I. Fujinaga. 2011. “An expert ground truth set for audio chord recognition and music analysis.” In ''Proceedings of the 12th International Society for Music Information Retrieval Conference (ISMIR)'', 633–638.
  
4. Sheh, A. and Ellis, D.P.W. (2003). '''Chord segmentation and recognition using em-trained hidden markov models.''' Proceedings of 4th International Conference on Music Information Retrieval.
+
Burgoyne, John Ashley. 2012. “Stochastic Processes and Database-Driven Musicology.” Ph.D. diss. Montréal, Québec, Canada: McGill University. http://digitool.Library.McGill.CA:80/R/-?func=dbin-jump-full&object_id=107704&silo_library=GEN01.
  
5. Yoshioka, T. et al. (2004). '''Automatic Chord Transcription with concurrent recognition of chord symbols and boundaries.''' Proceedings of 5th International Conference on Music Information Retrieval.
+
Haas, W. B. de, and John~Ashley Burgoyne. 2012. ''Parsing the Billboard Chord Transcriptions''. Technical report UU-CS- 2012-018, Department of Information and Computing Sciences, Utrecht University.
  
6. Harte, C. et al. (2005). '''Symbolic representation of musical chords: a proposed syntax for text annotations.''' Proceedings of 6th International Conference on Music Information Retrieval.
+
Harte, C., M. Sandler, S. Abdallah, and E. Gómez. 2005. “Symbolic representation of musical chords: A proposed syntax for text annotations.” In ''Proceedings of the 6th International Society for Music Information Retrieval Conference (ISMIR)'', 66–71.
  
7. Papadopoulos, H. and Peeters, G. (2007). '''Large-scale study of chord estimation algorithms based on chroma representation and HMM.''' Proceedings of 5th International Conference on Content-Based Multimedia Indexing.
+
Harte, Christopher. 2010. “Towards automatic extraction of harmony information from music signals.” Ph.D. diss. Queen Mary, University of London.
  
8. Abdallah, S. et al. (2005). '''Theory and Evaluation of a Bayesian Music Structure Extractor''' (pp. 420-425) Proc. 6th International Conference on Music Information Retrieval, ISMIR 2005.
+
Mauch, Matthias. 2010. “Automatic Chord Transcription from Audio Using Computational Models of Musical Context.” Ph.D. diss. Queen Mary University of London.
  
9. John Ashley Burgoyne et al. (2011). '''An expert ground-truth set for audio chord recognition and music analysis''' (pp. 633–638) Proc. 12th International Society for Music Information Retrieval Conference, ISMIR 2006. [http://ismir2011.ismir.net/papers/OS8-1.pdf (PDF)]
+
Pauwels, Johan, and Geoffroy Peeters. 2013. “Evaluating automatically estimated chord sequences.” In ''Proceedings of IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP)''. Vancouver, British Columbia, Canada.

Revision as of 07:28, 9 September 2013

Description

This task requires participants to extract or transcribe a sequence of chords from an audio music recording. For many applications in music information retrieval, extracting the harmonic structure of an audio track is very desirable, for example for segmenting pieces into characteristic segments, for finding similar pieces, or for semantic analysis of music. The extraction of the harmonic structure requires the estimation of a sequence of chords that is as precise as possible. This includes the full characterisation of chords – root, quality, and bass note – as well as their chronological order, including specific onset times and durations. Audio chord estimation has a long history in MIREX, and readers interested in this history, especially with respect to evaluation methodology, should review the work of Christopher Harte (2010), Pauwels and Peeters (2013), and the “Utrecht Agreement” on evaluation metrics.

Data

Two datasets are used to evaluate chord transcription accuracy.

Isophonics
The collected Beatles, Queen, and Zweieck datasets from the Centre for Digital Music at Queen Mary, University of London (http://www.isophonics.net/), as used for Audio Chord Estimation in MIREX for many years. Available from http://www.isophonics.net/. See also Matthias Mauch’s dissertation (2010) and Harte et al.’s introductory paper (2005).
Billboard
An abridged version of the Billboard dataset from McGill University, including a representative sample of American popular music from the 1950s through the 1990s. Available from http://billboard.music.mcgill.ca. See also Ashley Burgoyne’s dissertation (2012) and Burgoyne et al.’s introductory paper (2011). Parsing tools for the data are available from http://hackage.haskell.org/package/billboard-parser/ and documented by De Haas and Burgoyne (2012).

Training and Testing

The training and testing divisions differ for the two data sets. The Isophonics has been available publicly for so long that it no longer makes sense to offer a separate training phase; as such, the entire data set will be used for testing, as in previous years. In contrast, in order to support MIREX, a portion of the Billboard ground truth has been withheld from the public. Submissions may train on all of the songs that have been publicly released so far: the MIREX servers have access to the ground-truth annotations and the original audio. Whether trained or not, all submissions will be tested against a fresh set of 200 songs that have never been released publicly.

The ground-truth files contain one line per unique chord, in the form {start_time end_time chord}, e.g.,

...
41.2631021 44.2456460 B
44.2456460 45.7201230 E
45.7201230 47.2061900 E:7/3
47.2061900 48.6922670 A
48.6922670 50.1551240 A:min/b3
...

Start and end times are in seconds from the start of the file. Chord labels follow the syntax proposed by C. Harte et al. (2005). Please note that the syntax has changed slightly since since it was originally described; in particular, the root is no longer implied as a voiced element of a chord so a C major chord (notes C, E and G) should be written C:(1,3,5) instead of just C:(3,5) if using the interval list representation. As before, the labels C and C:maj are equivalent to C:(1,3,5).

Evaluation

To evaluate the quality of an automatic transcription, a transcription is compared to ground truth created by one or more human annotators. MIREX typically uses chord symbol recall (CSR) to estimate how well the predicted chords match the ground truth:

In previous years, MIREX has used an approximate CSR calculated by sampling both the ground-truth and the automatic annotations every 10 ms and dividing the number of correctly annotated samples by the total number of samples. Following Christopher Harte (2010, §8.1.2), however, we can view the ground-truth and estimated annotations as continuous segmentations of the audio and calculate the CSR by considering the cumulative length of the correctly overlapping segments. This way of calculating the CSR is more precise, as the precision of the frame-based method is limited by the frame length, and computationally more efficient, as it reduces the number of segment comparisons. Because pieces of music come in a wide variety of lengths, we will weight the CSR by the length of the song when computing an average for a given corpus. This final number is referred to as the weighted chord symbol recall (WCSR).

Chord Vocabularies

[chord-eval]

We propose a set of single chord evaluation measures for MIREX that extends the previous iterations of MIREX and combines it with evaluation measures proposed in the literature, providing a more complete assessment of the transcription quality. Following Pauwels and Peeters (2013), we suggest using the CSR with five different chord vocabulary mappings.

In each of these calculations, the full chord descriptions of either the estimated or the ground-truth transcriptions, which might contain complex chord annotations, would be mapped to the following classes:

  1. Chord root note only;
  2. Major and minor: {N, maj, min};
  3. Seventh chords: {N, maj, min, maj7, min7, 7};
  4. Major and minor with inversions: {N, maj, min, maj/3, min/b3, maj/5, min/5}; or
  5. Seventh chords with inversions: {N, maj, min, maj7, min7, 7, maj/3, min/b3, maj7/3, min7/b3, 7/3, maj/5, min/5, maj7/5, min7/5, 7/5, maj7/7, min7/b7, 7/b7}.

With the exception of no-chords, calculating the vocabulary mapping involves examining the root note, the bass note, and the relative interval structure of the chord labels. A mapping exists if both the root notes and bass notes match, and the structure of the output label is the largest possible subset of the input label given the vocabulary. For instance, in the major and minor case, G:7(#9) is mapped to G:maj because the interval set of G:maj, {1,3,5}, is a subset of the interval set of the G:7(#9), {1,3,5,b7,#9}. In the seventh-chord case, G:7(#9) is mapped to G:7 instead because the interval set of G:7 {1, 3, 5, b7} is also a subset of G:7(#9) but is larger than G:maj. If a chord cannot be represented by a certain class, e.g., mapping a D:aug or F:sus4(9) to {maj, min}, the chord is excluded from the evaluation if it occurs in the ground-truth, and it is considered a mismatch if it occurs in an estimated annotation.

Most frequent chord qualities in the McGill Billboard corpus.
Quality Freq. (%) Cum. Freq (%)
maj 52 52
min 13 65
7 10 75
min7 8 83
maj7 3 86
5 2 88
1 2 90
maj(9) 1 91
maj6 1 92
sus4 1 93
sus7 1 94
sus9 1 94
7(#9) 1 95
min9 1 96

Our recommendations are motivated by the frequencies of chord qualities in the Billboard corpus (see table above), which is a balanced sample of American popular music from the 1950s through the 1990s (J.A. Burgoyne, Wild, and Fujinaga 2011). Pure major and minor chords alone account for 65 percent of all chords encountered, whereas augmented and diminished triads account for 0.2 percent or less of the corpus each. Our arguments for our particular seventh-chord vocabulary as opposed to the set of all tetrads follows similar reasoning; our proposed vocabulary accounts for 86 percent of all chords, whereas no other standard type of seventh chord accounts for more than 0.2 percent of the corpus. In future years, the table suggests that we might consider introducing vocabularies including power chords, and possibly suspended chords or added sixths and ninths as well.

Chord Segmentation

Besides CSR, the chord transcription literature includes several other metrics for evaluating chord transcriptions, which mainly focus on the segmentation of the automatic transcription. We propose to include the directional Hamming distance in the evaluation. The directional Hamming distance is calculated by finding for each annotated segment the maximally overlapping segment in the other annotation, and then summing the differences ((S. A. Abdallah et al. 2005); (Mauch 2010, §2.3.3)). Depending on the order of application, the directional Hamming distance yields a measure of over- or under segmentation. Both directions can be combined to yield an overall quality metric (Christopher Harte 2010, §8.3.2):

Submission Format

Audio Format

Audio tracks in the training directory will be encoded as 44.1 kHz 16bit mono WAV files.

I/O Format

The algorithms should output text files with a similar format to that used in the ground truth transcriptions. That is to say, they should be flat text files with chord segment labels and times arranged thus:

start_time end_time chord_label

with elements separated by white spaces, times given in seconds, chord labels corresponding to the syntax described by C. Harte et al. (2005), and one chord segment per line. As in all benchmarks after 2008, end times are a mandatory component of the output. For the evaluation process we will assume enharmonic equivalence for chord roots. We will no longer accept participants who would only like to be evaluated on major/minor chords and want to use the number format.

Command line calling format

Submissions have to conform to the specified format below:

extractFeaturesAndTrain  "/path/to/trainFileList.txt"  "/path/to/scratch/dir"  

where fileList.txt has the paths to each WAV file. The features extracted on this stage can be stored under /path/to/scratch/dir. The ground truth files for the supervised learning will be in the same path with a .txt extension at the end. For example for /path/to/trainFile1.wav, there will be a corresponding ground truth file called /path/to/trainFile1.wav.txt. For testing:

doChordID.sh "/path/to/testFileList.txt" "/path/to/scratch/dir" "/path/to/results/dir" 

If there is no training, you can ignore the second argument here. In the results directory, there should be one file for each testfile with same name as the test file + .txt. Programs can use their working directory if they need to keep temporary cache files or internal debugging info. Standard output and standard error will be logged.

Packaging submissions

All submissions should be statically linked to all libraries (the presence of dynamically linked libraries cannot be guaranteed). All submissions should include a README file including the following information:

  • Command line calling format for all executables and an example formatted set of commands
  • Number of threads/cores used or whether this should be specified on the command line
  • Expected memory footprint
  • Expected runtime
  • Any required environments (and versions), e.g. Python, Java, bash, MATLAB.

Time and Hardware limits

A hard limit of 24 hours will be imposed on runs (total feature extraction and querying times). Submissions that exceed this runtime may not receive a result.

Discussion

Bibliography

Abdallah, Samer A., Katy Noland, Mark B. Sandler, Michael Casey, and Christophe Rhodes. 2005. “Theory and Evaluation of a Bayesian Music Structure Extractor.” In Proceedings of the International Society for Music Information Retrieval Conference, 420–425.

Burgoyne, J. A., J. Wild, and I. Fujinaga. 2011. “An expert ground truth set for audio chord recognition and music analysis.” In Proceedings of the 12th International Society for Music Information Retrieval Conference (ISMIR), 633–638.

Burgoyne, John Ashley. 2012. “Stochastic Processes and Database-Driven Musicology.” Ph.D. diss. Montréal, Québec, Canada: McGill University. http://digitool.Library.McGill.CA:80/R/-?func=dbin-jump-full&object_id=107704&silo_library=GEN01.

Haas, W. B. de, and John~Ashley Burgoyne. 2012. Parsing the Billboard Chord Transcriptions. Technical report UU-CS- 2012-018, Department of Information and Computing Sciences, Utrecht University.

Harte, C., M. Sandler, S. Abdallah, and E. Gómez. 2005. “Symbolic representation of musical chords: A proposed syntax for text annotations.” In Proceedings of the 6th International Society for Music Information Retrieval Conference (ISMIR), 66–71.

Harte, Christopher. 2010. “Towards automatic extraction of harmony information from music signals.” Ph.D. diss. Queen Mary, University of London.

Mauch, Matthias. 2010. “Automatic Chord Transcription from Audio Using Computational Models of Musical Context.” Ph.D. diss. Queen Mary University of London.

Pauwels, Johan, and Geoffroy Peeters. 2013. “Evaluating automatically estimated chord sequences.” In Proceedings of IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP). Vancouver, British Columbia, Canada.