Qualitätskontrolle für Audio-Publishing in WordPressRedaktionsteams
Episodenqualität über mehrere Mitwirkende hinweg konsistent halten, ohne dass jede:r Redakteur:in wie ein Audio-Engineer denken muss.
EBU-R128-Audio-QC für WordPress
Wisse, dass eine Episode die Broadcast-Lautheit trifft, bevor sie live geht.
AudioLinter analysiert Podcast-Audio nach EBU R128 und repariert es per Klick auf -16 LUFS mit True Peak unter -1 dBTP – direkt in WordPress. Hochgeladene Dateien werden innerhalb von 48 Stunden auf EU-Servern gelöscht.
-16 LUFS
Ziel-Integrationslautheit
<= -1 dBTP
True-Peak-Grenze
48 h
Auto-Löschung auf EU-Servern
Für wen es ist
Für Teams gebaut, die Audio aus WordPress veröffentlichen – nicht für isolierte Desktop-Workflows
Das Produkt passt zu Radiosendern, Newsroom-Abläufen, Campus-Medien und Podcast-Teams, die Beiträge, Episoden und Medien bereits in WordPress verwalten.
Sender und Campus-Radio
Lautheitsprobleme, Clipping-Risiko und Dead Air erkennen, bevor ein Beitrag auf der Seite erscheint oder weiterverteilt wird.
Podcast-Betrieb
Produzent:innen eine leichtere QC-Ebene im CMS geben und Veröffentlichungsentscheidungen trotzdem explizit und überprüfbar lassen.
So funktioniert es
Ein Ablauf, der dazu passt, wie Publishing-Teams ohnehin arbeiten
Das Produkt versucht nicht, redaktionelles Urteilsvermögen zu ersetzen. Es ergänzt Analyse, optionale Reparatur und mehr Veröffentlichungssicherheit.
01
Hochladen oder aus der Mediathek wählen
Redakteur:innen können von einer lokalen Datei oder einem bestehenden WordPress-Medienelement starten, ohne den Publishing-Ablauf zu verlassen.
02
Das Analyseergebnis prüfen
AudioLinter prüft Lautheit, Spitzenpegel und Dead Air, damit Teams wissen, ob ein Beitrag veröffentlichungsbereit ist.
03
Bei Bedarf reparieren und erneut prüfen
Wenn Audio Arbeit braucht, können Teams eine reparierte Datei erzeugen, sie erneut analysieren und explizit entscheiden, wie sie veröffentlicht wird.
Warum die Website zählt
Die Website soll das Produkt verkaufen und den Workflow vermitteln
AudioLinter wird glaubwürdiger, wenn die öffentliche Seite nicht nur das Plugin erklärt, sondern auch, was Befunde bedeuten und wie man sie löst.
Marketing-Ebene
Landing, Preise und Produktpositionierung sollen Menschen helfen, den Wert schnell zu verstehen und zum richtigen Plan zu finden.
Doku-Ebene
Einrichtung, erste Analyse, Reparatur-Workflows, Kontingente und Produktregeln sollen in einem ruhigeren Dokumentationssystem leben.
Hilfe-Ebene
Teams sollen lernen können, was `too loud`, `peak too high` und `dead air` bedeuten – inklusive manueller Korrekturen in Tools wie Audacity.
Als Nächstes auf der Seite
Preise, Doku und Troubleshooting sollen sich wie ein Produkt anfühlen.
Das neue Website-Fundament soll Monetarisierung und Vertrauen tragen: das Plugin kaufen, die Ergebnisse verstehen und den richtigen Korrekturweg am selben Ort finden.