Skip to content
Sabib, Tanzim Rahman Sabib, homeRésumé
All work

Case study 01, Iqra Wave Foundation

Music Remover

An AI tool that strips the background music out of videos and keeps the voices. I was the technical owner: I took it from zero to MVP alongside the co-founder, and the architecture I laid down is what shipped to production.

  • 3,000+

    users, rated 4.9 from 60+ reviews on the Chrome Web Store

  • ~3.3 s

    to process a one-minute video (real-time factor ≈ 0.055)

  • >95%

    smaller ML deployment: 1–⁠2.5 GB down to under 50 MB

Open the Music Remover live site (opens in a new tab)
Music Remover’s website: an “Add to Chrome” card for muting music on YouTube videos, next to a drop zone for uploading audio or video files.

The problem

Background music gets in the way of a lot of video: lectures, podcasts, tutorials, and for some people, religious or personal reasons. The job: strip the music out of any video and keep the speech, fast enough that nobody sits waiting, and small enough to run on people’s own machines.

My part

I was the technical owner, working alongside the co-founder. I made the architecture calls and built the Chrome extension, the Windows desktop app, the FastAPI services and the async workers.

What I built

  1. ClientsChrome extension, Windows desktop app
  2. APIFastAPI services
  3. JobsCelery workers on a Redis queue, in Docker
  4. Audioyt-dlp → FFmpeg → ONNX separation (Spleeter, sherpa-onnx)
  5. Cloud tierSupabase auth, usage-based credits, cloud or local GPU
Music Remover, top to bottom.

It runs two ways. Locally, the desktop app does the separation on the user’s own machine. In the cloud tier, separation runs on pay-per-second serverless GPUs, with Supabase auth, usage-based credits and real-time job tracking; that tier is in limited beta.

Decisions that mattered

  1. Shrink the model instead of paying for bigger machines

    The stock model stack weighed 1–⁠2.5 GB. I replaced it with custom ONNX builds and a minimal FFmpeg, and the ML deployment came in under 50 MB. That size is what made two things possible: running locally inside the desktop app, and pay-per-second serverless GPUs in the cloud.

    Stock model stack1–2.5 GB
    What shippedunder 50 MB
    ML deployment size, on one linear scale. The light segment is the 1–2.5 GB range.

  2. Queue the heavy work, and make it safe to retry

    Separation runs in Celery workers behind a Redis queue, off the request path, so the API stays quick and the cloud tier can track each job in real time. Long media jobs fail halfway sometimes: a download drops, a decode stalls. Jobs are idempotent with fault-tolerant retries, so a failed step runs again without doing the work twice.