Het begon met irritatie
Eind 2023 moest ik audio uit een schermopname strippen voordat ik het naar een klant stuurde. De opname had mijn kant van een telefoongesprek vastgelegd dat op de achtergrond plaatsvond, en ik moest dat verwijderen voordat de video gedeeld kon worden.
Ik zocht een snelle oplossing en vond tientallen websites die aanboden om audio uit video te verwijderen. Ze wilden allemaal dat ik mijn bestand naar hun server uploadde. Een bestand met audio van een prive-telefoongesprek. Naar een onbekende server. Van een onbekend bedrijf. Met een onbekend databeleid.
Ik sloot elk tabblad en opende in plaats daarvan mijn terminal. Een FFmpeg-commando later was de audio weg. Maar de ervaring bleef bij me hangen. Niet iedereen kent FFmpeg. Niet iedereen heeft het geinstalleerd. En het feit dat de voor de hand liggende oplossing voor de meeste mensen inhield dat ze potentieel gevoelige content naar willekeurige servers uploadden, stoorde me als developer die om privacy geeft.
"Het moment dat ik besefte dat de 'makkelijke' oplossing voor de meeste mensen was om prive-audio naar servers van vreemden te uploaden, wist ik dat ik iets beters moest bouwen."
De architectuurbeslissing die alles bepaalde
De kerntechnische vraag was simpel: kon ik FFmpeg in een browser draaien? Als het antwoord ja was, dan was het hele upload-naar-server-model overbodig. Gebruikers konden hun video's lokaal verwerken en hun bestanden zouden nooit hun apparaat verlaten.
Het antwoord bleek ja te zijn, dankzij FFmpeg.wasm. Dit is een WebAssembly-port van FFmpeg, hetzelfde multimediaframework dat vrijwel elke professionele videotool aandrijft. Iemand had het ongelooflijke werk gedaan om deze C-gebaseerde tool te compileren zodat die in een browsersandbox kan draaien.
Toen ik FFmpeg.wasm voor het eerst in een prototype draaide, zag ik het een audiotrack uit een videobestand strippen volledig binnen het browsertabblad. Geen netwerkverzoek. Geen server. Het bestand ging van de schijf van de gebruiker naar het browsergeheugen, werd verwerkt door WebAssembly en kwam terug als een download. Ik dacht: zo zou elke online videotool moeten werken.
De technische uitdagingen waar niemand je voor waarschuwt
FFmpeg.wasm in een demo laten werken is een ding. Het betrouwbaar laten werken in elke browser, op elk apparaat en met elk bestandsformaat dat mensen erin gooien, is iets heel anders. Hier zijn de problemen die het grootste deel van mijn ontwikkeltijd opsloegen.
Geheugenbeheer was de grootste uitdaging. Browsers wijzen beperkt geheugen toe aan elk tabblad, en mobiele browsers zijn extra beperkt. Wanneer een gebruiker een videobestand van 500 megabyte laadt, moet de browser het originele bestand, de verwerkingsbuffer en het uitvoerbestand tegelijkertijd vasthouden. Op een telefoon met 3 gigabyte RAM gedeeld over elke open app en elk tabblad wordt die rekening snel krap.
Ik heb weken besteed aan het optimaliseren van hoe de tool bestanden in het geheugen afhandelt. Het bestand in stukken streamen, incrementeel verwerken en geheugen vrijgeven zodra elke fase klaar is. Het resultaat is dat de tool veel grotere bestanden aankan dan een naieve implementatie zou toelaten, maar er zijn nog steeds bovengrenzen die afhangen van het apparaat van de gebruiker.
Cross-browsercompatibiliteit was een ander konijnenhol. WebAssembly wordt door alle grote browsers ondersteund, maar de details van hoe elke browser het implementeert verschillen op subtiele manieren. Safari op iOS gaat anders om met SharedArrayBuffer dan Chrome op Android. Firefox heeft zijn eigen geheugentoewijzingseigenaardigheden. Ik heb een testmatrix gebouwd met meer dan 30 browser- en apparaatcombinaties en draaide die elke keer dat ik een wijziging pushte.
Formaatondersteuning was verrassend lastig. FFmpeg ondersteunt vrijwel elk formaat, maar de WebAssembly-build bevat niet elke codec om de downloadgrootte beheersbaar te houden. Ik moest de juiste balans vinden tussen het ondersteunen van gangbare formaten (MP4 met H.264, MOV, WebM) en het snel houden van de initiele paginalading. De meeste gebruikers komen nooit een niet-ondersteund formaat tegen, maar degenen die dat wel doen krijgen een duidelijke foutmelding en kunnen contact met me opnemen voor hulp.
Privacy is een architectuurkeuze, geen feature
Ik wil heel duidelijk zijn: Remove Audio is niet privé omdat we beloven niet naar je bestanden te kijken. Het is privé omdat je bestanden ons fysiek niet kunnen bereiken. Er is geen server-endpoint dat video-uploads accepteert. Er is geen API die bestandsgegevens ontvangt. De verwerkingscode draait in de sandbox van je browser, en de enige netwerkverzoeken die de pagina doet zijn voor het laden van de tool zelf en voor analytics en advertenties.
Dit onderscheid is belangrijker dan de meeste mensen beseffen. Wanneer een bedrijf zegt dat je gegevens veilig zijn op hun servers, vertrouw je op hun beveiligingspraktijken, hun medewerkers, hun infrastructuur en hun toekomstige beslissingen over dataretentie. Wanneer je gegevens je apparaat nooit verlaten, zijn geen van die vertrouwensvragen van toepassing.
Ik heb bewust voor deze architectuur gekozen, ook al betekent het dat ik sommige functies niet kan bieden die servergebaseerde tools wel hebben. Ik kan geen video's verwerken die groter zijn dan wat het browsergeheugen aankan. Ik kan geen achtergrondverwerking bieden terwijl de gebruiker het tabblad sluit. Ik kan geen mobiele app leveren die op de achtergrond verwerkt. Dit zijn echte afwegingen, en ik denk dat ze het waard zijn.
"Privacy zou geen vertrouwen moeten vereisen. Als je bestanden je apparaat nooit verlaten, valt er niets te vertrouwen. Dat is de architectuur die ik wilde."
De realiteit van solo-ontwikkeling
Remove Audio bouwen als solo-developer betekent dat ik elke beslissing neem, van de kleur van een knop tot de FFmpeg-commandovlaggen tot de formulering van het privacybeleid. Dit heeft voordelen: de tool blijft gefocust, beslissingen gaan snel en er is geen commissie die de kernmissie verwatert. Maar het betekent ook dat elk bugreport, elke support-e-mail en elke nachtelijke deployment op mij neerkomt.
Het moeilijkste van solo-ontwikkeling is niet de code. Het is het constante wisselen tussen developer, designer, technisch schrijver, supportmedewerker en marketeer. Ik zit diep in een WebAssembly-geheugenoptimalisatieprobleem en krijg een e-mail van een gebruiker wiens download mislukte op Safari iOS 16 op een specifiek iPad-model. Beide hebben aandacht nodig. Geen van beide kan wachten.
Wat me op de been houdt is de feedback. Elke keer dat iemand mailt om te zeggen dat de tool hen heeft bespaard om een gevoelige video naar een willekeurige website te uploaden, of dat ze 50 clips in een middag hebben gedempt voor hun social media-kalender, of dat hun grootouder het zonder hulp kon gebruiken, herinnert het me waarom ik dit heb gebouwd. Simpele tools die de privacy van mensen respecteren en echt werken. Dat is de missie.
Wat ik heb geleerd over het bouwen van tools die mensen gebruiken
Na meer dan 10 jaar webtools bouwen is dit waar ik steeds op terugkom: de tools die worden gebruikt zijn degene die uit de weg gaan. Niemand wil tijd besteden in een videodempingstool. Ze willen een video dempen en verder met hun dag. Elke seconde wrijving, elke onnodige stap, elk verwarrend UI-element is een reden voor iemand om het tabblad te sluiten en een alternatief te zoeken.
Deze filosofie bepaalt alles aan Remove Audio. Een pagina. Een actie. Sleep een bestand, klik op een knop, download het resultaat. Ik heb de verleiding weerstaan om functies toe te voegen die de kernervaring zouden compliceren. Geen audiobewerking. Geen video trimmen. Geen filters. Niet omdat die functies slecht zijn, maar omdat ze zouden afleiden van het doel waarvoor mensen kwamen.
De andere les is dat vertrouwen langzaam wordt opgebouwd en in een ogenblik verloren gaat. Ik ben transparant geweest over hoe de tool werkt, welke gegevens de site verzamelt (analytics- en advertentiegegevens, geen videocontent) en wat de beperkingen zijn. Als iets kapotgaat, repareer ik het en communiceer eerlijk. Als een gebruiker een randgeval heeft dat ik niet kan ondersteunen, zeg ik dat in plaats van ze tijd te laten verspillen.
Een tool bouwen waar mensen op vertrouwen is een verantwoordelijkheid die ik serieus neem. Elke video die iemand via Remove Audio verwerkt kan prive-momenten bevatten, gevoelige informatie of professionele content waarvan ze erop rekenen dat ik het niet verpest. Dat gewicht houdt de codekwaliteit hoog en de privacyarchitectuur niet-onderhandelbaar.
Wat hierna komt
Remove Audio blijft een gefocuste, privacy-first tool die een ding goed doet. Ik heb een lijst met verbeteringen waar ik aan werk: betere prestaties op eenvoudige apparaten, bredere formaatondersteuning en verbeterde toegankelijkheidsfuncties. Maar de kernarchitectuur, lokale verwerking zonder serveruploads, zal nooit veranderen.
Ik ben ook van plan meer te schrijven over de technische kant van browsergebaseerde videoverwerking. Het webplatform is capabeler dan de meeste developers beseffen, en ik denk dat we meer tools zullen zien die gevoelige media lokaal verwerken in plaats van serveruploads te vereisen. Als dit bericht je aanspreekt, houd dan de blog in de gaten voor diepere technische duiken.
En als je zover bent gekomen, bedankt voor het lezen. Of je nu Remove Audio regelmatig gebruikt of toevallig op dit bericht bent gestuit, ik waardeer de tijd. Als je vragen hebt over de tool, de technologie of iets wat ik hier heb geschreven, neem dan contact op via de contactpagina. Ik lees en beantwoord elk bericht persoonlijk.
Bouwen voor privacy in een upload-alles-wereld
Het web heeft het uploaden van persoonlijke content naar externe servers genormaliseerd, zelfs voor de eenvoudigste verwerkingstaken. Ik denk dat die standaard het bevragen waard is, vooral voor tools die video en audio verwerken. Niet elke taak heeft een server nodig. Niet elk bestand hoeft je apparaat te verlaten.
Remove Audio is mijn antwoord op die vraag: een tool die bewijst dat je een goede gebruikerservaring kunt leveren zonder ooit de bestanden van een gebruiker aan te raken. WebAssembly maakte het mogelijk. Koppigheid maakte het werkelijkheid. En de feedback van gebruikers die net zoveel om hun privacy geven als ik, maakt het de moeite waard om door te gaan.
Als je een developer bent die een vergelijkbare aanpak overweegt voor je eigen tools, deel ik graag wat ik heb geleerd. En als je een gebruiker bent die gewoon een video wil dempen zonder je zorgen te maken over waar je bestand naartoe gaat, dan is dat precies waarvoor ik dit heb gebouwd.