Building TagMyBeat: An AI Producer Tag Generator and a Browser-Based BPM & Key Finder That Never Uploads Your Audio

If you produce music, you know the drill: you finish a beat, export it, and then need a vocal tag to brand it. You also need to know the BPM and key of every sample in your library so everything fits together. These are two different problems, but they share the same DNA: audio processing, fast turnaround, and privacy for unreleased material.

I built TagMyBeat to solve both, and in this post I want to walk through how they work under the hood.

What Is TagMyBeat?

TagMyBeat is two things:

1. A Producer Tag Generator — type text, pick a voice and an effect preset, and get a professional vocal tag (think "DJ Khaled!" but yours).
2. A Free BPM and Key Finder — drop in an MP3, WAV, or FLAC, and get tempo, musical key, and Camelot code back, entirely in your browser. No upload. No server.

The tag generator is the main product (3 free generations per day, no login). The BPM/Key Finder is a free engineering-as-marketing tool that brings producers into the ecosystem. Both are open about how they work, so let's get into the tech.

Tech Stack at a Glance

Part 1: How the Producer Tag Generator Works

The generation pipeline is a classic producer-consumer pattern:

User types text → quota check → task queue (asyncio.Queue) → worker pool (8 workers)
→ TTS generates speech → FFmpeg applies audio effects → file saved → frontend polls status

Audio Effects with FFmpeg

After the voice is generated, FFmpeg steps in. We have 5 built-in effect presets:

• Clean — light compression and normalization
• Hype — pitch shift up, short reverb, stereo widening
• Chill — pitch shift down, large reverb, warm EQ
• Cinematic — deep reverb, delay, dramatic EQ
• Retro — bitcrushing, tape saturation, vinyl noise

Each preset is a chain of FFmpeg audio filters (atempo, aecho, equalizer, etc.) composed programmatically. Advanced mode lets you dial in 6 custom parameters: stutter speed, reverb size, reverb wet, delay time, delay feedback, and pitch shift.

Part 2: Deep Dive — How the BPM and Key Finder Works (Entirely Client-Side)

This is the part I'm most excited about. The BPM/Key Finder runs 100% in the browser using WebAssembly and Web Workers. Your audio files never leave your device.

The Core Engine: essentia.js

Under the hood, we use essentia.js, a WebAssembly port of Essentia, an open-source C++ library for audio analysis developed by the Music Technology Group at Universitat Pompeu Fabra. Essentia has been battle-tested in academic research and production systems (Spotify uses it internally).

Loading essentia.js happens lazily — the ~2MB WASM binary is fetched from our CDN only when you first open the BPM/Key Finder. We use a Web Worker to keep the main thread responsive during initialization and analysis.

Step 1: Smart Windowing

Not all parts of a track are equally useful for analysis. Intros often have no drums, outros fade out, and breakdowns can confuse tempo detection. So we don't feed the entire track to the analyzer.

Instead, we use a smart windowing strategy that varies by track length:

All windows avoid the first and last 10% of the track (the edge guard) to dodge intros and outros. This might seem like a small detail, but it dramatically improves accuracy on real-world tracks.

Step 2: BPM Detection with PercivalBpmEstimator

For tempo detection, we use essentia's PercivalBpmEstimator, which is based on the Percival algorithm. Here's how it works at a high level:

1. Onset Detection — The algorithm detects note and drum onsets across multiple frequency bands using spectral flux.
2. Inter-Onset Interval (IOI) Histogram — It computes a histogram of time differences between consecutive onsets. Regular rhythms produce peaks at the tempo period and its multiples.
3. Perceptual Weighting — The algorithm applies a perceptually-motivated weighting function that favors tempos in the 80–200 BPM range (where most music lives) and penalizes half-time and double-time candidates.
4. BPM Candidate Scoring — Multiple tempo hypotheses are scored against the IOI histogram, with penalties for ambiguous cases.

But here is the key insight: for longer tracks, we run this algorithm on three different 20-second windows at different positions and then aggregate the results. This is critical because a single window might hit a breakdown or a double-time section.

Step 3: Key Detection with KeyExtractor

Key detection uses essentia's KeyExtractor, which works as follows:

1. Chroma Feature Extraction — The audio is converted into a chromagram: a 12-bin representation of how much energy is present at each pitch class (C, C#, D, ..., B), collapsed across all octaves. This is computed every 4096 samples with a 4096-sample hop size.
2. Key Profile Correlation — The averaged chroma vector is correlated against 24 key profiles (12 major + 12 minor keys using the Krumhansl-Kessler tonal hierarchy). Each profile represents the expected chroma distribution for a given key.
3. Strength and Confidence — The algorithm returns not just the best-matching key and scale, but also a strength score (0–1) indicating how strongly the chroma matches the profile. Low strength often means the track modulates or has an ambiguous tonal center.

For tracks longer than 90 seconds, we sample two 40-second windows and use a majority-voting aggregation: if both windows agree on the key, we return it with the averaged strength. If they disagree, we pick the one with higher strength. This handles tracks where the verse and chorus are in different keys.

Step 4: Aggregation and Normalization

Raw BPM estimates need cleanup. Here is our aggregation pipeline:

Raw BPM estimates from each window
→ Normalize into 80-200 BPM range (doubling/halving)
→ Cluster analysis: group estimates within ±2 BPM of each other
→ If largest cluster has ≥ 2 estimates: return median of that cluster
→ Otherwise: return median of all estimates

The cluster approach is important. Imagine a trap beat at 140 BPM. Window 1 might detect 140, Window 2 detects 70 (half-time feel during a sparse section), and Window 3 detects 140. Without clustering, a simple average gives 116.7 — useless. With clustering, the 140 group wins, and we get the correct answer.

The normalization step (multiply by 2 if below 80, divide by 2 if above 200) uses the fact that most music sits in 80–200 BPM. A 65 BPM estimate on a drum and bass track is almost certainly half of 130 (or, more likely, half of ~174).

Step 5: Camelot Notation

For DJs, we convert the detected key to Camelot notation, which is the standard harmonic mixing system used in Pioneer DJ gear, rekordbox, and Mixed In Key:

The rule of thumb: adjacent Camelot numbers mix harmonically (8A → 9A, 8A → 7A), and same-number cross-scale transitions work (8A → 8B).

Why No Server Upload?

Three reasons:

1. Privacy — producers work with unreleased material. They should not have to trust a server with their beats.
2. Instant UX — no upload progress bar, no network errors, no timeouts. Files are decoded locally in milliseconds.
3. Zero server cost — audio analysis is CPU-intensive. Offloading it to the client means we can offer this as a free tool indefinitely.

The trade-off is that we cannot analyze YouTube or Spotify links (the browser would need to download the audio first, which raises copyright issues). That feature is on the roadmap, but for now the tool is file-based.

What I Learned Building This

essentia.js is incredible but heavy. The WASM binary is ~2MB, and initialization takes 1-3 seconds on a cold load. The lazy-loading pattern (only fetch when the BPM/Key Finder page opens) was essential to keep the main tag generator fast.

Smart windowing matters more than the algorithm. Switching from full-track analysis to multi-window analysis with edge guards improved BPM accuracy by ~15-20% on real-world test tracks. The algos are mature; the preprocessing is where you win.

Web Workers are underrated for audio. Running essentia on the main thread caused 200-500ms UI freezes per file. Moving to a Worker made batch analysis of 20+ files feel smooth. The message-passing overhead is negligible compared to the analysis time.

Browser fingerprinting is a pragmatic middle ground. No one wants to create an account for a free tool. Fingerprinting gives us abuse prevention and data isolation without signup friction. The trade-off is that clearing browser data resets your quota, but for a free tier that is acceptable.

Try It Yourself

• BPM and Key Finder — free, no signup, works offline after the WASM loads
• Producer Tag Generator — 3 free generations per day

The BPM/Key Finder source is visible in the browser (it is all client-side JS). The backend for the tag generator is in Python/FastAPI. If you are curious about any specific part, drop a comment — I am happy to dive deeper into the FFmpeg effects chains, the Edge TTS integration, or the essentia.js setup.

TagMyBeat is built with Next.js 16, FastAPI, essentia.js, Edge TTS, FFmpeg, and Tailwind CSS. Deployed on Cloudflare + a VPS. No user accounts, no audio uploads for the BPM/Key Finder.