Music technologyRepertoire archaeology2026

Music Atlas

A product-first explorer for a sanitized metadata and model-analysis export.

Loading the schema-3 public index. Search will be ready shortly.

This explorer runs in the browser against a static sanitized schema-3 export. No visitor-triggered provider APIs are called.

01 / THE IDEA

The library remembers files. I wanted it to remember relationships.

DJ software is good at storing records and weak at helping a person recover the connections between them. I wanted to choose one track I already knew, then ask what else in the archive could sit near it by pace, harmonic position, credit, release lineage, or scene context. The result is a retrieval tool for forgotten repertoire.

Search across artist, title, release metadata, source BPM and keys, and sectional tonal keys. Select a record, inspect its available analysis, then follow exactly ten explainable neighbors as new seeds. Every result says why it appeared. There is no hidden taste model, audio similarity claim, or visitor-triggered provider API.

02 / THE FRICTION

The software disagrees about pitch.

25.0%

Public tonal maps with one predicted key across every analyzed section.

72.7%

Public tonal maps that triggered the pipeline second-opinion rule.

These are pipeline findings, not human-labeled ground truth. The explorer keeps source lanes separate and makes disagreement visible instead of flattening it into a consensus.

03 / PUBLIC BOUNDARY

Real corpus. Deliberately narrow export.

The public instrument ships 47,445 records from a sanitized metadata and model-analysis export of 51,302 archive rows. That is a public export, not a claim that every archive row is public.

The export contains artist, title, album, genre, year, label, source-specific BPM and key, sectional tonal summaries, and public detail where available. No audio, paths, filenames, play history, crates, comments, private IDs, or visitor-triggered provider APIs are shipped. Sectional and arrangement labels are machine-generated provisional hypotheses, not human ground truth.

04 / MODEL FIELD NOTES

Testing the first layer of a music analysis protocol.

The archive is the controlled testbed. I have now tested representation stability, tempo agreement against DJ metadata, interpretable classifier heads, and stem-based structure analysis on the same local hardware. Some methods earned a place. Others earned a narrower job.

100private archive tracks
200non-overlapping excerpts
20full tracks in the stem trial
0completed-run failures

Music Atlas is a long-term attempt to develop a repeatable AI-assisted protocol for analyzing electronic music. The goal is to help people understand what tracks are doing and use that evidence while writing the music they want. The archive gives me a private, known corpus for testing each part of that protocol.

Retrieval is the first test harness and remains a practical part of the eventual system. A useful neighboring record gives a DJ or musician a concrete reference for groove, texture, arrangement, energy, or production choices. Some retrieval evidence is deterministic and attributable: tempo, key, and the metadata graph of artists, labels, versions, and releases. Some is learned: embedding models that place tracks near each other by how they sound. Before asking those models to support deeper analysis or composition, I needed to know whether their output remained stable on this material.

The first evidence was not good enough. This section records the correction, the stronger tests that followed, and the parts that still need human judgment.

The protocol now has a sectional map and a human reference plan.

This milestone covers the full archive rather than the 100-track benchmark sample used in the tests below. The private archive contains 51,302 tracks, and no source audio leaves the local workstation. The full sectional scan produced 51,178 complete tonal maps across 519,685 analyzed sections, with zero unresolved failures and 4,046,195 verification checks.

Only 25.0 percent of the 51,178 mapped tracks held one predicted key across every analyzed section. Separately, 72.7 percent triggered the pipeline second-opinion rule. The result does not show that records themselves changed tonal center. It shows that one whole-track label fails to represent the pipeline's sectional predictions for most tracks.

I compared MusicalKeyCNN and Madmom on two separate cohorts. The selected unstable cohort contained 10,000 tracks with 5,139 exact label agreements, or 51.39 percent. The stable control contained 2,000 tracks with no overlap, 1,492 exact agreements, or 74.6 percent, and zero failures.

That split supports confidence-based routing: stable cases can take a faster path while unstable cases receive closer review. Agreement is not human accuracy. Missing human ground truth is the limit, and two models agreeing does not supply it.

The arrangement pilot covered 100 tracks. All 100 were valid with zero errors. It produced 985 proposed segments, used 305 DJ-grid source records, and made 243 grid comparisons. DJ evidence came from Rekordbox, Serato, and Traktor where available, compared with Madmom-derived timing.

Arrangement boundaries and role names remain machine hypotheses. Human ground truth is still missing. Madmom outputs are research-only under CC BY-NC-SA 4.0 pending licensing review. An archive-wide Madmom key rerun is not recommended.

The next protocol runs three deep reference tracks, then ten, then twenty. Three establishes the method. Ten tests repeatability. Twenty can form a small reference and evaluation corpus. Twenty cannot train a capable generative model from scratch.

Human maps will be made in Ableton before consulting machine maps to reduce anchoring. They will capture bars and timestamps, section function, layers, rhythm, harmony, energy, transition devices, production techniques, uncertainty, and a technique-level recreation recipe.

The long-term direction is an analysis companion built from measured evidence.A user drops in a track and receives evidence-backed structure, sectional key, rhythmic architecture, energy contour, layer schedule, transition devices, probable production techniques, uncertainty, and technique-level recreation guidance. Retrieval remains useful as a source of concrete reference tracks. This product direction is not shipped.

Folder labels could not answer the question.

The first experiment took one thirty-second excerpt from each of 100 tracks and ranked fifteen embedding models by whether a track's five nearest neighbors came from the same broad source category. Those categories came from folder organization, not from listening judgments.

Random precision at five was 0.091. The highest observed score was 0.304. Every model had a negative silhouette score, which means those categories did not form separated clusters in any embedding space.

That test can describe rough folder alignment. It cannot decide whether a retrieved record is musically useful, and the original page treated the ranking as if it could. I replaced that conclusion instead of trying to rescue it.

The labels were weak.The next test used the one identity label I could verify without interpretation: two excerpts came from the same recording.

Can a model recognize the same track from a different section?

I made View A and View B from the same 100 private tracks. Each view contained a separate thirty-second excerpt. All 100 pairs were non-overlapping, the minimum start separation was 48.1 seconds, and the resulting 200 clips had unique hashes.

Every View A excerpt searched all 100 View B excerpts, placing its correct match among 99 tracks that were not the same recording. I repeated the search from B to A, producing 200 queries per embedding lane. All fifteen embedding lanes and TempoCNN completed both views with zero failures.

Swipe the table horizontally to see all columns.

Model laneTop-1Recall@5MRR
Discogs track0.9750.9900.982
Discogs release0.9600.9850.971
MusicFM0.9500.9700.961
Discogs multi-trained backbone0.9300.9900.955
MAEST0.9400.9650.953
Discogs ONNX0.9200.9750.946
Discogs artist0.9000.9600.928
MERT 95M0.8900.9450.914
MuQ0.8700.9600.912
OMAR-RQ base0.8650.9650.905
Discogs label0.8350.9550.887
MusiCNN0.8050.9150.855
MERT 330M0.8150.9000.855
CLAP music0.4850.6900.576
OMAR-RQ multifeature0.1200.3200.235
Random baseline0.0100.0500.052

The random baselines are 0.010 for top-1, 0.050 for recall at five, and 0.052 for mean reciprocal rank. Discogs-track posted the highest point estimates: 0.975 top-1, with a 95 percent bootstrap confidence interval from 0.945 to 0.995; 0.990 recall at five, with an interval from 0.975 to 1.000; and 0.982 MRR.

The intervals do not support a clean winner. Discogs-track and Discogs-multi tie on recall at five, and the confidence interval on their difference runs from -0.015 to 0.015. The MRR difference between Discogs-track and Discogs-release has an interval from -0.00125 to 0.02538. The interval against MusicFM runs from -0.00656 to 0.05526. Both include zero.

The supported result is a strong cluster of stable representations: Discogs-track, Discogs-release, MusicFM, Discogs-multi, MAEST, and Discogs-ONNX. These models usually place two different sections of the same recording together. The test does not show which one will return better neighboring records for a DJ.

Track stability is a gate, not a taste judgment.

A model can pass this test perfectly and still surface other records that are obvious, wrong, or useless behind the deck. The paired-section test measures whether its representation survives a change in the part of the recording it hears. That is valuable because a model that loses track identity across sections is a poor foundation for retrieval. It remains only one requirement.

Two low scores need context. CLAP reached 0.485 top-1, but this experiment never tested its intended text-to-audio job. A written query such as “dark broken techno with soft pads” needs a shared text and audio space, and that needs a separate evaluation.

OMAR-RQ multifeature reached 0.120 top-1 while OMAR-RQ base reached 0.865. The multifeature lane used a simple pooling and readout step I wrote. That readout may be the failure, so I am not treating the score as a verdict on the frame-level representation.

MERT 330M scored below MERT 95M on top-1, recall at five, and MRR. The larger checkpoint also took roughly twice as long per clip in the first pass. More parameters did not help this task.

TempoCNN earned a place in the next build.

TempoCNN produced a median raw disagreement of 0 BPM between the two excerpts. Ninety-one percent of tracks landed within 3 BPM after allowing for half-time and double-time readings. Raw Pearson correlation was 0.591; octave-aligned correlation was 0.900.

I then checked both excerpts against the DJ metadata rather than treating cross-section agreement as accuracy. Eighty-eight tracks had at least two source BPMs that agreed within 3 BPM after octave alignment. Nine conflicting Serato and Rekordbox records were excluded instead of being forced into a ground truth value. Traktor covered only four tracks in this sample.

91 percentView A and B within three BPM
97.7 percentView A within three BPM of DJ consensus
94.3 percentView B within three BPM of DJ consensus

The median TempoCNN disagreement against that coherent reference was 0.202 BPM for View A and 0.197 BPM for View B. The dependency-light local DSP estimate reached the same 3 BPM gate on 55.7 and 54.5 percent of tracks. TempoCNN is the primary tempo candidate. The simpler DSP method remains useful as a diagnostic fallback.

Key now has a dedicated agreement evaluation. The full sectional scan produced 51,178 complete tonal maps across 519,685 sections with zero unresolved failures. MusicalKeyCNN and Madmom agreed on 51.39 percent of exact labels in a 10,000-track unstable cohort and 74.6 percent in a separate 2,000-track stable control with no overlap. That agreement supports routing by confidence. It does not measure accuracy against human ground truth, which is still missing.

Stable scores still need human meaning.

Seven official Essentia heads ran across both excerpts from all 100 tracks: approachability, engagement, danceability, instrumentation, mood and theme, voice versus instrumental, and DEAM arousal and valence. All 200 excerpts completed in 349.4 seconds with zero failures. The sample has no human labels for any of those concepts. Every result below measures cross-section stability or an internal consistency check. Human accuracy is untested.

Approachability was the most stable scalar, with a cross-view correlation of 0.950. Danceability reached 0.934, but it labeled 80 of 100 View A excerpts and 79 of 100 View B excerpts as danceable, with medians near 0.99. On a DJ archive that head is too saturated for ranking. It may still work as a coarse gate.

Voice probability reached 0.827 cross-view correlation and 82 percent top-class agreement. Its correlation with Demucs vocal energy share was only 0.443. DEAM valence reached 0.848 and arousal 0.832 across views. Engagement reached 0.829. Those scores are repeatable on different sections of the same track. Their relationship to a listener's judgment remains untested.

Instrument tags had a median per-label correlation of 0.860 and 82 percent top-label agreement. The bass classifier correlated 0.345 with Demucs bass energy share. The drums classifier correlated negative 0.209 with drum energy. Mood and theme tags reached 0.830 median per-label correlation and 75 percent top-label agreement, while the official sidecar reports a test PR-AUC of 0.14. Classifier labels and measured stem energy stay separate. Raw mood tags stay out of the product until a person reviews them.

Candidate axes

Approachability, voice, DEAM arousal and valence, and selected instrument probabilities move forward for human calibration.

Coarse gate

Danceability is stable but nearly saturated on this archive. It can divide obvious cases, not rank them finely.

Hold

Engagement and raw mood or theme tags remain exploratory until human judgments give the scores a defensible meaning.

Demucs fits. Archive-wide separation does not.

Demucs ran in two forms. First, I separated all 200 thirty-second excerpts in memory and retained only derived measurements. Every excerpt completed in 221 seconds with zero failures, and no rendered stems remained. Drum, bass, other, and vocal energy shares reached cross-view correlations of 0.809, 0.741, 0.711, and 0.667. Mean and upper-percentile stem-share change reached 0.789 and 0.757. Threshold peak count reached only 0.308 and was dropped.

A sixteen-dimensional structural vector built from those measurements retrieved the other excerpt from the same track at 0.293 top-1, 0.500 recall at five, and 0.397 mean reciprocal rank across 198 valid queries. Random baselines were 0.010 top-1 and 0.051 recall at five. One nearly silent track was excluded by a fixed input-level rule. The structure vector carries repeatable same-track evidence, but it trails Discogs-track at 0.975 top-1 and CLAP at 0.485. It complements an embedding rather than replacing one.

The second trial asked whether stem activity could reveal full-track arrangement changes that a mixture-only analyzer missed. I ran Demucs 4.0.1 with the htdemucs model on twenty complete tracks, two from each benchmark bucket. All twenty finished on the RTX 2080 SUPER. The trial covered 120.5 minutes of music in 7.94 minutes of GPU time.

23.9 secondsmedian runtime per full track
6.55 GiBpeak total GPU use
9.50 GiBraw stems from twenty tracks

I measured one-second activity curves from each stem and compared their transition candidates with a mixture-only detector. A candidate counted as stable only when it survived two-, four-, and eight-second context windows. The mixture detector retained 56.8 percent of its candidates. The stem detector retained 48.3 percent.

The stem-minus-mixture difference was negative 8.4 percentage points, with a 95 percent bootstrap interval from negative 22.6 to positive 5.2 points. Only 39.7 percent of selected stem boundaries matched a mixture boundary within four seconds. Forty-six stem-only candidates survived all three context widths, a median of two per track.

Those extra candidates are real output, but they are not verified arrangement boundaries. This corpus has no human boundary annotations. Recombined stems tracked the source closely, with a median waveform correlation of 0.9992, but that verifies timing and technical coherence rather than perceptually clean isolation.

Use Demucs after selection.For a track chosen for deeper review, derive compact stem-activity measurements and transition candidates, verify the result, then delete the WAV stems.

At the measured speed, processing 51,302 five-minute tracks would take about 12.3 sequential GPU days. Keeping the tested float32 stems would require roughly 19.8 TiB before backups. Runtime is manageable. Storage and weak evidence of added accuracy are not.

The 9.50 GiB trial output also exposed a separate retention failure. The 910 GiB backup volume was 98 percent full with 18 GiB free while the weekly recovery set was still staging. I left the active job alone. It later verified its restore-critical contents, replaced the current set, and exited cleanly. Available space recovered to 187 GiB, or 79 percent used. Eight dated legacy trees remain, and the automatic retention correction is not installed. The immediate capacity risk is contained. The retention work is still open.

Eight gigabytes was enough when the models took turns.

Everything ran locally on an NVIDIA RTX 2080 SUPER with 8 GB of VRAM. Sequential execution avoided memory conflicts, and every candidate fit. The embedding bakeoff peaked at about 4.46 GiB while OMAR-RQ loaded. Demucs reached 6.55 GiB during full-track separation.

The original sixteen-lane pass over View A took 23 minutes 6 seconds. View B took 23 minutes 13 seconds from the first model start through TempoCNN completion. A fresh paired run therefore costs about 46 minutes on this machine.

Audio and embeddings stayed on the workstation, and the runners checked source hashes before inference. I also compared the CUDA ONNX and TensorFlow CPU Discogs paths on a smoke clip. Their minimum framewise cosine similarity was 0.99999988, and their maximum absolute difference was 0.00000165.

01

The NVIDIA kernel and userspace driver versions were mismatched at the start. One reboot aligned both at 595.84.

02

MERT required a Python 3.11, PyTorch 2.2, and Transformers 4.38 compatibility environment to load every checkpoint key correctly.

03

Essentia's TensorFlow wheel expected old CUDA 11 libraries. Its frozen graphs ran on CPU while the dynamic Discogs ONNX model used CUDA 12.

04

Demucs rejected the documented hybrid-model maximum when passed as 7.8 seconds. An integer seven-second segment ran correctly and completed the twenty-track trial.

Private research results do not grant production rights.

Permissive candidates

CLAP uses Apache 2.0. Demucs uses MIT. MusicFM lists MIT and Apache 2.0, although its upstream code and weight split still needs confirmation before shipping.

Noncommercial weights

MERT and MuQ use CC BY-NC 4.0. OMAR-RQ weights use CC BY-NC-SA 4.0, while its code uses AGPL 3.0.

License or replace

MTG's Essentia weights use CC BY-NC-SA 4.0. MTG offers proprietary licensing for commercial use.

Several Discogs representations sit inside the stable group. Using them in a commercial product would require an agreement with MTG or a replacement model. Their research value is one input to that licensing decision.

The next phase builds a human reference.

The paired-section test shows which models preserve the identity of a recording across different excerpts. The tempo cross-check shows that TempoCNN usually agrees with coherent DJ-tool metadata. The interpretable heads produce repeatable scores that still lack human meaning. The Demucs trials show that stem separation fits the workstation, produces stable continuous measurements, and adds structure candidates. None of those tests says whether a neighboring record is useful or whether a proposed arrangement boundary sounds right.

The next phase is human reference analysis in Ableton before the machine map is consulted. It runs three tracks, then ten, then twenty. The first three establish the method, ten tests repeatability, and twenty can form a small reference and evaluation corpus. An archive-wide Madmom key rerun is not recommended. The reference maps will give the key and arrangement hypotheses a human comparison point.

The current build has a stable representation group, a defensible tempo candidate, a sectional key map awaiting human comparison, several interpretable axes awaiting calibration, and a bounded role for stem separation. The wider protocol still needs trusted analysis of rhythm, harmony, timbre, arrangement, energy, and production choices, with the source and uncertainty left visible. I will keep the claims no larger than the tests.

The analysis stack.

These are the main open tools behind the tests. The models have separate licenses, documented above.