Pipeline

Three spelling dialects

Comparison basis: what counts as a claim

The engines segment the music independently. musWM often assigns one label to a whole harmonic span, whereas AnalysisGNN tends to label every beat. To place them on a common grid, alignment carries each engine’s most recent label forward within its bar, so a cell may hold a label the engine never asserted at that position. Such cells are marked held.

Every figure on this site uses the onset basis. A held cell is treated exactly like a missing label: it is displayed struck through and receives no grade. The question is therefore: where an engine actually commits to a label, do the engines agree?

In When-in-Rome 335, 37.8% of all labelled cells are held (105,278 of 278,392). A choice with that much influence on the result is fixed rather than left to a setting.

Alignment: where a label is placed

A corpus is built under one of two alignments, named in the note above every table. This corpus uses window.

Only musWM labels are ever moved. AnalysisGNN and AugmentedNet report no analysis window — they label onsets directly — and are used exactly as their adapters return them. The builder restricts repositioning to musWM by name, and a before-and-after comparison confirmed that the rows of the other two engines pass through byte-identical.

Should two musWM labels would land on the same position, the second move is not made and that label keeps its own beat, so no label is lost.

In When-in-Rome 335, 12,174 of 44,850 musWM onsets (27.1%) were repositioned.

What the choice of alignment changes

Repositioning can only move a musWM label away from one position and onto another. Leaving a beat for which it had no evidence removes a disagreement that was never a genuine claim; leaving a beat on which all three engines happened to agree removes an agreement; arriving at a new beat creates a new comparison. No position at which all three engines remain present switches between identical and different. Because the pool of comparable rows changes, an agreement rate is meaningful only together with the alignment under which it was computed.

Where a label sits is not always where its evidence is

Two further effects can separate a label from the moment it describes. Both arise in the shared alignment step, so the RN tab of the main site exhibits them as well.

Comparison modes

Only the normalised comparison is used on this site. The strict and degree-only modes are described for completeness; neither is offered in the tables.

Differences that normalisation deliberately preserves: Cad64 ↔ I64 (a cadential reading of the six-four), different applied targets (/III ↔ /V), and different local-key decisions.

Repeated labels

A label is written once, at the row where its run begins; later rows of the same run are left blank for that engine. This is a fixed presentation choice.

In When-in-Rome 335 nearly every repeat is a carried cell rather than a genuine re-assertion: of 106,074 repeated cells, 105,278 are carried, and only 784 are an engine emitting the same label again at the next onset (760 AnalysisGNN, 24 AugmentedNet). On the onset basis, hiding repeats therefore changes what is read, not what is counted.

Row classes

Grading

All grades on this site are derived from the textbook and locked. At every row where all three engines emit a label at the same onset, the reference is the Roman numeral that Kostka, Payne & Almén, Tonal Harmony, 8th edition, assign given musWM’s local key, mode and chord code at that position.

Grades are the same on Alignment and Disagreements, and none can be changed by hand. Where the textbook accepts two spellings of one chord — a suspension figure over the same degree (pp. 201–202), or V/III ≡ VII in minor (p. 257) — both count as equal for all three engines.

Tolerances. A triad and a seventh chord on the same root and bass count as the same label (V = V7, V6 = V65, V64 = V43, vii° = vii°7 = viiø7); a different bass is still a difference. The grades are therefore tolerant agreement with the textbook label, not exact label identity.

An engine’s score is correct ÷ graded, reported over all compared rows and separately for Alignment and Disagreements. Ratings lists every reason a row was not compared, with counts, together with the number of labels each engine emitted, so the share of the corpus behind each figure is always in view.

What the figure does and does not say. The reference is built from musWM’s reading — its key, notes, bass and root — but never from its label. Where musWM’s label departs from the textbook label, musWM scores 0; the reference stays as the textbook writes it, and AnalysisGNN and AugmentedNet are checked against that same label, so an engine that writes it scores 1 even where musWM scores 0. Because the key is musWM’s, a label that would be right in a key another engine read differently scores 0; the share of compared rows on which each engine shares musWM’s key is reported beside the result. On Alignment rows the three engines wrote the same label and therefore share a score by definition.

Placement on the written bar

AnalysisGNN and AugmentedNet read the MusicXML and report written bar numbers. musWM reads MIDI, and until 15 September 2026 that MIDI was MuseScore’s export of the score, which plays repeats and numbers bars on its own timeline. musWM’s bar numbers therefore did not always name the written bar: in some works every label sat one bar or four bars off, repeated sections were analysed twice, and one export stopped before the end of the score.

musWM’s input is now rendered from the MusicXML in written bar order, one MIDI bar per written bar with the bar’s real length (pickups and irregular bars included). Each musWM row is placed by its own time position: tick → written bar → written bar number and beat. The label itself is not touched. All three engines now share one timeline, and every work uses the direct bar map.

Alignment check. The build then tests, for every work and engine, whether the notes an engine reports at an onset exist in the written bar the row is shown on: the bass for all three engines, and musWM’s analysed pitch classes as well. It does not ask whether a chord is right, so it favours no engine. A work fails when musWM’s or AugmentedNet’s bass is found in the bar less than 90.0% of the time; AnalysisGNN is reported but does not decide, because its bass is a separate per-note prediction rather than the bass of the chord it labels.

The 3 remaining works (126, 162, 179) show scattered misses rather than a constant offset and are listed for review by eye; they are left out of the independent note check. Where a musWM label would be moved onto a position another musWM label already holds, the move is not made and the label stays on its own beat, so no label is lost; no collision warning remains.

Independent note check

The textbook grades take musWM’s key, root, bass and notes as given, so they cannot show whether those choices are right. This check builds its reference only from the notes written in the score — no engine output, no chord code — and applies it to every engine that reports the field.

• A bar is used only when all its notes (every part, concert pitch, grace notes ignored) form exactly one complete triad or seventh chord; augmented triads and diminished sevenths are left out because their root cannot be read from the notes.
• The written spelling must stack in thirds from that root, so E–G–A♯ is not read as E diminished.
• Every beat must contain the root, and no beat may hold a complete triad on another root, so a bar that moves C–E–A → F–A–C is not taken as one F major seventh.
• The bass is the lowest sounding note, tested only where it stays the same through the bar.
• Key cannot be read from one chord; it is tested only for compatibility with the written key signature, which counts every modulation as incompatible and is therefore not a key accuracy.

The check covers the unambiguous case only. It does not grade Roman numerals, it does not reach passages with chord changes, suspensions or passing tones, and its result cannot be generalised to the whole corpus. Results are on the Summary.

Bar-number mapping

Since 15 September 2026 all three engines report written bars and every work uses direct. The other two mappings are kept for corpora built before that date, where musWM could follow the repeat-expanded order of performance.

The mapping used for each work is listed under Works. Where there is doubt, switch the score window to Whole work and confirm the bar by eye.

Corrections

15 September 2026.

• Alignment fault corrected. musWM labels had been placed on MIDI bar numbers rather than written bars (see Placement on the written bar). The whole corpus was rebuilt with the current engine. Every figure on the site changed; the three-engine agreement rose from 20.2% to 22.5% over 16,091 comparable rows.
• Textbook criterion audited. The coded rule set now reproduces all 56 labelled chords of the book’s reference examples (Examples 16-3, 16-4, 17-1, 17-2 and the tables on p. 65); the first version reproduced 50. V7/VI in minor is now derived as the book writes it; the secondary functions of VII in minor and the melodic-minor chords with the same notes are accepted in both spellings for every engine; positions whose notes form an augmented sixth chord are left out for every engine, because the notes alone cannot separate it from V7/♭II. Known limits that need context (Picardy third, common-tone diminished seventh, which note of a chord is a nonchord tone) are stated rather than hidden.
• Two engine rules corrected after the audit (user approval). In minor, a major-minor seventh chord on III is now written V7/VI rather than III7 (Example 16-4, p. 257; 97 events). A leading-tone chord (vii°, vii°7, viiø7, secondary ones included) is no longer read where the root of the V7 that contains it sounds in musWM’s window and had been set aside as a nonchord tone; the chord is then written as that V7 (187 cells). Theory conformance moved from 96.1% to 96.8%.
• Grading: leading-tone references checked against the score. Where the textbook reference is a leading-tone chord but the root of the V7 containing it sounds in the written score at that onset, the reference would rest on musWM’s window leaving that note out; such positions (27) are not graded, for any engine.
• Margin statement withdrawn. The earlier “±5 / ±1 point” margin mixed a resampling interval with a rule-change shift and is no longer given.
• Independent note check added (above).

What these figures do not establish

• They do not show that any engine is correct in an absolute sense. Agreement among three engines may reflect a shared convention as readily as a shared mistake.
• The textbook grade tests naming, not hearing. The key and notes are musWM’s, so the grade asks whether a chord, as musWM read it, is named as the textbook would name it. It is not an accuracy, and the three engines’ grades are not a ranking.
• The independent note check covers only bars holding one unambiguous chord; it says nothing about passages where the harmony changes inside the bar.
• An agreement rate depends on its denominator. The Summary reports agreement over comparable rows; a rate over all rows would be a different number and cannot stand in for it.
• A coverage gap is not a disagreement, and the two are never pooled.
• Labels are never recomputed in the browser. The pack holds what the engines produced on the day it was built.
• Every figure uses the onset basis. A figure that counted carried labels would answer a different question and cannot be compared with these.
• A row’s bar and beat are where the aligned table places the label, not necessarily where the engine found its evidence. The evidence line in the score window shows the difference.

The three engines differ in a property that matters as soon as analysis has to keep pace with listening. musWM is rule-based, causal and explainable: a label is formed from the notes held in a capacity-limited window, uses nothing that has not yet sounded, and carries the representations it was derived from. AnalysisGNN and AugmentedNet are learned score-level models; both take a complete score and use bidirectional context, so each label also depends on later music. On this site all three were run on complete scores, so the comparison itself is unaffected; the difference concerns what each engine can do during listening.

Sources: the pinned implementations used here (AugmentedNet models.py and inference.py; AnalysisGNN models/analysis.py, models/chord.py). This describes design objectives, not analytical quality.