Es begann mit Genervtsein
Ende 2023 musste ich vor dem Versand an einen Kunden den Ton aus einer Bildschirmaufnahme entfernen. In der Aufnahme war mein Teil eines Telefonats zu hören, das im Hintergrund lief, und ich musste ihn löschen, bevor das Video geteilt werden konnte.
Ich suchte nach einer schnellen Lösung und fand Dutzende Websites, die anboten, Audio aus Videos zu entfernen. Alle wollten, dass ich meine Datei auf ihren Server hochlade. Eine Datei mit dem Ton eines privaten Telefonats. Auf einen unbekannten Server. Betrieben von einem unbekannten Unternehmen. Mit einer unbekannten Aufbewahrungsrichtlinie.
Ich schloss jeden Tab und öffnete stattdessen mein Terminal. Ein FFmpeg-Befehl später war das Audio weg. Aber das Erlebnis blieb hängen. Nicht jeder kennt FFmpeg. Nicht jeder hat es installiert. Und dass die offensichtliche Lösung für die meisten Menschen darin bestand, potenziell sensibles Material auf irgendwelche Server hochzuladen, hat mich als Entwickler, dem Privatsphäre wichtig ist, gestört.
"In dem Moment, als mir klar wurde, dass die 'einfache' Lösung für die meisten Leute darin bestand, privaten Ton auf fremde Server hochzuladen, wusste ich: Ich muss etwas Besseres bauen."
Die Architektur-Entscheidung, die alles definiert hat
Die zentrale technische Frage war einfach: Kann ich FFmpeg im Browser ausführen? Wenn die Antwort ja lautet, ist das gesamte Upload-auf-Server-Modell überflüssig. Nutzer könnten ihre Videos lokal verarbeiten, und ihre Dateien würden das Gerät nie verlassen.
Die Antwort war tatsächlich ja – dank FFmpeg.wasm. Das ist eine WebAssembly-Portierung von FFmpeg, also genau jenem Multimedia-Framework, das praktisch jedes professionelle Video-Tool antreibt. Jemand hatte die beeindruckende Arbeit geleistet, dieses in C geschriebene Tool so zu kompilieren, dass es in einer Browser-Sandbox läuft.
Als FFmpeg.wasm zum ersten Mal in einem Prototyp lief, sah ich zu, wie es eine Audiospur vollständig innerhalb eines Browser-Tabs aus einer Videodatei entfernte. Keine Netzwerkanfrage. Kein Server. Die Datei ging von der Festplatte des Nutzers in den Browser-Speicher, wurde dort per WebAssembly verarbeitet und kam wieder als Download heraus. Ich erinnere mich, dass ich dachte: Genau so sollte jedes Online-Video-Tool funktionieren.
Die technischen Herausforderungen, vor denen dich niemand warnt
FFmpeg.wasm in einer Demo zum Laufen zu bringen, ist eine Sache. Es zuverlässig über verschiedene Browser, Geräte und Dateiformate hinweg zum Laufen zu bringen, die Menschen tatsächlich hineinwerfen, ist etwas völlig anderes. Diese Probleme haben den Großteil meiner Entwicklungszeit verschlungen.
Das Speichermanagement war die größte Herausforderung. Browser weisen jedem Tab nur begrenzt Arbeitsspeicher zu, und mobile Browser sind besonders eingeschränkt. Wenn ein Nutzer eine 500-Megabyte-Videodatei lädt, muss der Browser gleichzeitig die Originaldatei, den Verarbeitungspuffer und die Ausgabedatei halten. Auf einem Handy mit 3 Gigabyte RAM, das sich jede offene App und jeden Tab teilt, wird diese Rechnung sehr schnell eng.
Ich habe Wochen damit verbracht, zu optimieren, wie das Tool Dateien im Speicher behandelt: die Datei in Blöcken streamen, schrittweise verarbeiten und Speicher freigeben, sobald ein Schritt abgeschlossen ist. Das Ergebnis ist, dass das Tool deutlich größere Dateien verarbeiten kann, als eine naive Implementierung erlauben würde – trotzdem bleiben Grenzen, die vom Gerät des Nutzers abhängen.
Die Browser-Kompatibilität war ein weiteres Rabbit Hole. WebAssembly wird von allen großen Browsern unterstützt, aber die Details der jeweiligen Implementierung unterscheiden sich in subtilen Punkten. Safari auf iOS geht anders mit SharedArrayBuffer um als Chrome auf Android. Firefox hat eigene Eigenheiten bei der Speicherverwaltung. Ich habe eine Testmatrix mit über 30 Browser- und Gerätekombinationen aufgebaut und sie bei jeder Änderung durchlaufen lassen.
Auch die Formatunterstützung war überraschend knifflig. FFmpeg unterstützt fast jedes Format, aber der WebAssembly-Build enthält nicht jeden Codec, damit der Download nicht zu groß wird. Ich musste die richtige Balance finden zwischen der Unterstützung gängiger Formate – MP4 mit H.264, MOV, WebM – und einer schnellen ersten Seitenladung. Die meisten Nutzer stoßen nie auf ein nicht unterstütztes Format. Wer es doch tut, bekommt eine klare Fehlermeldung und kann mich kontaktieren.
Privatsphäre ist eine Architekturentscheidung, kein Feature
Eines möchte ich ganz klar sagen: Remove Audio ist nicht privat, weil wir versprechen, deine Dateien nicht anzuschauen. Es ist privat, weil deine Dateien uns physisch gar nicht erreichen können. Es gibt keinen Server-Endpunkt, der Video-Uploads entgegennimmt. Es gibt keine API, die Dateidaten empfängt. Der Code läuft in der Sandbox deines Browsers, und die einzigen Netzwerkanfragen der Seite dienen dem Laden des Tools selbst sowie Analytics und Werbung.
Diese Unterscheidung ist wichtiger, als den meisten bewusst ist. Wenn ein Unternehmen sagt, deine Daten seien auf seinen Servern sicher, musst du auf seine Sicherheitspraktiken, seine Mitarbeiter, seine Infrastruktur und seine künftigen Entscheidungen zur Datenaufbewahrung vertrauen. Wenn deine Daten dein Gerät nie verlassen, stellen sich all diese Vertrauensfragen gar nicht.
Ich habe diese Architektur bewusst gewählt, obwohl sie bedeutet, dass ich manche Funktionen serverbasierter Tools nicht anbieten kann. Ich kann keine Videos verarbeiten, die größer sind als das, was der Browser-Speicher hergibt. Ich kann keine Hintergrundverarbeitung anbieten, wenn der Nutzer den Tab schließt. Ich kann keine Mobile-App bauen, die im Hintergrund rechnet. Das sind echte Kompromisse – und ich halte sie für sinnvoll.
"Privatsphäre sollte kein Vertrauensvorschuss sein. Wenn deine Dateien dein Gerät nie verlassen, gibt es nichts, worauf du vertrauen musst. Genau diese Architektur wollte ich."
Die Realität als Solo-Entwickler
Remove Audio als Solo-Entwickler zu bauen heißt, dass ich jede Entscheidung treffe – von der Farbe eines Buttons über die FFmpeg-Flags bis zur Formulierung der Datenschutzerklärung. Das hat Vorteile: Das Tool bleibt fokussiert, Entscheidungen fallen schnell, und kein Gremium verwässert die Kernmission. Aber es bedeutet auch, dass jeder Bug-Report, jede Support-Mail und jedes nächtliche Deployment bei mir landet.
Das Schwierigste an Solo-Entwicklung ist nicht der Code. Es ist das permanente Wechseln zwischen Entwickler, Designer, Technical Writer, Support und Marketer. Ich stecke tief in einem WebAssembly-Speicherproblem und bekomme gleichzeitig eine Mail von einem Nutzer, bei dem der Download auf Safari iOS 16 auf einem bestimmten iPad-Modell scheitert. Beides braucht Aufmerksamkeit. Nichts kann warten.
Was mich dranbleiben lässt, ist das Feedback. Jedes Mal, wenn mir jemand schreibt, dass das Tool sie davor bewahrt hat, ein sensibles Video auf irgendeine Website hochzuladen, oder dass sie an einem Nachmittag 50 Clips für ihren Social-Media-Kalender stummgeschaltet haben, oder dass sogar ihre Großeltern es ohne Hilfe nutzen konnten, werde ich daran erinnert, warum ich das gebaut habe. Einfache Tools, die Privatsphäre respektieren und wirklich funktionieren. Das ist die Mission.
Was ich darüber gelernt habe, Tools zu bauen, die Menschen wirklich nutzen
Nach mehr als 10 Jahren, in denen ich Web-Tools baue, komme ich immer wieder auf dasselbe zurück: Die Tools, die genutzt werden, sind die, die nicht im Weg stehen. Niemand will Zeit in einem Tool zum Stummschalten von Videos verbringen. Man will ein Video stummschalten und mit dem Tag weitermachen. Jede Sekunde Reibung, jeder unnötige Schritt, jedes verwirrende UI-Element ist ein Grund, den Tab zu schließen und nach einer Alternative zu suchen.
Diese Philosophie prägt alles an Remove Audio. Eine Seite. Eine Aktion. Datei hineinziehen, Button klicken, Ergebnis herunterladen. Ich habe der Versuchung widerstanden, Features einzubauen, die das Kernerlebnis komplizierter machen würden. Kein Audio-Editing. Kein Video-Trimmen. Keine Filter. Nicht, weil diese Funktionen schlecht wären, sondern weil sie von dem ablenken würden, wofür die Menschen gekommen sind.
Die andere Lektion lautet: Vertrauen wird langsam aufgebaut und ist sofort verspielt. Ich war transparent darüber, wie das Tool funktioniert, welche Daten die Seite sammelt – Analytics- und Werbedaten, aber keine Videoinhalte – und wo die Grenzen liegen. Wenn etwas kaputtgeht, behebe ich es und kommuniziere ehrlich. Wenn ein Nutzer einen Sonderfall hat, den ich nicht unterstützen kann, sage ich das offen, statt seine Zeit zu verschwenden.
Ein Tool zu bauen, auf das Menschen sich verlassen, ist eine Verantwortung, die ich ernst nehme. Jedes Video, das jemand durch Remove Audio verarbeitet, kann private Momente, sensible Informationen oder beruflich wichtiges Material enthalten, bei dem die Person darauf zählt, dass ich nichts falsch mache. Dieses Gewicht hält die Codequalität hoch und die Privacy-Architektur nicht verhandelbar.
Wie es weitergeht
Remove Audio bleibt ein fokussiertes Tool mit Privacy-First-Ansatz, das eine Sache gut macht. Ich arbeite an einer Liste von Verbesserungen: bessere Performance auf schwächeren Geräten, breitere Formatunterstützung und bessere Accessibility-Features. Aber die Kernarchitektur – lokale Verarbeitung ohne Server-Uploads – wird sich nie ändern.
Ich plane außerdem, mehr über die technische Seite browserbasierter Videoverarbeitung zu schreiben. Die Web-Plattform kann deutlich mehr, als vielen Entwicklern bewusst ist, und ich glaube, wir werden mehr Tools sehen, die sensible Medien lokal verarbeiten, statt Uploads auf Server zu verlangen. Wenn dich dieser Beitrag angesprochen hat, schau im Blog vorbei – dort wird es tiefere technische Einblicke geben.
Und wenn du bis hier gelesen hast: Danke. Egal, ob du Remove Audio regelmäßig nutzt oder zufällig auf diesen Beitrag gestoßen bist – ich schätze deine Zeit. Wenn du Fragen zum Tool, zur Technik oder zu etwas hast, das ich hier geschrieben habe, melde dich über die Kontaktseite. Ich lese und beantworte jede Nachricht persönlich.
Für Privatsphäre bauen in einer Welt des Upload-everything
Das Web hat es normalisiert, persönliche Inhalte selbst für die simpelsten Verarbeitungsschritte auf entfernte Server hochzuladen. Ich finde, dieses Standardmuster sollte hinterfragt werden – besonders bei Tools, die mit Video und Audio arbeiten. Nicht jede Aufgabe braucht einen Server. Nicht jede Datei muss dein Gerät verlassen.
Remove Audio ist meine Antwort auf diese Frage: ein Tool, das beweist, dass man eine gute Nutzererfahrung liefern kann, ohne jemals die Dateien der Nutzer anzufassen. WebAssembly hat es möglich gemacht. Sturheit hat dafür gesorgt, dass es tatsächlich entstanden ist. Und das Feedback von Nutzern, denen Privatsphäre genauso wichtig ist wie mir, macht es lohnend, weiterzumachen.
Wenn du als Entwickler einen ähnlichen Ansatz für deine eigenen Tools in Betracht ziehst, teile ich gern, was ich gelernt habe. Und wenn du als Nutzer einfach nur ein Video stummschalten willst, ohne dir Sorgen zu machen, wo deine Datei landet, dann habe ich dieses Tool genau dafür gebaut.