Summary

parse_lrc_metadata stops at the first ], so [ti:Vision [Radio Edit]] parses as the title Vision [Radio Edit. import_lyrics_files compares the tag against the song's title exactly, so such an .lrc matches no song and is reported unmatched.

Changes

• Find the closing ] by bracket depth (find_tag_close) instead of taking the first one.
• Regression tests for bracketed values, and for the two behaviours that stay the same.

Acceptance criteria

1. Balanced brackets in [ti:], [ar:] and [al:] are kept — parse_lrc_metadata_keeps_brackets_inside_values.
2. [ar:X][ti:Y] on one line still reads the first tag, and a value whose brackets never balance still falls back to the last ] — parse_lrc_metadata_handles_unbalanced_brackets_in_values.
3. Such an .lrc matches on import — manual: 23 audio files and their .lrc files into an empty library on Windows, all 23 matched. The Vision [Radio Edit] title was unmatched before this change.

Test plan

• cd src-tauri && cargo test — 1219 passed. Its 19 failures also fail on unmodified main in this environment. nextest isn't installed here.
• cargo clippy --all-targets -- -D warnings — its 2 errors also occur on unmodified main here, both outside the changed code.
• node --run lint and node --run build — pass; no frontend change.
• docs/references/contracts/*.md — no IPC command, payload or event changed.
• Product standards: lifecycle, quality and testing. ISO 25010 functional correctness. Regression coverage added; no ADR.

Related issues

Closes #465

🤖 Generated with Claude Code

parse_lrc_metadata now preserves balanced brackets in [ti:], [ar:], and [al:] values. This allows LRC files with values such as Vision [Radio Edit] to match songs during lyrics import. Unbalanced bracket values retain the existing behavior.