PianoCoRe: Combined and Refined Piano MIDI Dataset

3.2.1 Score processing

Before matching, the MusicXML files were converted to MIDI format using the partitura library (Cancino‑ Chacón et al., 2022) with the following refinements:

• Dynamics and Tempo: the <sound> tags and dynamics attributes for notes are processed to embed performance direction markings for dynamics and tempo directly into the note velocities and tempo changes of the score MIDI file.

• Ornaments: trills and mordents are unrolled based on the invisible notes available in MusicXML (<cue/> or print‑object=‘‘no''). The base visible ornament note is removed to avoid overlapping note events.

• Grace Notes: acciaccatura and appoggiatura notes are expanded based on the definitions. Acciaccatura notes appear as a sequence of 32nd notes before the beat. Appoggiatura notes steal the duration of the main note.

• Repeats: for scores with repeats, two versions are created: a maximal version with all repeats unfolded and a minimal version with each repeat played only once (suffix _mini in the file name).

These changes ensure fair consideration of score structure and performance‑specific elements in MIDI score files. To simplify the management of the created dataset, the full set of possible repeat structures in the scores was not considered.

3.2.2 Candidate pair selection

To avoid a brute‑force comparison of all files, a filtering step to identify a smaller set of candidate pairs is performed. A score is paired with a performance if they meet the following criteria:

• Composer: the composer names, extracted from file paths or metadata tags, match;

• Note Count: the note ratio $R_n$ falls within a plausible range of close length: $0.75\le R_n\le 1.33$; and

• Keywords: if available, the catalog numbers, and key/scale information within the titles match.

This pre‑filtering enables efficient application of computationally intensive, alignment‑based verification.

3.2.3 Note alignment and verification

For the final step, note‑level alignments for candidate pairs were computed using the DualDTWNoteMatcher from Parangonar (Peter, 2023). The underlying dynamic time warping (DTW) implementation was optimized using Numba's just‑in‑time (JIT) compilation (Lam et al., 2015). The optimized version works, on average, 12 times faster on the ASAP dataset. This optimization was essential for performing millions of pairwise alignments within a reasonable timeframe.

A candidate pair is considered a definitive match if the alignment achieves $R_a>0.7$ (more than 70% of score notes matched to the performance). This threshold was chosen empirically to ensure a global overlap between the sequences with close score and performed repeat structures. Unmatched notes may correspond to omitted repeats, transcription errors, or specific interpretations. These data are still valuable for performance‑only applications, including large‑scale pre‑training.

Performances that fail to align with the maximal unfolded score are matched to the minimal one, increasing data retention. The exact repeat structure of the performances is not detected. For trills, the number of notes may differ between performances and scores. However, unrollment of trills in the score MIDI yields a higher alignment recall than aligning multiple performed notes to a single base trill note.

Alignments are stored in compressed .npz files compatible with the original MIDI files. Each file contains arrays describing the attributes of the aligned score and performance notes: indices, pitches, and onset/offset times. Insertions and deletions are represented by the sentinel value −1 for missing attributes.

3.3.1 ASAP dataset

The (n)ASAP dataset v2.1.1 (Peter et al., 2023)⁴ was used. The original score MIDI files, exported using MuseScore (Watson, 2018), contain data‑parsing issues like unrealistic time signatures (e.g., 65/4, 25/32), cut measures with anacrusis, duplicated notes, and notes with zero duration. These were corrected by re‑generating score MIDI files using the standardized pipeline (Section 3.2.1). The performance MIDI files were cleaned by removing duplicate notes, truncating durations of the first of the two overlapping notes (such that $o_i=o_{i-1}+{\hat{d}}_{i-1}$), and removing all notes shorter than 5 ms. There are 208 score and 94 performance MIDI files with zero duration notes in the original dataset.

3.3.2 ATEPP dataset

The ATEPP v1.2 dataset (Zhang et al., 2022)⁵ was used. Only 5,091 of 11,674 transcribed performances are paired with scores without an alignment. ATEPP shares the scores with ASAP, but not all suitable scores (e.g., the entirety of Chopin) are present in ATEPP. By matching two datasets, 39 scores from ASAP can be assigned to 827 performances in ATEPP.

As a preprocessing step, score MIDI files were computed from MusicXML files, similar to scores in ASAP. Also, the following metadata issues were corrected: merging duplicate movements under different names (49 movements and 265 reassigned performances), performances with a wrong piece name (24 movements and 43 performances), and performances without a score in the metadata (3 scores and 14 performances). These problems were fixed by matching and checking performances and scores of the same composer.

3.3.3 GiantMIDI‑piano

For GiantMIDI‑Piano (Kong et al., 2022), a curated subset of the original data⁶ consisting of 7,236 MIDI files was used. The analysis of the metadata showed duplicates (by YouTube ID) in the original curated data. In total, 315 MIDI transcriptions were distributed under multiple composition names. Also, manual inspection during the matching process revealed other inconsistencies. A MIDI file may represent only a specific movement of the annotated piece, or it may be a performance of a different piece mistakenly matched after a YouTube search.

Since checking and annotating all MIDI files is exhaustive, only sequences that matched with the scores and performances from other examined datasets were used. The final subset included 2,139 performance MIDI files of musical pieces by 402 composers.

3.3.4 PERiScoPe

The PERiScoPe v1.0 dataset (Borovik et al., 2025)⁷ was processed by excluding performances from ASAP or ATEPP. Only the remaining 34,773 performance MIDI files transcribed from audio sources using Transkun V2 (Yan and Duan, 2024) were used. The dataset required no specific process except for common transcription artifacts, described below in Section 3.3.6.

3.3.5 Aria‑MIDI

From the Aria‑MIDI v1 dataset (Bradshaw and Colton, 2025) with 1,186,253 transcribed MIDI files,⁸ 621,132 files that had a composer in the metadata were filtered and used. There are 19,021 unique composer names in the filtered subset.

An important difference in Aria‑MIDI is how sustain pedals are encoded. The transcribed files do not distinguish between pressed and sustained note durations. The durations were predicted as sustained even when the sustain pedal was predicted separately.

3.3.6 Transcription artifacts

One issue fixed for all transcribed MIDI datasets is the error with ‘infinite’ pitches, where notes span until the end of the file. This artifact arises when open‑source transcription models (Kong et al., 2021; Yan and Duan, 2024) produce unmatched note‑on and note‑off events due to offset or sustain‑pedal decoding errors. During MIDI serialization, such notes remain active till the end of the sequence. An algorithm to identify and correct note durations was developed to repair performances in the source datasets: ATEPP (30 MIDI files), GiantMIDI (9), PERiScoPe (92), and Aria‑MIDI (5,501).

3.6.1 Content and metadata

All score and performance files are organized under the composer/composition/movement/ directory hierarchy, making the dataset easy to navigate and parse. The following unified naming convention is used:

• Composer: composer directories follow IMSLP format [last_name],_[first_name];

• Piece: piece/opus numbers are represented using Arabic numbers, scales follow the format [Note]_[?sharp|flat]_[major|minor];

• Filename: The source of every file is preserved in the metadata and the filename, formatted as [source]_[original_filename].mid.

The dataset provides content and metadata to support various performance analysis and modeling tasks:

• Score: MusicXML and MIDI files, source (ASAP, ATEPP, PDMX, or MuseScore), note count;

• Performance: MIDI file, source (ASAP, ATEPP, GiantMIDI, PERiScoPe, or Aria), flag for a transcribed performance and transcription model name, performer’s name (if available), duration and note count;

• Quality Labels: lead performance (the higher‑priority version of the performance for duplicates), MIDI quality class probabilities and predicted label (‘score’, ‘high quality’, ‘low quality’, ‘corrupted’) (Section 4);

• Alignment: if available, path to the _align.npz file with raw alignment (after Parangonar), path to the _refined_align.npz file with the complete note‑to‑note alignment between the score and cleaned performance, and alignment recall/precision before and after alignment refinement (Section 5); and

• Refined Performance: if alignment is available, refined MIDI file (real and synthetic notes annotated using MIDI markers) that has a complete note alignment with the score MIDI file (Section 5).

3.6.2 Applications

PianoCoRe‑C includes matched score and performance MIDI files from the existing piano score and performance datasets: ASAP, ATEPP, PDMX, GiantMIDI‑Piano, Aria‑MIDI, and PERiScoPe. The combined dataset can be used for tasks that benefit from maximum data scale, such as self‑supervised pre‑training of music models, large‑scale music analysis, or developing data cleaning and filtering techniques.

4.2.1 Note alignment and MIDI quality

The initial hypothesis is that a proxy for MIDI quality is its alignment with the score. The analysis began by examining the differences between recorded performances in ASAP and transcribed performances in ATEPP. In ATEPP, 28.3% of sequences are labeled as ‘high quality,’ ‘low quality,’ ‘background noise,’ or ‘corrupted.’ Figure 4 visualizes the performances using the note ratio $R_n=N_p/N_s$ and adjusted alignment ratio $R_a^{\prime }=\max (R_a,P_a)$ (Section 3.1). This formulation rewards performances that fully align with the score, even if some segments are not performed.

Figure 4

As we see in Figure 4, ‘recorded’ and ‘high quality’ performances cluster in the upper part ($R_a^{\prime }>0.85$), indicating strong alignment with the scores. In contrast, ‘corrupted’ files are inconsistently scattered, including both well‑ and poorly‑aligned performances, while ‘low quality’ and ‘background noise’ sequences overlap with high‑quality and corrupted transcriptions.

Manual inspection of the MIDI files revealed inconsistencies in the original ATEPP labels. Some ‘low quality’ and ‘unlabeled’ files with poor alignment (e.g., 02709.mid, 03001.mid, 10193.mid) contain clearly broken transcriptions. In contrast, a few files labeled as ‘corrupted’ (e.g., 01591.mid, 05389.mid) align well and are musically usable. Thus, the existing audio‑based labels do not reliably reflect MIDI quality.

4.2.2 MIDI quality training dataset

Based on the analysis of alignments and the adjusted ratio $R_a^{\prime }$, a soft data‑labeling heuristic is proposed. Combined with score and recorded MIDI files the four quality classes are defined as follows:

1. Score (S): deadpan score MIDI performances;

2. High Quality (HQ): any recorded MIDI, transcribed MIDI with $R_a^{\prime }>0.9$;

3. Low Quality (LQ): transcribed, $0.7<R_a^{\prime }<0.85$; and

4. Corrupted (C): transcribed, $R_a^{\prime }<0.65$.

The quality ranges are chosen to be disjoint at the boundaries to create clearer distributions for training.

The heuristic was applied to label the deduplicated performances aligned with musical scores. Table 2 shows the distribution of the soft quality labels.

These data were used to sample subsets for training, testing, and calibration. To ensure composition leakage, a piece‑based split was applied, maximizing the number of the real corrupted samples in the test set. Second, to create a diverse dataset, there are no more than three samples for each musical piece from each data source (ASAP, ATEPP, PERiScoPe, and Aria‑MIDI), as well as a soft quality label (HQ, LQ, and C).

As seen in Table 2, LQ and C soft labels are underrepresented. For training, 2,500, 1,000, and 86 real HQ, LQ, and C samples, respectively, are balanced with synthetic performances built from the sampled HQ MIDI files. The artificial corruptions for LQ/C classes included random note removal (15%–25%/35%–50%), onset/offset jitter (up to 20 ms/150 ms), velocity jitter (up to 5/20 bins), and random note insertions (up to 5%/30%). Similarly, 953 real scores were augmented with 1,447 synthetic versions (randomized constant velocities, 10‑ms onset jitter) to simulate transcription artifacts for score‑based audio.

For validation and testing, 200 real Score HQ, and LQ samples are selected alongside 54 Corrupted performances. The classifier calibration set includes all of the real samples from the evaluation split, with no more than three samples per piece, source, and class. The class distributions per each set are shown in Table 3.

4.2.3 MIDI quality classifier

The data representation consists of a stacked sequence encoding with five note features: Pitch, TimeShift (s), Velocity (MIDI bins), Duration (s), and absolute TimePosition (s). This encoding does not contain any score features (beat positions and durations) to make the model score‑agnostic and universal.

The backbone is a 12‑layer transformer encoder (Vaswani et al., 2017) with 80 million parameters, pre‑trained using a multi‑mask language modeling objective (Borovik et al., 2025). The model dimension is set to 768, and self‑attention is extended with Rotary positional embeddings (Su et al., 2024). Real‑valued note features are passed to sinusoidal embeddings (Guo et al., 2023) for lossless encoding. For classification, penultimate‑layer embeddings are prepended with a [CLS] token and processed by a one‑layer transformer (dimension 128) and a classification head.

The pre‑training was conducted on the deduped subset of Aria‑MIDI (Bradshaw and Colton, 2025) with 371,053 diverse piano MIDI files, provided with the official dataset release. The maximum context length is set to 512 notes. The pre‑training included 600,000 steps with batch size 128, while the fine‑tuning took 20,000 steps with batch size 512. Training data augmentation included pitch shift ($\pm 6$ semitones), velocity shift ($\pm 6$ MIDI bins), and tempo stretching ($\pm 5\%$).

The trained MLM backbone was verified on emotion and pianist classification tasks. On the EMOPIA dataset (Hung et al., 2021), the classifier achieved a test accuracy of 72.7% and an F1 score of 72.1%. On the Pianist8 dataset (Chou et al., 2024), the accuracy and F1 score were 86.4% and 85.5%. The metrics are close to similarly sized models (Liang et al., 2024) and slightly below those of larger models (Bradshaw et al., 2025).

4.2.4 Results

Table 4 shows the evaluation results of the classifier configurations tested on the balanced test set.

The best configuration achieved a macro F1 score of 89.1% on the held‑out test set. It learned to perfectly distinguish score‑like MIDI files and showed less errors between HQ, LQ, and C classes. The synthetic training samples and token‑based aggregation helped to learn more robust decision boundaries. Masking of note features revealed the shared contribution of pitch, dynamic, and timing to MIDI quality classification. Since note‑level alignment is imperfect and quality is continuous rather than discrete, errors on the test set are expected.

4.4.1 Applications

PianoCoRe‑B is designed for tasks that depend on large amounts of clean and reliable piano performance data. Specifically, this dataset is useful for large‑scale, self‑supervised pre‑training; musical analysis of performance styles; and piano performance generation.

5.2.1 Alignment hole processing

The first step detects and removes large, structurally incorrect alignment sections. An ‘alignment hole' is defined as a continuous region of notes where the alignment is sparse or nonsensical (only a few notes are aligned). In scores, the holes correspond to unperformed score measures (e.g., repeats), whose individual notes may be incorrectly matched with random performance notes. In the performances, the holes are the extra performed segments whose notes may be inadvertently aligned with random score notes.

To detect holes, a sliding window approach is used. Let $H_a$ be a ratio of unaligned notes within a surrounding window of $H_w$ notes for a given note. If $H_a$ ratio exceeds a threshold $H_r$, the note is flagged. Contiguous regions of flagged notes are designated as holes, and all alignment pairs within them are removed.

The default values are $H_w=31$ notes and $H_r=0.75$. The window size is close to double the median (15) and mean (16.9) number of notes in a measure in all scores in the dataset. With this window, we consider on average one measure to the left and one to the right. Setting the threshold at $75\%$ ensures that only regions that are almost entirely unaligned are removed.

5.2.2 Onset cleaning and temporal refinement

This stage refines the temporal alignment of concurrently played notes (chords) and corrects large‑scale time shifts. First, all aligned notes are used to build the initial onset pair list: tuples of score onset beat $o_i$ and the average performed onset time $t(o_i)$ for all notes in the chord. Then, note and onset times are checked for misalignments and outliers based on:

• high intra‑onset deviations and

• inter‑onset intervals that deviate from the local performance tempo.

For intra‑onset deviations, the onset deviations $\mathrm{\Delta }{t}_i(n_j)=t(n_j)-t(o_i)$ from $t(o_i)$ are computed for all notes $n_j$ in a chord: $\{n_j|o(n_j)=o_i\}$. By default, notes whose onsets deviate from $t(o_i)$ by more than two standard deviations are removed from the alignment as outliers. For chords with two distant notes, both notes will be removed if the condition is met.

For inter‑onset intervals, the method estimates the maximum and minimum plausible time shifts $\mathrm{\Delta }{t}_{\max }(o_i)$ and $\mathrm{\Delta }{t}_{\min }(o_i)$ between the current and previous score onsets $o_i$ and $o_{i-1}$. If the time interval between the current and previous onset implies a tempo outside a plausible range (by default, 15–480 BPM), it is identified as an alignment jump. This onset can be filtered out of the alignment. However, by default, the timing of the notes of the affected onsets is adjusted.

First, a local tempo ${\tau }_{\mathrm{local}}(o_i)$ is estimated based on a $w$‑second window (by default, $w=8$) of preceding performed note onsets ${\mathrm{O}}_{\mathrm{local}}(o_i)=\{o_j|t(o_i)-t(o_j)<w\}$. Then, the expected onset time $\hat{t}(o_i)$ is computed using the inter‑onset beat shift ${\mathrm{IOI}}_i^s=o_i-o_{i-1}$ and ${\tau }_{\mathrm{local}}(o_i)$. Using the expected onset time, the required time shift $\mathrm{\Delta }{t}_{\mathrm{adj}}(o_i)=\hat{t}(o_i)-t(o_i)$ is determined, and the subsequent performance notes are shifted accordingly.

This step explicitly alters the global timing in the original performance MIDI. However, after the shift, the onsets fall into the range of the plausible local tempos, and tempo outliers are not learned by the trained models. Any unperformed notes can be also naturally filled in with the same local performance tempo.

In addition, close onset pairs with $\mathrm{\Delta }t(o_i)=t(o_i)-t(o_{i-1})<0.01$ (10 ms) are filtered out to avoid two same‑pitch note‑on events (which is impossible for a human performer). After the alignment hole processing and onset cleaning, the algorithm cleans up the performance MIDI by removing notes without a link in the alignment. In the end, only matched and cleanly performed notes remain.

5.2.3 Note interpolation

This step interpolates the unperformed notes to create parallel note‑aligned score–performance pairs.

The note onset time $t(n_i)$ of a note $n_i$ is linearly interpolated from two neighboring performed notes $n_j$ and $n_k$. To avoid the contribution of very close notes, the configurable minimum beat and time intervals $n_j$ and $n_k$ between the two anchor notes are used ($t(n_k)-t(n_j)\ge \mathrm{\Delta }{t}_{\mathrm{int}}$ and $o(n_k)-o(n_j)\ge \mathrm{\Delta }{o}_{\mathrm{int}}$).

Note articulation (duration) and dynamics (MIDI velocity) are averaged and weighted by the performed notes in the neighboring beats. The weights are inversely proportional to the absolute beat distances ${\mathrm{IOI}}_{i,j}^s=|o(n_j)-o(n_i)|$ from the score position of the note $n_i$ being interpolated. Closer notes contribute a higher weight to the interpolated features.

The algorithm prevents the creation of notes with identical pitch and onset, and shortens overlapping notes so that at each new key press the previous note is closed. The result is a performance MIDI file fully aligned with the score at the note level. Interpolated notes are marked with a special MIDI text marker, allowing them to be filtered out or marked during model training.

5.2.4 Performance–score synchronization

This step synchronizes the beat structure of the refined performance MIDI with the score. This data format is commonly used in MIDI encodings with beat/bar tempo (Huang and Yang, 2020; Hsiao et al., 2021; Zeng et al., 2021). The alignment pairs are used to compute a beat‑to‑time mapping and insert inter‑beat tempo changes into the performance MIDI. For example, for a 4/4 time signature and 480 ticks per quarter, notes at the beats are separated by 480 ticks in both the score and performance MIDI, with exact times derived from tempo changes.

Finally, the entire performance is shifted so that its first played note occurs at the same time as the first score note, ensuring a consistent starting point for all performances of the same composition.

5.2.5 Final output

The algorithm returns the refined alignment, refined performance MIDI, and note‑level alignment recall ratios. The recall values from different stages (initial, hole processing, and onset cleaning) serve as quantitative indicators of alignment quality and can be used to interrupt the refinement process. The alignment is released as a compressed .npz file containing an array of performance note indices aligned to the sorted score MIDI notes, along with a boolean mask for interpolated notes. All MIDI processing steps are performed using the symusic Python library (Liao et al., 2024).

The presented refinement does not rematch links produced by the note aligner. It only filters existing links and interpolates missing notes. Each step of the pipeline can be enabled independently. Default parameters were chosen empirically rather than optimized, as automated evaluation would require precise human annotations. Custom clean datasets can be generated using the released raw alignments and MIDI files.

In PianoCoRe, all refined performance MIDI files underwent the first three stages of the RAScoP alignment and the final initial performance onset shift. Beat synchronization was not applied in order to preserve the original timing without re‑quantizing the note onsets and offsets. Synchronization can be computed using the refined score MIDI, performance MIDI, and note‑level alignment.

5.4.1 Applications

PianoCoRe‑A/A* represent a large‑scale resource of score–performance–aligned piano MIDI data. They pave the way for training more nuanced models for rendering expressive piano performances without having to perform rigorous data matching and alignment.

6.2.1 Training convergence

Figure 8 illustrates the feature‑based validation losses tracked during training. Each model was evaluated on a validation set drawn from the same source data (e.g., the ‘ASAP+ATEPP’ model on unseen ‘ASAP+ATEPP’ performances). The results reveal a pattern: the model trained only on ‘ASAP’ quickly overfits, demonstrating that a small dataset, even of high quality, is insufficient. As the scale of the data increases (‘+ATEPP’, ‘+PERiScoPe’), overfitting is delayed.

Figure 8

The comparison between the ‘PianoCoRe‑A’ model (blue) and its unrefined counterpart ‘w/o RAScoP’ (gray) provides direct evidence of the value of the refinement pipeline. The refined dataset yields a more stable and consistently lower validation loss, particularly for the note time shifts. This confirms that targeted removal of temporal noise is crucial for learning an accurate timing model.

6.2.2 Unconditional generation

This section presents the evaluation results for the unconditional performance rendering. The inference set included test set scores with at least three performances from two different MIDI sources (e.g., ASAP and Aria‑MIDI). The models rendered each score in its entirety seven times. Pearson correlation (Borovik and Viro, 2023; Jeong et al., 2019b; Zhang et al., 2024) between the note features of the dataset and rendered performances was computed. The evaluated features are: onset velocity (Vel), relative inter‑onset intervals (IOI), relative intra‑onset deviations (OD), and note articulation (Art).

Table 7 presents the mean Pearson correlation between the model outputs and the ground‑truth performances from a multi‑source test set. Models trained on more diverse datasets (‘+ ATEPP’, ‘+ PERiScoPe’, and ‘PianoCoRe‑A') consistently outperform the baseline trained only on ‘ASAP’. Interestingly, the model trained on ASAP and ATEPP shows higher correlation with an average set of performances from PianoCoRe‑A. This may be because ATEPP specifically focuses on the performances of renowned pianists. Other datasets contain a wider variety of performance styles.

More training data with more interpolated notes ($R_{\mathrm{RAScoP}}\ge 0.7$) slightly hurts the unconditional rendering capabilities. The model trained on raw data without the cleanup shows lower correlation with higher quality performances for note timing (IOI and OD).

6.2.3 Performance continuation

The final analysis evaluated the models in a performance continuation task across four distinct test domains: ASAP, ATEPP, PERiScoPe, and Aria. As in the previous experiments, compositions and performances were not seen during the training. The models performed 256 notes in parallel using the performance context of the preceding 256 notes. Table 8 shows the mean absolute error computed against the ground truth performance features.

The results complement the previous findings. With more training data, the model performs better on MIDI files of different sources. PianoCoRe‑A achieves the best average performance on ASAP and Aria‑MIDI performances and second‑best results on the other subsets. Only the model trained on data without overrepresented Aria‑MIDI achieves similar or lower errors on ATEPP and PERiScoPe. Given the validation loss plots in Figure 8, the full dataset model has room for an improvement in the long run. Overall, the results show the potential of PianoCoRe for training performance models robust to varying piano data distributions.