Skip to content

Library repair: split glued chord runs, rescue orphaned rows (v2026.09.07.003) - #37

Merged
cdburgess75 merged 1 commit into
mainfrom
claude/hello-lr09iw
Sep 7, 2026
Merged

cdburgess75 merged 1 commit into
mainfrom
claude/hello-lr09iw

Conversation

@cdburgess75

Copy link
Copy Markdown
Owner

Driven by an audit of a real 50-song backup rather than guesses. Three render-time fixes, so songs already in a library heal without being re-imported.

Measured over that library: 298 → 418 coloured chords, with no song losing one — checked per song, not just in aggregate.

1. Space-stripped chord runs (8 songs, 23 lines)

Some songs store a whole progression as a single token — DDCD, GmFDmCGmFDmCA — from a paste that ate the spaces. splitChordRun() greedily splits it back, returning null unless the whole string is consumed by real chords, so a leftover character rejects the line rather than half-parsing it.

The safety comes from case: a chord root must be an uppercase A-G, so "Cage", "Face" and "Bag" die on their second character. Twelve English words were confirmed unsplittable.

Verified against the actual music, not just the regex:

GmFDmCGmFDmCA  -> Gm F Dm C Gm F Dm C A   (White Room — the real verse progression)
CGBdA          -> C G Bb A                 (White Room chorus)
DDCD / GF#C    -> D D C D / G F# C         (Sunshine of Your Love)
GAmDG          -> G Am D G                 (Tequila Sunrise)
BA#/F#G#mF#EF#B-> B A#/F# G#m F# E F# B    (New Orleans Ladies)

2. Orphaned chord rows (23 rows)

Chord line, then a whitespace-only line, then the lyric — the lyric's leading spaces were split onto their own line, leaving the chord stranded above nothing and the lyric bare underneath. Now paired across the junk line.

A genuinely empty line must never trigger this. "Intro chords, blank, verse" is a deliberate layout and pairing there would drop the intro onto the first sung line, so the 17 rows separated that way are left exactly as they are.

3. Bd → Bb (6 occurrences)

A corrupted flat, confirmed by the owner. Bare letter only — C#d and G#d already carry an accidental and would become "C-sharp-flat", so they stay flagged as unknown. Length-preserving (2 chars → 2), so pairToSegs' column alignment is untouched.

Verification

  • Before/after over all 50 backup songs with a per-song regression check: no song may lose a pill.
  • Every split asserted against its real progression; 12 English words confirmed unsplittable; the empty-separator case confirmed unchanged.
  • Existing suites green: charts 14, links 24, showcase 11, wake 11.
  • Seed songs render byte-identically.
  • CI equivalents run locally.

Finding worth recording

Roughly half that library has no chords in the stored data at all — imported as lyrics only. No parser change can conjure those; they need re-importing from a source that carries chords. Recorded in CLAUDE.md §2 so the next person doesn't go hunting for a rendering bug that isn't there.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB


Generated by Claude Code

…9.07.003)

Driven by an audit of a real 50-song backup rather than guesses. Three
render-time fixes. Across that library no song loses a chord and the total
goes from 298 to 418 coloured chords.

SPACE-STRIPPED CHORD RUNS. Eight songs store a whole progression as a single
token -- "DDCD", "GmFDmCGmFDmCA" -- from a paste that ate the spaces.
splitChordRun() greedily splits it back, returning null unless the whole
string is consumed by real chords, so a leftover character rejects the line
rather than half-parsing it.

The safety comes from case: a chord root must be an UPPERCASE A-G, so "Cage",
"Face" and "Bag" die on their second character. Verified against the actual
music, not just the regex -- White Room yields Gm F Dm C Gm F Dm C A, which is
the real verse progression.

ORPHANED CHORD ROWS. Chord line, then a whitespace-only line, then the lyric:
23 rows where the lyric's leading spaces were split onto their own line,
leaving the chord stranded above nothing and the lyric bare. Now paired across
the junk line.

A genuinely empty line must never trigger this. "Intro chords, blank, verse"
is a deliberate layout and pairing there would drop the intro onto the first
sung line, so the 17 rows separated that way are left exactly as they are.

"Bd" to "Bb", a corrupted flat the owner confirmed, six occurrences. Bare
letter only: "C#d" and "G#d" already carry an accidental and would become
"C-sharp-flat", so they stay flagged as unknown. Length-preserving, two
characters to two, so pairToSegs' column alignment is untouched.

Verified: before/after over all 50 backup songs with a per-song regression
check (no song may lose a pill); the seven improved songs listed; every split
asserted against its real progression; twelve English words confirmed
unsplittable; the empty-separator case confirmed unchanged. Existing suites
green -- charts 14, links 24, showcase 11, wake 11 -- and the seed songs
render byte-identically.

Finding worth recording: roughly half that library has no chords in the stored
data at all, imported as lyrics only. No parser change can conjure those.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@cdburgess75
cdburgess75 merged commit 2f25577 into main Sep 7, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants