Library repair: split glued chord runs, rescue orphaned rows (v2026.09.07.003) - #37
Merged
Merged
Conversation
…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
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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, returningnullunless 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:
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#dandG#dalready carry an accidental and would become "C-sharp-flat", so they stay flagged as unknown. Length-preserving (2 chars → 2), sopairToSegs' column alignment is untouched.Verification
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