What exactly does AudioLinter check?

Loudness, against the standard that radio and streaming services follow (EBU R128). AudioLinter measures how loud a recording is on average, how high the loudest moments peak, how much the loudness varies and where longer silence sits. Anything that stands out can be fixed in one step, without taking the file out of WordPress.

Why is the WordPress directory listing worth mentioning?

Because outsiders do the checking there. The WordPress team looks for security holes, among other things. It also checks who is allowed to do what and whether the add-on can be translated. So anything listed there has been looked at by someone other than its author. Later, all new versions arrive through the same directory.

Why does the version history list your own security bugs?

Because that is where they belong. One example: a check only looked at whether someone may upload to the website. It did not look at whether they may edit the individual post. Another: access keys were readable in the form. Both are fixed. Whoever fixes such bugs quietly takes away their users' chance to judge whether they were affected.

Why does an add-on need so much technology behind it?

Because the check cannot run on the customer's website. Processing audio takes a lot of computing power and longer than a website should wait. So the add-on sends the file to a separate service. There it is stored, scanned for viruses and then processed. Eight parts work together to do that.

LiveSL-01

Getting a one-person product through the WordPress.org review

AudioLinter checks podcast and spoken-word recordings for even loudness and repairs them in one click, right inside WordPress. I built the product alone and look after it myself, 36 versions so far. The hardest part was not the audio. It was the review every add-on has to pass before it is allowed into the official WordPress directory.

Visit the project

SL-01Live

AudioLinter

353 · Downloads via the WordPress directory

~7 · Days until approval in the directory

Verified numbers

Downloads via the WordPress directory: 353Source: wordpress.org/plugins, as of 24.08.2026
Days until approval in the directory: ~7Source: WordPress.org review thread, July 2026
Versions shipped: 36Source: CHANGELOG.md and wordpress.org, as of 11.08.2026 (v1.0.36)
Parts that work together in the background: 8Source: docker-compose.prod.yml, as of 11.08.2026
Files with automated tests: 140Source: Project code, as of 11.08.2026

Starting point

People who publish podcasts through WordPress often notice loudness problems only when listeners complain. One episode is too quiet, the next too loud, with seconds of silence in between. You can only check that in a separate audio program. So the file has to leave WordPress and be uploaded again afterwards. That detour was meant to go away.

Outcome

A running service that is listed in the official WordPress directory and updated through it. 36 versions have been released so far. Before a listing, outsiders review the software, security included. Passing that review is the best proof of quality this project has.

The problem was the detour, not the check

Checking the loudness of a recording is not a new problem. Programs for it have existed for years. What was unsolved was the way there. Someone who uploads a podcast episode to WordPress would have to download it again, open it in an audio program, check it, correct it, save it and upload it again. With one episode a week, people simply stop doing that at some point.

So I did not build a better check. I brought the existing check to where the file already is.

Why eight parts run in the background

A WordPress add-on cannot process audio by itself. Most websites lack the computing power, and a website must not wait minutes for an answer. So the add-on is only the switch. The work happens on a separate machine.

There, every file is first received and stored. Then a virus scanner checks it, because these are other people’s files from other people’s websites. Only then is it examined and repaired. That runs in the background so nobody has to wait.

For the technically minded: the eight services

A FastAPI layer accepts the upload, checks API key and quota and stores the file in S3-compatible object storage. ClamAV scans it. Analysis and repair run asynchronously in a Celery worker with FFmpeg. Postgres holds keys, quotas and session data, Redis is queue and cache, Traefik terminates TLS.

Nobody wishes for this much technology in a side project. It follows from the task. Each of these parts solves one specific problem, none is there for fun.

The real hurdle was WordPress.org

What says most about the work is not the audio processing. It is being accepted into the official WordPress directory. There a team you do not know reviews the whole program. It looks for security holes and checks who is allowed to do what.

The reviewers found things I had not seen myself. Preparing for the review brought up more. They are named in the public version history. One check only looked at whether someone may upload, not whether they may edit the individual post. Messages from the service were written into the page unchecked. And access keys were readable in the form. They would have shown up in every screenshot.

Those entries are public because that is what a version history is for. Whoever fixes a security hole quietly takes away their users’ chance to judge whether they were affected.

What 36 versions mean

New versions arrive through the same directory WordPress uses for all updates. So every version lands on websites that are already running. A broken version breaks other people’s websites.

That happened once. In version 1.0.27 a bug slipped into the program during a clean-up. For everyone who had set up a certain notification, it crashed the whole WordPress admin area. I only found it two versions later. The entry about it names the affected versions and the cause. It recommends updating immediately.

It is not pretty. But handling it honestly is the point. Anyone who releases 36 versions will release a bad one at some point. What matters is whether users learn what happened.

What is not here

User numbers. The directory currently reports fewer than ten active installations. That is not a selling point, and I am not turning it into one. This project shows something else: one person can build a complete service with virus scanning and billing, get it through an outside review and maintain it for months.

Frequently asked

What exactly does AudioLinter check?: Loudness, against the standard that radio and streaming services follow (EBU R128). AudioLinter measures how loud a recording is on average, how high the loudest moments peak, how much the loudness varies and where longer silence sits. Anything that stands out can be fixed in one step, without taking the file out of WordPress.
Why is the WordPress directory listing worth mentioning?: Because outsiders do the checking there. The WordPress team looks for security holes, among other things. It also checks who is allowed to do what and whether the add-on can be translated. So anything listed there has been looked at by someone other than its author. Later, all new versions arrive through the same directory.
Why does the version history list your own security bugs?: Because that is where they belong. One example: a check only looked at whether someone may upload to the website. It did not look at whether they may edit the individual post. Another: access keys were readable in the form. Both are fixed. Whoever fixes such bugs quietly takes away their users' chance to judge whether they were affected.
Why does an add-on need so much technology behind it?: Because the check cannot run on the customer's website. Processing audio takes a lot of computing power and longer than a website should wait. So the add-on sends the file to a separate service. There it is stored, scanned for viruses and then processed. Eight parts work together to do that.

All work