What was the motivation to start WhatsMyBitrate and make it open source?

It started, as these things usually do, with being annoyed.

A suspicious file

I was building my music library and kept running into files that felt... off. A "FLAC" that sounded oddly flat. A "320 kbps" MP3 that seemed thinner than it should. Anyone who's collected music from various sources over the years knows the feeling — files pass through so many hands, get converted and re-converted, that the label on the tin stops meaning much.

The frustrating part was that there was no quick way to check. The tools that existed were either desktop apps you had to install and learn, command-line utilities that assumed you already knew what you were looking for, or forum advice along the lines of "just open it in a spectrum analyzer and eyeball it." I wanted something dead simple: give it a file, get the truth.

There was a philosophical itch underneath the practical one, too. Audio has a long tradition of taking claims on faith — cables that cost more than amplifiers, formats that promise more than they deliver, "hi-res" badges applied to files nobody measured. The whole culture rewards believing the label. A tool that starts from "show me the data" felt like a small push in the other direction.

So I built it — as a script first

The core insight is simple enough: lossy encoders leave fingerprints. Chop the high frequencies off a file and no amount of re-encoding will put them back. So a tool that measures where the frequency content actually stops can tell you what a file really is — not what it claims to be.

The first version of WhatsMyBitrate wasn't a website at all. It was a Python script on my machine, built to do one job: point it at a file (or a whole folder of files) and get the truth back. I put it on GitHub partly for backup, partly because I figured someone else out there had the same annoying problem. The website came later — the realization that most people don't want to install Python and run a script just to check one file. They want to drop a file in a browser and get an answer in seconds. So the web version is really just the friendly front door to what the open-source project already did.

The spectrogram came along because it's the difference between being told something and seeing it. A fake lossless file shows its cutoff as a hard line across the top of the image. Once you've seen that line, you can't unsee it.

That last point ended up mattering more than any feature decision. The most common reaction to the tool isn't "thanks for the number" — it's "I didn't know you could see that." Numbers ask to be trusted; pictures ask to be checked. A verdict you can look at and verify with your own eyes is a different kind of answer than one you're asked to accept, and that difference is basically the whole argument for how this project is run.

Why open source from day one?

It was never really a question — the project lived on GitHub before the website existed. But there are a few reasons I'd never do it differently.

Trust. This is a tool that judges other people's claims about quality. It would be pretty hypocritical for the tool itself to be a black box saying "trust me." With the code public, anyone can verify exactly what's measured, how the verdict is reached, and what happens to their file. You don't have to believe the privacy policy — you can read the code and see that files get discarded.

Usefulness. The web version analyzes one file at a time. But plenty of people want to audit an entire library — thousands of files. The GitHub version does batch scans precisely because that's what it was built for from the start, and keeping it open means anyone can adapt it to their own workflow.

It's just better software. Bugs get found, edge cases get reported, ideas get suggested. Audio is full of weird formats and stranger encoders, and no single person tests against all of them. Opening the code turned a personal script into something much more robust.

There's a subtler benefit too: public code forces honest engineering. When anyone can read the implementation, there's no hiding a shortcut behind marketing copy. The thresholds the verdicts rest on are published on the about page, the reasoning is in the how-it-works writeup, and the code that applies them is on GitHub. If any of those three disagreed with the others, someone would eventually notice — which is a healthy kind of pressure to work under, and a big part of why the detection has gotten more careful over time rather than more confident.

And honestly? The audio community has given me a lot — free software, shared knowledge, endless forum threads answering obscure questions at 2am. Releasing this was a small way to give something back.

What open source means in practice

"Open source" gets used loosely, so here's what it concretely means for this project. The code is under the MIT license — the most permissive mainstream option — which means anyone can read it, run it, modify it, and build on it, including commercially, with no permission needed beyond keeping the copyright notice. There's no CLA, no contributor paperwork, no enterprise tier hiding the good features. What analyzes files on this website is the same analysis pipeline you can clone and run on your own machine tonight.

It also means the privacy story is verifiable rather than promised. Plenty of tools say "we don't keep your files," and you have to take their word for it. Here, the file-handling path is a few dozen lines anyone can audit: the upload is decoded, measured, discarded. People reasonably care about this — unreleased music, client work, and personal recordings pass through the analyzer, and "trust the code, not the promise" is the only privacy model that scales with how sensitive that material can be.

What the community has actually changed

Opening the code wasn't just altruism — it materially shaped the tool. A few examples of the kind of thing that only surfaces once strangers run your software against their own messy libraries:

Encoder edge cases. My early thresholds were calibrated on LAME-encoded MP3s, because that's what my library contained. It took reports about files encoded with Fraunhofer's encoder — which lowpasses differently at the same bitrate — to make the detection honest across encoder families. No single person's music collection contains every encoder ever shipped.

The HE-AAC problem. The discovery that low-bitrate streams synthesize their high frequencies — and therefore "pass" the naive cutoff test — came from analyzing broadcast rips and realizing the spectrum was lying. That became its own section of the AAC guide, and it's exactly the kind of finding that a closed tool would have no pressure to disclose.

Batch workflows. The most-requested feature by far was scanning entire libraries rather than single files. That demand is why the GitHub version treats batch analysis as a first-class job — something I'd never have prioritized for a personal script, since my own need was occasional suspicion, not bulk auditing.

The trade-offs, honestly stated

Open source isn't free of costs, and pretending otherwise would be exactly the kind of marketing this project exists to fight. The honest ledger: supporting a public issue tracker takes time that could go to features. Publishing the detection thresholds means someone determined to defeat them knows exactly where the lines are — though I'd argue a check that only works while secret wasn't a real check to begin with. And there's always the possibility of someone re-hosting the tool under a worse privacy model; the license permits it, and all I can do about it is make the original the obvious one to use.

On balance those costs are small next to the core benefit, which loops back to the opening problem: a tool that exists to verify other people's claims has to be verifiable itself. Closed code asking you to trust its verdicts about trust is a circle I didn't want to draw.

If you want to get involved

The project stays healthy in proportion to how many eyes it gets, and there are useful ways to contribute at every level of commitment:

Report odd files. Genuinely the most valuable contribution. If the analyzer's verdict looks wrong for a file you know the provenance of — a CD you ripped yourself, a purchase from a reputable store — that mismatch is a calibration bug waiting to be understood. Open an issue with what the tool said and what the file actually is; the debug log attached to every result exists precisely so these reports are actionable.

Test against your library. Run the batch version over a library full of weird formats — old WMA files, DSD conversions, game soundtracks, broadcast captures. Edge cases live in other people's collections, not mine.

Write or review code. The analysis pipeline is plain Python with no exotic dependencies, and issues tagged for newcomers stay deliberately unassigned. If DSP is new to you, the codebase is a friendly place to learn it — the whole thing is built on the idea that measuring audio shouldn't require a PhD or a proprietary license.

Spread the method, not just the tool. The deeper goal was never really the website — it's that more people learn to read a spectrogram and stop trusting labels. If this site teaches someone to catch fakes with any tool at all, it did its job.

Where it goes from here

The goal stays the same: a free, trustworthy way to know what your audio actually is. No accounts, no uploads kept, no paywall. The roadmap is driven mostly by whatever the community's libraries turn out to contain — better handling for the formats that show up in issue reports, more reference material in the reading room, and continued calibration of the detection as new encoders and new scams appear.

If that sounds useful, go analyze something — and if you find a fake in your library, well, now you know. And if you want to dig into the code, suggest a feature, or run batch scans, the GitHub repo is waiting. Suspicious files welcome; they make the tool better.