Franchise Record Pool: AI Track Library and Shazam for DJs (2026 Build Guide)

Why Fora Soft wrote this playbook

Fora Soft has been shipping real-time audio and video products since 2005 — 625+ products delivered, 21 years of specialisation, and a 100% success rate on the projects we scope. Franchise Record Pool is one of the audio-first builds we are most proud of, precisely because almost every sub-system in it is the kind of thing a buyer is told “you can’t build that without a giant team.”

We shipped the full FRP product family — web console, Electron desktop app, native-feeling iOS and Android clients, audio-fingerprint recognition engine, LLM-driven voice assistant, and Serato sync — against a live catalog of 720,000 licensed tracks from Sony, Universal and Virgin. This article is the playbook we wish every music-tech founder had before they wrote their first RFP. Read it as a working estimate of what it takes to ship a modern DJ platform, not as marketing copy.

If you are weighing “build vs buy” for your own music library, skip straight to the DJ pool landscape and the cost model. If you are scoping a build, the reference architecture and pitfalls are where the real money is saved.

The FRP brief in one paragraph

Franchise Record Pool is a subscription platform for professional DJs. It ships three things in one login: a 720,000-track licensed catalog with BPM, key, remixes and source metadata on every row; a “Shazam for DJs” recognition engine that tells you what another DJ just played in their set and adds it to your crate; and an AI voice assistant that builds thematic playlists from a sentence. On top of those three capabilities sit a web dashboard, an Electron desktop app, React Native iOS/Android clients, Serato sync, and a WebRTC layer for DJ-to-fan audio.

FRP is not a Spotify clone. It is a working tool for people whose job is a four-hour set — which changes every single product decision, from how fast the waveform loads to how the search ranks Clean vs Dirty versions.

What pro DJs actually need from a track pool

Before we built FRP we shadowed working DJs at clubs, weddings, radio residencies and corporate events. The brief that came out of that research is the same one that should drive any DJ-pool product — and it is narrower than most founders expect.

1. Clean vs Dirty, fast. A working DJ needs to flip between the explicit and radio-edit versions of the same track in one tap. Search that buries “Clean” behind three filters loses users within a week.

2. BPM and key on every row. Harmonic mixing runs on the Camelot wheel (12 keys × major/minor = 24 slots). If key metadata is missing or wrong on more than 2% of the catalog, DJs notice in the first gig and switch providers.

3. Remixes in the same pane as the original. Edits, redrums, intro/outro versions and acapellas should be one expand-tap away from the source track, with remixer credit, BPM delta and length clearly shown.

4. “What did they play?” recognition. DJs watch each other. They record a snippet on their phone, open your app, and expect the ID in under a second — and then expect to add it to their crate with one tap.

5. Sync with their DJ software. If the library doesn’t reach Serato, rekordbox or Traktor, the platform is a read-only brochure. This is the feature that separates DJ pools from every other music product.

6. Offline reliability in venues. WiFi in clubs is terrible. Desktop and mobile clients must cache download queues, resume on reconnect and never fail silently on a broken transfer.

Inside the FRP platform — features that matter

FRP ships a dense feature set. The ones below are what we’d fight to keep in a slimmer MVP if budget was half.

720,000-track licensed catalog with full metadata

Every track in FRP is licensed from major labels (Sony Music, Universal, Virgin Records and a list of indie distributors). Each row exposes key, BPM, genre, sub-genre, release date, remix/edit family, and a short preview waveform. No other DJ-pool in our research surfaces all of that on a single search hit.

Audio recognition (“Shazam for DJs”)

Upload or record 5–10 seconds of audio and FRP returns the matching track with a confidence score. It also returns the closest remixes in the FRP catalog — which is the feature that flips recognition from “fun demo” to “adds tracks to my crate”.

AI voice playlist builder

A single microphone button opens a conversation. “Make a playlist with Italian pop from the 90s, around 140 BPM, no explicit.” The assistant confirms, generates the playlist, and reads the title and first five tracks back out loud.

Serato-native library sync

Tracks downloaded from FRP appear in Serato with the FRP metadata intact — no re-tagging, no re-importing, no manual folder management. This is the single feature pros check before subscribing.

Web + Electron desktop + React Native mobile

One codebase discipline, three surfaces. The Electron desktop app is where the heavy library management happens; the mobile app is what they open in the booth or on the street when they want to Shazam a track; the web app is the billing and admin layer.

Fan communication channel (mobile only)

On the mobile app, DJs can broadcast short audio messages and previews to followers over a WebRTC-backed channel. It’s the feature that keeps the app on the home screen between gigs.

The audio recognition engine — how “Shazam for DJs” works

Modern audio recognition uses a constellation algorithm: take a short snippet, compute its spectrogram, extract peak time-frequency points, hash pairs of peaks, and match those hashes against a pre-indexed database of hashes computed for every track in the catalog. Avery Wang published the canonical description at ISMIR 2003; every Shazam-style engine since builds on it.

The engine survives ambient noise because it discards amplitude and only cares about the pattern of peaks — the peaks that remain after the crowd, the drinks and the bad PA are still the peaks the original track has. A 5-second clip is enough against a multi-million track database.

Build, license or hybrid — the three realistic paths

1. Roll your own. Dejavu (open-source Python), audfprint (Dan Ellis, Columbia), or a Chromaprint/AcoustID pipeline. Free at license, but you eat the fingerprint computation cost (GPU hours) and the hosting cost of the hash index. Fine for catalogs under ~500k tracks with in-house ML.

2. Commercial API. ACRCloud, AudibleMagic or Gracenote. Pay-per-recognition or flat-rate enterprise. Faster to ship; cost escalates linearly with usage; you depend on their uptime.

3. Hybrid. Use an open-source fingerprinter against your catalog, fall back to a commercial API for tracks outside your catalog. This is what FRP does — it is materially cheaper at scale and keeps recognition latency bounded.

AI voice assistant for thematic playlists

The FRP voice assistant is deliberately narrow. It does one thing well: turn a spoken brief into a catalog query and then a playlist. The pipeline has four moving parts.

1. Whisper transcribes the speech. OpenAI Whisper at $0.006/minute, with an in-browser 16 kHz capture. Language is auto-detected; DJs tend to speak four or five languages across our user base, and Whisper handles code-switching well.

2. GPT-4o extracts the filter. A system prompt tells the model to emit a strict JSON object: genre array, BPM range, key set, year range, explicit flag, mood, language. Only the JSON goes to the search service — we never let the LLM write SQL directly.

3. The catalog search runs deterministically. The JSON filter hits our own metadata index (MongoDB + a denormalised search projection). The LLM never sees the catalog; the catalog never sees the LLM.

4. Amazon Polly reads the result back. A short confirmation (“Built a 23-track Italian pop set averaging 138 BPM”) plays in natural voice. Polly Neural runs at $16 per million characters — a rounding error per session.

This architecture keeps hallucinations impossible: the model cannot invent a track, because it never touches the library. We detail the same pattern in our AI call assistants guide and the synthetic voice library comparison.

// System prompt used by FRP (abbreviated)
You are a DJ-assistant router. Return ONLY a JSON object:
{
  "genre": string[],
  "subgenre": string[],
  "bpm_min": number, "bpm_max": number,
  "key_set": string[],              // Camelot notation
  "year_min": number, "year_max": number,
  "explicit_ok": boolean,
  "language": string[],
  "mood": string[]
}
No prose. No track names. No commentary.
If the user is ambiguous, default the bpm range to +/-3 around
the implied style (e.g. "house" -> 120..128).

BPM, key and metadata enrichment

Label metadata is inconsistent, incomplete and often wrong. At FRP scale you must re-analyse audio yourself. We use Essentia (the MTG Barcelona library) for BPM, key and mood detection; it is free, open-source, and parity-tested against Mixed In Key to roughly 99% agreement on the standard MIREX test sets.

Essentia extracts 200+ audio descriptors per track — we store about 15 of them (BPM, confidence, Camelot key, energy, danceability, loudness, spectral complexity, and a short mood tag set). Analysis runs once on ingest on cheap CPU workers; a 4-minute track takes ~12 seconds on a modest VM. For a 720k-track catalog that is roughly 2,400 worker-hours, amortised over years.

Serato, rekordbox and Traktor integration

None of the three major DJ software vendors publishes an official SDK. Integration is done by writing into the formats they read:

1. Serato writes crates as binary .crate files under ~/Music/_Serato_/Subcrates. Cue points and beatgrid markers live in ID3 GEOB frames inside the audio files themselves. The FRP desktop app writes both, atomically, when a track downloads.

2. rekordbox (Pioneer) uses an XML library file (rekordbox.xml) plus a SQLite database in newer versions. The XML path is still the reliable one for third-party writers.

3. Traktor (Native Instruments) uses a collection XML (collection.nml) that third-party tools such as Lexicon and DJ Conversion Utility already parse reliably.

A serious DJ pool ships Serato sync first, rekordbox second, Traktor third. That is the order of pro-DJ market share in 2026.

Reference architecture (web, desktop, mobile)

FRP is built on a clear four-layer architecture that we recommend for any licensed-catalog DJ product. Adapt the boundaries, not the shape.

WebRTC carries DJ-to-fan audio and low-latency preview because the alternatives are too slow. WebRTC holds glass-to-glass around 200–500 ms. RTMP sits around 3–5 seconds. Standard HLS lands at 10–30 seconds. For a DJ cueing into a track, only WebRTC reads as “instant”. We unpack that trade-off further in our Agora.io alternative guide.

The DJ pool landscape — FRP vs BPM Supreme vs DJcity vs Beatport

If you are evaluating a custom build instead of a licensed subscription, you should know what the incumbents offer. The matrix below is our working snapshot as of April 2026 — verify with the vendor before publishing pricing internally.

The two cells that matter most for FRP’s positioning are “in-app recognition” and “AI voice search”. Both are empty for every incumbent — which is exactly why a custom build is defensible here.

Licensing 720,000 tracks — the legal layer

Engineering is the easy half of a DJ pool. The hard half is the catalog agreements. Every track needs two licenses: the master (from the label — Sony, Universal, Warner, Virgin, BMG, plus indie distributors) and the composition (from publishers via mechanical, or from a collecting society). DJ pools typically negotiate a flat per-month-per-user promo-use license from labels with reporting of downloads.

Two practical things to plan for: DMCA-style takedown windows (labels periodically remove individual tracks), and watermarking (some labels require promo-only DRM so tracks cannot be sold-on). Both need architectural support on day one — bolt-on later is an eight-week emergency.

Storage, CDN and catalog scale

For a 720k-track catalog at FLAC masters plus MP3-320 and MP3-128 transcodes you are planning for roughly 20–28 TB of object storage. That is not a large number in 2026; the cost is in egress, not at-rest.

A multi-CDN posture (Cloudflare + a regional fallback, or AWS CloudFront + Fastly) is how you keep download speeds stable across regions. Spotify publicly reported a ~35% egress reduction after they moved to Opus + multi-CDN — similar arithmetic applies at any serious catalog scale. Pre-signed URLs with short TTLs plus byte-range resume handles the “club WiFi cut out” case without custom client code.

For fingerprint storage, the indexed hashes themselves are small (~1–2 KB per track); a 1M-track fingerprint index fits comfortably on a single large-RAM machine. This is the part of the system where over-engineering happens most often.

The build stack we chose (and why)

The exact stack behind FRP — and the reason each piece is there rather than a plausible alternative.

• React + TypeScript for all client UI. One component library, three surfaces. Chosen over Svelte/Vue because hiring depth matters when you have three clients in parallel.
• Electron for the desktop app. Serato sync, local cache and offline download queue need file-system access a browser cannot give you.
• React Native for iOS and Android. We reuse ~70% of the React component logic from web; native modules handle audio capture and Serato-equivalent mobile exports.
• Node.js + Express for the API edge. Fast to hire for, good fit for the mostly-CRUD + search workload.
• Python workers for ML and audio analysis. Essentia, Whisper client, fingerprint index lives here.
• MongoDB for metadata (schema drifts constantly as labels add fields). MySQL for transactional data (subscriptions, entitlements, billing).
• WebRTC for DJ-to-fan audio and preview. Under 500 ms and no extra plugin.
• OpenAI Whisper + GPT-4o + Amazon Polly for the voice assistant. We covered the selection logic in 7 best AI tools to elevate audio apps.

Cost model for a similar platform

Rough 2026 ranges for an FRP-class product — excluding catalog licensing and label-reporting ops. These are Fora Soft Agent-Engineered estimates, which is faster and tighter than the classical outsourced benchmarks; check with your vendor rather than extrapolating.

Ongoing runtime on top of development: expect roughly 2–4% of subscription revenue going to AI APIs (Whisper at $0.006/min, GPT-4o at its current tier, Polly at $16 per million characters), plus CDN egress that scales with downloads. For reference on the AI-API side we wrote a full piece: 6 best synthetic voice libraries for app development.

Pitfalls we solved so you don’t have to

1. Treating recognition as a ML project, not an indexing project. Teams burn months training fancier fingerprinters. The win is almost always in the index — cardinality, hash distribution, and how fast you can shard the lookup. Start with a well-understood hash scheme and measure.

2. Letting the LLM talk to the database. The moment the model writes your search query, it hallucinates tracks. Route through strict JSON and deterministic search; the LLM is a parser, not a retriever.

3. Ignoring Serato on day one. Post-launch Serato integration is a six-to-eight-week emergency with zero user visibility to show for it. Write into the Serato folder from release one.

4. Trusting label metadata. BPM is missing on roughly 30% of label feeds; key on 60%; mood on nearly all. Re-analyse on ingest.

5. One-stop DRM “later”. If any of your label contracts require promo-only watermarking, the download pipeline must produce per-user fingerprints on every download. Retrofitting this into a running catalog is the single most expensive mistake we see.

KPIs that matter for a DJ pool

Quality KPIs. Recognition accuracy (target ≥ 98% top-1 on 5s clips against your own catalog), BPM accuracy vs ground truth (≥ 99%), key accuracy (≥ 95%), voice-command intent precision (≥ 92% on a held-out test set). These numbers matter because DJs test you on day one; anything lower reads as “broken”.

Business KPIs. Monthly active DJ ratio (D28 ≥ 55% of paid users), downloads per DJ per week (≥ 25 for a healthy pool), churn (< 4% monthly), free-to-paid conversion (≥ 8% of trial users). Below those thresholds your unit economics are almost always upside-down after label payouts.

Reliability KPIs. Catalog-search p95 ≤ 250 ms, recognition p95 ≤ 1.2 s, download resume rate ≥ 99.5%, desktop-app crash-free sessions ≥ 99.8%. Club-WiFi tolerates nothing else.

When NOT to build this from scratch

A custom DJ pool only pays back when you have a real edge on catalog, community or software integration. If you don’t, you will pay to rebuild something that already works better.

Don’t build when: your catalog will stay under 50k tracks; you have no label or distributor relationship; your plan is to onboard fewer than 2,000 paying DJs in year one; or your differentiator is “nicer UI than BPM Supreme”. Reskin a licensed product instead.

Do build when: you are a label or distributor with catalog rights the incumbents can’t touch; you have a regional licensing advantage (Latin America, Korea, MENA markets are all underserved); or your product is fundamentally a DJ workflow tool with a library, not a library with a player.

FAQ

What to read next

Ready to build your own AI-powered audio platform?

Franchise Record Pool is a proof that a DJ-pool product in 2026 is three engineering disciplines stitched together: a licensed catalog, a fingerprint-driven recognition service, and a tightly-scoped LLM wrapped around deterministic search. None of those are exotic individually; the win is in shipping them as one product that pro DJs actually use at gigs.

If your product is audio-first — a DJ pool, a music-tech SaaS, a karaoke platform, a broadcast tool, a radio back-end — Fora Soft is the team that has shipped it before and can tell you honestly where your scope is tight and where it is going to hurt.

Start with a 30-minute call. We’ll come back with either a line-item scope or the honest reason this should be a white-label build instead. Both answers save you money.