Build progress: v1 → v2

In v1, the Song Structure lane reused the existing free track analysis and drew coloured section bands, key chips and a chord lane. The analysis underneath was simple:

• A 3-minute song always became 4 slices, even when the real change was somewhere else.
• A single noisy beat could flip the chord label, so one held chord showed up as several.
• Anything after 2 minutes was never analysed, so long songs showed a truncated structure.
• Existing tracks with the old data never picked up any fix.

The lane at webapp/static/js/song-structure.js showed what the worker returned. It did not compute anything in the browser. Numbers came from the saved analysis on the track.

Analysis still runs on the auto-scaled worker, not on the API gateway. Nothing was added to request handlers. No new job type, no new charge, no database schema change.

Kept for comparison: chord_timeline(use_decoder=False) still runs the old per-beat path. Beat times are read-only input: the beat grid (SANCT) is never changed by this work.

The browser only draws what the worker saved. Chord lane, key chips and section bands read from the same stored analysis.

Not verified a fresh browser pass on a real track in the Song Structure view. The last recorded browser pass was on v1.

Uploads are the entry point for analysis, so the upload fixes from the same day are part of this path:

• Client-compress and import concurrency raised to 3 lanes (8172a55e).
• Rows claimed synchronously to stop duplicate upload POSTs (6436b9fc).
• Import meter and row percentage driven from one clamped byte source (9ceadf4a).

Python's round(4.5) is 4, so an earlier expectation was wrong. The code's floor(x + 0.5) gives 5 and is correct.

Ledger source: git log on session/20261019-220540-cx. Commits outside the analysis and display path are not listed.

• docs/work-dispositions/section-tiling.md and section-tiling-blocked-disk.md
• docs/work-dispositions/harmonic-chord-decoder-r1.md
• docs/work-dispositions/songchop-section-chord-upgrade-retro.md (lessons and friction)
• docs/reports/song-analysis-algorithm-progress.html (the earlier report this one extends)

• webapp/app.py is already clean: app.py:32641 calls detect_per_section_keys(audio_data, sr) with no sections=4. The stale sections=4 site is tools/song_intel_demo.py:119 (ignored argument, harmless). The other sections=4 calls are intentional compatibility checks in scripts/verify_track12_harmonic.py and scripts/verify_section_tiling.py.
• Some older receipts still describe the chord decoder as unwired or unverified.
• scripts/verify_track12_harmonic.py expected-count fix from the old fixed 4.

1. Run the Song Structure view on a real track and screenshot it (display check).
2. Measure worker time for a 3 to 5 minute real track (cost check).
3. Build a small rights-safe real-music set and run the verifiers on it (accuracy check).
4. Clean up the stale call sites once the above is in.

Plan only Nothing in this tab is MEASURED

v3 is a proposal for the section boundary detector, per-section keys, chord decoding, the display, and the evidence needed to trust them. No v3 code has shipped. Every effort, cost and risk figure below is an ESTIMATE. No accuracy number is claimed, because no labelled data or evaluation harness exists yet.

Nothing here is MEASURED. No accuracy figure is claimed for any aspect.

• tab-impl: i-verdict: decision summary.
• tab-impl: i-laws: SANCT and storage constraints.
• tab-impl: i-cost: CPU cost.
• tab-impl: i-road: phased roadmap. Phase 0: benchmark and ablation gate, own segmenter within about 10 points of HR3F. Phase 1: sections sidecar job, table, migration, touch points T1 to T4, GET route. Phase 2: bar-level chord Viterbi. Phase 3: per-section key and modulation. Phase 4: per-stem, later. Backfill only after the Phase 1 gate.
• tab-order: order-root: ship a thin display on a versioned, additive JSON contract. Sections are not ready for display until Phase 0.
• tab-evolution: e-v3: evidence-gated drift and meter, keyed on (audio_hash, grid_revision_hash, analyzer_version). Downbeat F within ±70 ms gate. NOT MEASURED.
• tab-evolution: e-ablation: v2 synthetic chord regression FAILED (chords_distinct_in_path: 1).
• tab-evolution: e-cost: CPU first, no GPU.
• tab-evolution: e-answer, e-boundaries, e-gates, e-priority, e-risks, e-unverified: decision, boundary, gate, priority, risk and unverified notes.

Ids only. Line numbers beyond the ids have not been rechecked.

• SANCT beat grid is sacred. Never alter beat cut points. No zero-crossing snapping on loops or segments. Sections are analysis metadata; beat_times is read-only.
• The API gateway only enqueues. Processing runs on auto-scaled workers.
• No new charge and no schema change without a plan.
• Whole-track analysis stays cache-keyed by audio_hash.

• No labelled data and no eval harness exist.
• Real-music segmenter accuracy is unmeasured.
• Worker job duration is unmeasured.
• The v2 display has never been browser-checked.
• Model licences are unchecked.
• Roadmap line numbers beyond the ids were not rechecked.
• No browser is installed in this environment, so no page rendering or nav click was tested.

Research and plan only No labelling code has shipped

VERIFIED-ON-PAGE ESTIMATE / UNVERIFIED PLAN INFERENCE VENDOR CLAIM

Competitors that publish anything label sections with a short fixed vocabulary (intro, verse, chorus, bridge, outro) over boundaries found by analysing the audio. None of the pages we could open publish how, and only one (rekordbox) names a sub-section event (Fill in). The method the research literature supports is repetition first: compare bars with each other to find which bars belong together (repetition), use novelty (sudden change) to place the boundary, and let repetition choose the label while novelty sets the boundary. We plan to read labels off the SANCT bar grid, label only above a confidence threshold (otherwise "Section" or "Variation"), and treat fills, turnarounds, buildups, breaks, risers and stops as deviations inside a repeating section. Nothing is built; no accuracy is claimed.

What this tells us

• No competitor page we could open publishes a method, dataset or accuracy.
• Of everything opened, only rekordbox names a sub-section event (Fill in), and only allin1 has a "break" label. None states turnaround, buildup, riser or stop detection. This is scoped to pages opened, not the whole market.
• Section names are vendor-defined, not a standard. Cyanite returns unnamed segments.
• Licences differ. allin1 is MIT. SongFormer code is CC-BY-4.0 with model and dataset terms unchecked. Both are candidates only, gated on licence review.

Reconciliation rule

Repetition assigns the label: which bars belong together, and which group is chorus-like. Novelty sets the boundary: the strongest novelty peak within one bar of the repeat edge, on the SANCT bar grid, never off-grid. PLAN ESTIMATE thresholds, set on the labelled set.

• Boundary: if the repeat edge and the novelty peak differ by 1 bar or less, use the peak bar. If they differ by more than 1 bar, keep the repetition edge only when the repeat is strong; otherwise emit a boundary labelled "Section".
• Label: a novelty boundary with no repeat evidence gets "Section", never a guessed name.
• Repeat without a peak: a repeat with no novelty peak stays as "Variation" inside the parent section, not as a new section.

INFERENCE Moises' method is likely repetition-based. No Moises page says so, and this is UNVERIFIED.

Illustration only. No data claims. Fill marker shown inside a Chorus bar.

Fill marker: a sub-section event sitting inside the parent Chorus bar, not a new section.

Processing

The API gateway only enqueues. The work runs as a queued job on auto-scaled workers. Measure job duration on a worker before any price is set. Additive JSON fields and an analysis-version bump plan. No schema change without a plan. PLAN

The layout has a tag legend at the top. Tables are wrapped in a horizontal-scroll safety net, and at 390 px they stack as cards with a label on each cell. Not checked in a browser: no headless browser is installed, so the layout and nav click were not tested.

• Moises accuracy, method and dataset: none published. The Moises help article is bot-blocked; snippet only.
• rekordbox: AlphaTheta help article bot-blocked; full Instruction Manual not opened.
• Foote 2000 primary not opened (blocked on CiteSeerX, IEEE and Semantic Scholar).
• Meredith et al. publisher page bot-walled; author draft read.
• Goto ICASSP 2003 version not fetched (2006 journal read).
• Muller and Kurth lag-matrix primary not fetched.
• mir_eval ISMIR 2014 paper not fetched.
• Serato support pages bot-blocked.
• Mixed In Key "up to eight cue points" and "bridges": snippet-only.
• Traktor, Ableton, LALAL.AI, AudioShake and Beatport DJ: checked on landing or feature pages only. AudioShake per-model pages not enumerated.
• Songstitch: not applicable.
• SongFormer model and dataset licence not verified.
• Whether rekordbox or Moises use deep learning is unverified.
• Every reliability figure and threshold is an ESTIMATE.
• No headless browser was available, so layout and nav click were not tested.
• Earlier unsourced research notes (e.g. HMM family) are not relied on.