2013:Real-time Audio to Score Alignment (a.k.a Score Following)
Real-time Audio to Score Alignment, also known as Score Following
Score Following is the real-time alignment of an incoming music signal to the music score. The music signal can be symbolic (MIDI) or audio, but we will concentrate here on audio following, unless there are some candidates who'd want their symbolic followers to be evaluated and can propose reference data.
This page describes a proposal for evaluation of score following systems.
Submissions will be required to estimate alignment precision according to the indexed times. In order for your system to participate, please specify the type of alignment (monophonic, polyphonic), type of training and realtime performance, also separated into two domains (upon enough submissions) for symbolic and audio systems. Note that we also do accept systems that don't run in real-time in practice, as soon as their algorithm is on-line, i.e. without making use of global knowledge of the input.
Task specific mailing list
In the past we have use a specific mailing list for the discussion of this task and related tasks. This year, however, we are asking that all discussions take place on the MIREX "EvalFest" list. If you have an question or comment, simply include the task name in the subject heading.
46 recordings and their corresponding MIDI representations of the score will be used in the evaluation. These 46 excerpts were extracted from 4 distinct musical pieces. Recordings are in 44.1Khz 16bit wav format. The reference scores are in MIDI format.
Zhiyao Duan and Prof. Bryan Pardo contributed another polyphonic dataset. This dataset consists of 10 pieces of four-part J.S. Bach chorales. The audio file was performed by a quartet of instruments: violin, clarinet, saxophone and bassoon. The ground-truth alignment between audio and midi were generated by human annotation.
Andreas Arzt contributed a heavily polyphonic dataset consisting of 3 piano performances of the Prelude in G minor op. 23-5 by Sergei Rachmaninoff. The 3 performances (by Ashkenazy, Gavrilov and Shelley) differ heavily in their style of interpretation. The ground truth data was compiled by extensive manual correction of off-line alignments. Due to an oversight this data was not used for the evaluation runs.
Evaluation procedure consists of running score followers on a database of aligned audio to score where the database contains score, and performance audio (for system call) and a reference alignment (for evaluations) -- See http://ismir2007.ismir.net/proceedings/ISMIR2007_p315_cont.pdf for details.
See the details of 2006 proposal on the MIREX 2006 Wiki
Each system should conform to the following format:
doScofo.sh "/path/to/audiofile.wav" "/path/to/midi_score_file.mid" "/path/to/result/filename.txt"
The stdout and stderr will be logged.
"/path/to/result/filenam.txt" should be have one line per detected note with the following 4 columns
1. estimated note onset time in performance audio file (ms) 2. detection time relative to performance audio file (ms) 3. note start time in score (ms) 4. MIDI note number in score (int)
1800 1800 0 75 2021 2022 187.5 73 ... ... ... ...
Remarks: The third column with the detected note's start time in score serves as the unique identifier of a note (or chord for polyphonic scores) that links it to the ground truth onset of that note within the reference alignment files. The fourth column of MIDI note number is there only for your convenience, to know your way around in the result files, if you know the melody in MIDI.
All submissions should be statically linked to all libraries (the presence of dynamically linked libraries cannot be guarenteed).
All submissions should include a README file including the following the 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
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 12 hours will be imposed on rthe total runtime of algorithms. Submissions that exceed this runtime may not receive a result.
name / email