htdemucs vs BS-RoFormer vs Spleeter: een audio bron-scheiding benchmark 2026

Wie zich het afgelopen jaar in AI-muziekscheiding heeft verdiept, is waarschijnlijk dezelfde drie namen tegengekomen: Spleeter, htdemucs (Hybrid Transformer Demucs) en BS-RoFormer. Ze duiken op in elke vergelijking, elk paper en elke "hoe verwijder ik vocalen"-tutorial — maar de manier waarop ze worden vergeleken klopt meestal niet. De meeste posts citeren één SDR-getal uit een paper uit 2019 en houden het daarbij.

Dat is niet bruikbaar als je een product wilt bouwen, een pipeline wilt opzetten of een model wilt kiezen voor echte audio.

Dit artikel vergelijkt de drie modellen op de dimensies die er écht toe doen wanneer je audio bron-scheiding in productie zet:

Kwaliteit — SDR-scores uit peer-reviewed bronnen, geen onderbuikgevoel
Inference snelheid — waar je in productie daadwerkelijk op zit te wachten
Kosten per song — draaiend op gangbare GPU's tegen 2026-prijzen
Output flexibiliteit — 2 stems vs 4 stems vs 6 stems
Wanneer welk model de juiste keuze is — en wanneer niet

Alles hieronder is gebaseerd op gepubliceerde benchmarks plus onze eigen productiedeployment van htdemucs op schaal. Waar we cijfers noemen, noemen we ook de bron.

TL;DR (voor wie nu het antwoord wil)

Model	Geschikt voor	Output stems	Kwaliteit (gem. SDR)	Snelheid
Spleeter	Real-time, lichte hardware, batch processing	2, 4 of 5	~5,9 dB (vocalen)	~100× real-time op GPU
htdemucs	Productie consumer-apps, balans tussen kwaliteit en snelheid	4 of 6	~9,0 dB (gem.)	~5–8× real-time op A40
BS-RoFormer	Hoogste kwaliteit voor offline werk, mastering, archief	4 (meestal)	~9,80 dB (gem.)	~2–3× real-time op A40

Als je maar één ding meeneemt uit dit artikel: htdemucs is voor vrijwel elk product de juiste default, en je draait waarschijnlijk beter htdemucs_ft dan de standaard checkpoint. Op de serverless pricing van Replicate kosten alle drie de Demucs-varianten (default, 6s, ft) per call ongeveer hetzelfde — maar ft levert merkbaar betere scheiding. We hadden dit niet verwacht toen we begonnen; het werd pas duidelijk toen we naar onze daadwerkelijke factuur keken.

BS-RoFormer is alleen op bas duidelijk beter en alleen wanneer latency niet uitmaakt. Spleeter is een model uit 2019 dat op 2026-hardware draait — snel, maar het kwaliteitsverschil is inmiddels hoorbaar.

De rest van dit artikel legt uit waarom.

Wat we bedoelen met "kwaliteit" — SDR kort uitgelegd

De kwaliteit van music source separation wordt meestal gemeten in Signal-to-Distortion Ratio (SDR), in decibels. Hoger is beter. De referentie-dataset is MUSDB18 (of MUSDB18-HQ voor high-quality audio), met 150 volledige tracks inclusief geïsoleerde stems voor zang, drums, bas en "other".

Een paar praktische ankerpunten:

<6 dB SDR: hoorbare artefacten, "phasey" vocalen, hoorbare bleed tussen stems
6–8 dB SDR: bruikbaar voor casual doeleinden (karaoke, songs leren, ideeën uitwerken)
8–10 dB SDR: schoon genoeg voor content creatie en de meeste DJ-toepassingen
>10 dB SDR: tegen transparant aan voor de gemiddelde luisteraar; geschikt voor release-kwaliteit na lichte cleanup

Alles boven ~9 dB op vocalen ligt voorbij het punt waar de meeste luisteraars in een blindtest nog verschil horen. De winst daarboven gaat over edge cases — zware reverb, dubbele vocalen, complexe mixen.

Een opmerking over SI-SDR: sommige recente papers rapporteren SI-SDR (scale-invariant SDR), die corrigeert voor simpele gain-verschillen en robuuster is. Wanneer cijfers in dit artikel afwijken van andere bronnen, zit het verschil meestal in de definitie van de metric.

De drie modellen, kort

Spleeter (Deezer, 2019)

Uitgebracht door het research team van Deezer in 2019, is Spleeter een U-Net architectuur die in het spectrogram-domein opereert. Het komt in 2-stem (vocalen/begeleiding), 4-stem (vocalen/drums/bas/other) en 5-stem (voegt piano toe) configuraties.

Het was destijds een mijlpaal — de eerste keer dat iemand fatsoenlijke source separation kon draaien op een laptop-CPU zonder licentiekosten. Zes jaar later is het op kwaliteit ingehaald door elk modern model, maar het blijft met afstand de snelste en lichtste optie.

htdemucs (Meta AI, 2022)

De vierde generatie Demucs van het research team van Meta AI. Anders dan Spleeter is htdemucs een hybride model — het opereert zowel in het tijddomein (waveform) als in het frequentiedomein (spectrogram), met een Transformer-backbone die ze verbindt. Het originele paper rapporteert een SDR-verbetering van 1,4 dB ten opzichte van de vorige Demucs-generatie op MUSDB-HQ.

Twee varianten doen er in de praktijk toe:

htdemucs — het standaard 4-stem model
htdemucs_6s — een 6-stem variant die geïsoleerde gitaar- en piano-stems toevoegt

Daarnaast is er htdemucs_ft, een fine-tuned versie die langzamer is maar iets accurater op individuele stems.

htdemucs deed competitief mee in de Sony Music Demixing Challenge van 2021 en blijft de default voor de meeste productie-pipelines die niet de absolute SOTA najagen.

BS-RoFormer (2023)

De huidige state of the art op MUSDB18-HQ. BS-RoFormer (Band-Split RoPE Transformer) is een pure Transformer-architectuur die RNN-modules vervangt door een hiërarchische RoPE Transformer. Het splitst het input-spectrogram op in meerdere niet-overlappende frequentie-subbanden en benut het feit dat verschillende instrumenten karakteristieke frequentiebereiken bezetten (bas laag, cymbalen hoog, etc.).

BS-RoFormer, getraind op MUSDB18-HQ plus 500 extra songs, won de eerste plaats in de Music Source Separation track van de Sound Demixing Challenge 2023 (SDX23). Zelfs de kleinere versie zonder extra trainingsdata rapporteert 9,80 dB gemiddelde SDR op MUSDB18-HQ.

Het nadeel: het is langzamer en geheugenintensiever dan htdemucs, en de productieklare open weights zijn nog steeds verspreid over community implementaties in plaats van één canonieke release.

1. Kwaliteitsbenchmark (gepubliceerde SDR-scores)

Dit is waar de meeste vergelijkingsposts uit elkaar vallen — ze pikken één getal eruit. Hieronder de per-stem SDR-scores uit de gepubliceerde literatuur, op MUSDB18-HQ (zonder extra trainingsdata, tenzij anders vermeld):

Model	Vocalen	Drums	Bas	Other	Gemiddeld
Spleeter (4-stem)	~5,9 dB	~5,9 dB	~5,5 dB	~4,5 dB	~5,4 dB
htdemucs (default)	~8,1 dB	~8,4 dB	~8,6 dB	~5,9 dB	~7,7 dB
htdemucs_ft (fine-tuned)	~8,9 dB	~9,5 dB	~9,4 dB	~6,4 dB	~8,5 dB
BS-RoFormer (geen extra data)	—	—	~11,28 dB	—	~9,80 dB
BS-RoFormer (met 500 extra songs)	—	—	—	—	~9,76 dB+

Bronnen: Spleeter-scores uit het Spleeter JOSS paper en de BeatsToRapOn separation benchmark. htdemucs-scores uit Hybrid Spectrogram and Waveform Source Separation en Benchmarks and leaderboards for sound demixing tasks. BS-RoFormer-scores uit de SDX23-resultaten gedocumenteerd in hetzelfde paper.

Een paar observaties uit de tabel:

Het gat Spleeter → htdemucs is groter dan het gat htdemucs → BS-RoFormer. Van Spleeter naar htdemucs win je gemiddeld ongeveer +2,3 dB. Van htdemucs naar BS-RoFormer ongeveer +1,3 dB. Dit is precies waarom htdemucs voor de meeste use cases de praktische sweet spot is.

De grootste winst van BS-RoFormer zit op bas. Bas-scheiding springt van ~8,6 dB (htdemucs) naar ~11,28 dB (BS-RoFormer) — een verschil dat je in een blindtest hoort. De winst op vocalen en drums is kleiner. Bouw je iets dat specifiek schone bas nodig heeft (DJ-tools, transcriptie, muziekonderwijs voor bassisten), dan is BS-RoFormer de extra compute waard. Voor de rest zit de winst op de rand van wat je nog kunt waarnemen.

htdemucs_ft wordt onderschat. Veel vergelijkingsposts testen alleen de default htdemucs checkpoint. De fine-tuned versie (htdemucs_ft) sluit het grootste deel van het gat naar BS-RoFormer voor ongeveer 4× de inference tijd — in de praktijk nog altijd sneller dan BS-RoFormer.

2. Inference snelheid (echt, niet theoretisch)

Geschatte end-to-end tijd voor een song van 3 minuten op één A40 GPU, gemeten van API-call tot download-klare output:

Model	End-to-end tijd	Real-time multiplier
Spleeter (4-stem, GPU)	~2–5 seconden	~40–90× real-time
htdemucs (default, 4-stem)	~30–45 seconden	~4–6× real-time
htdemucs_6s (6-stem)	~40–60 seconden	~3–5× real-time
htdemucs_ft (fine-tuned)	~90–150 seconden	~1,2–2× real-time
BS-RoFormer	~60–120 seconden	~1,5–3× real-time

Opmerkingen:

End-to-end tijd ≠ pure GPU inference tijd. Publieke benchmarks rapporteren meestal alleen de model forward pass op schone input. Echte productietijd omvat container cold start (5–30s op serverless), audio I/O (file download, ffmpeg pre-processing) en result upload. Onze cijfers hierboven zijn end-to-end op Replicate.
Spleeter speelt een heel andere wedstrijd qua snelheid. Het is de enige die comfortabel sneller dan real-time draait op CPU alleen.
De overlap parameter van htdemucs is een grote knop voor snelheid. De default overlap=0.25 is een redelijke trade-off; overlap=0.5 verbetert de kwaliteit licht tegen ~2× de kosten; overlap=0 maakt het merkbaar sneller maar introduceert hoorbare chunking-artefacten op segmentgrenzen.
De referentie-implementaties van BS-RoFormer verschillen enorm in snelheid afhankelijk van wiens checkpoint en inference code je gebruikt. Bovenstaande cijfers gelden voor de community-populaire MVSep BS-RoFormer SW build.

Bouw je een consumentenproduct waar gebruikers op resultaten wachten, dan begint alles boven ~60 seconden voor een song van 3 minuten in onze ervaring conversie te kosten. Dat houdt htdemucs (default en 6s) binnen acceptabel terrein en duwt htdemucs_ft en BS-RoFormer richting async/queued flows waar de gebruiker later kan terugkomen.

3. Kosten per song (productiedeployment economics)

Dit is het hoofdstuk waar de meeste online vergelijkingen er volledig naast zitten. De publieke pricing op Replicate ziet er rechtdoorzee uit — A40 op $0,000725/seconde, vermenigvuldigen met inference tijd, klaar. In de praktijk zit die berekening er ongeveer 2× naast tegenover je werkelijke factuur, en er zit een interessantere wrinkle in die vrijwel geen vergelijkingspost benoemt.

De kernconclusie uit onze productiedeployment

We draaien htdemucs al meerdere maanden in productie op aistemsplitter.org over alle drie de Demucs-varianten — htdemucs (default 4-stem), htdemucs_6s (6-stem) en htdemucs_ft (fine-tuned). Op de A40 GPU instances van Replicate kosten alle drie de varianten in onze daadwerkelijke billing ongeveer hetzelfde per call: ruwweg 22 calls per $1, oftewel ongeveer $0,045 per song.

Dat is een pauze waard, want het spreekt tegen wat je op basis van de gepubliceerde inference tijden zou verwachten.

Model	Naïeve kosten (publieke pricing × inference tijd)	Onze daadwerkelijk gemeten kosten
Spleeter (GPU)	<$0,002	<$0,005
htdemucs (default)	~$0,022	~$0,045
htdemucs_6s (6-stem)	~$0,029	~$0,045
htdemucs_ft (fine-tuned)	~$0,11	~$0,045
BS-RoFormer	~$0,065	~$0,06–0,10 (varieert)

Waarom alle drie de Demucs-varianten convergeren naar dezelfde kosten

Het naïeve pricing-model gaat ervan uit dat je alleen voor pure GPU inference tijd betaalt. In werkelijkheid omvat elke Replicate-call ook:

Container cold-start tijd (5–30 seconden bij schalen vanaf nul)
Model weights laden in GPU-geheugen
Audio file download en ffmpeg pre-processing
Result encoding en upload terug naar storage
Een minimale billable duration per call

Deze overhead is grofweg vaste kosten per invocation — ze schalen niet mee met hoe complex je model is. Wanneer de GPU forward pass van 30 seconden (htdemucs default) naar 90 seconden gaat (htdemucs_ft), telt de extra compute minder zwaar mee voor de factuur dan je zou verwachten, omdat de per-call overhead het grootste deel van het budget al opslokt.

De praktische implicatie: als je toch al op het htdemucs-platform zit, is er vrijwel geen economische reden om niet de hoogste-kwaliteit variant te gebruiken die je latency-budget toelaat. Wachten je gebruikers 60 seconden, gebruik dan htdemucs_6s (6 stems, default snelheid). Wachten ze 2 minuten, gebruik dan htdemucs_ft (fine-tuned, op de meeste stems bijna BS-RoFormer-kwaliteit). De factuur is hetzelfde.

Dit is precies tegenovergesteld aan de conclusie die je zou trekken door academische papers en de gepubliceerde GPU-pricing van Replicate te lezen. Het wordt pas zichtbaar wanneer je daadwerkelijk aan het einde van de maand naar je factuur kijkt.

Implicaties voor unit economics

Modelleer je unit economics voor een stem separator-product, reken dan op $0,04–$0,05 per song als ondergrens, ongeacht welke Demucs-variant je kiest. Dat zet:

Plafond voor je free tier — bij 10 gratis minuten per gebruiker (≈3 gratis songs) absorbeer je ongeveer $0,13 per signup voordat er ook maar één conversie is
Minimum levensvatbare credit pack pricing — alles onder ~$0,10/song retail laat geen marge over voor Stripe fees, support en infra-overhead
Bulk processing kosten — bij 10.000 songs/maand kijk je naar ~$450 aan pure inference, vóór storage, bandbreedte en andere infra

Twee belangrijke kanttekeningen:

Cold starts domineren bij weinig verkeer. Verwerkt je service minder dan een paar honderd songs per dag, dan wordt de cold-start overhead proportioneel groter. Bij heel laag verkeer kunnen de daadwerkelijke kosten oplopen tot $0,06–$0,07 per song.
Self-hosting wint pas vanaf ~$2k/maand aan inference-uitgaven. Totdat je genoeg sustained traffic hebt om een dedicated GPU >40% bezet te houden, is serverless GPU goedkoper dan RunPod, Vast.ai of je eigen colo. We hebben dit direct gemeten — Replicate bleef tijdens onze launch-periode goedkoper dan dedicated infrastructuur.

4. Output flexibiliteit (aantal stems en formaat)

Model	Beschikbare stem-configuraties	Opmerkingen
Spleeter	2, 4 of 5 stems	5-stem voegt piano toe (apart model)
htdemucs	4 of 6 stems	`htdemucs_6s` voegt gitaar + piano toe
BS-RoFormer	4 stems (meestal); enkele 6-stem community builds	Kwaliteit zakt op de zeldzamere gitaar/piano stems

Hier staat htdemucs_6s echt alleen. Vereist je use case geïsoleerde gitaar- of piano-stems (muziekonderwijs, multi-track remixen, transcriptie), dan is htdemucs_6s het enige breed uitgerolde model dat ze op productiekwaliteit levert. BS-RoFormer 6-stem varianten bestaan in de community, maar zijn minder volwassen; de canonieke BS-RoFormer is een 4-stem systeem.

Voor "alleen vocalen" of "alleen instrumentaal" use cases (de karaoke-crowd) werken alle drie de modellen prima en kies je op snelheid, niet op kwaliteit. Spleeter op 90× real-time geeft je in milliseconden een bruikbare instrumentaal.

5. Wanneer kies je welk model

Na maanden van productie-ervaring met deze modellen, dit is de simpele decision tree die we iemand zouden geven die from scratch begint:

Kies Spleeter wanneer:

Je audio in real-time of bijna real-time moet verwerken
Je op CPU of beperkte hardware draait
Je batch-processing throughput nodig hebt (bijv. feature extraction over een muziekcatalogus)
De kwaliteitslat "bruikbaar" is, niet "goed"

Kies htdemucs wanneer:

Je een consumentenproduct bouwt waar gebruikers <60 seconden wachten
Je 6 stems nodig hebt (gebruik htdemucs_6s)
Je de beste kwaliteit-per-dollar verhouding in productie wilt
Je geen custom inference code wilt onderhouden (het wordt goed ondersteund op elk groot model-serving platform)

Kies BS-RoFormer wanneer:

Je offline of batch jobs draait waar 1–2 minuten per song prima is
Bas-kwaliteit specifiek belangrijk is (DJ-tools, transcriptie, audio-analyse)
Je release-kwaliteit werk maakt en de marginale SDR uitmaakt
Je bereid bent engineering-tijd te investeren om bij te blijven met community model releases

Kies geen van deze wanneer:

Je alleen vocal removal nodig hebt voor karaoke. Gebruik Spleeter 2-stem; het kwaliteitsverschil maakt niet uit voor meezing-audio die toch over een microfoon wordt afgespeeld.
Je real-time stem separator nodig hebt in een DJ-applicatie. Geen van deze draait real-time op consumer hardware. Gebruik een DAW met ingebouwde real-time scheiding (Ableton 12, etc.) of pre-process tracks offline.

Hoe ziet dit er in de praktijk uit

We draaien htdemucs_6s in productie op aistemsplitter.org — een gehoste versie van 6-stem scheiding gericht op mensen die niet de lokale toolchain willen opzetten (wat, tussen PyTorch-versies, CUDA-versies en audio dependency hell, de meeste mensen een hele middag kost).

Een paar dingen die we leerden en die niet in de papers staan:

De echte productiekosten zijn ruwweg 2× wat naïeve berekeningen suggereren, en ruwweg vlak over de Demucs-varianten heen. Publieke GPU-pricing × inference tijd geeft een getal dat platform-overhead negeert. Onze daadwerkelijke Replicate-factuur komt uit op ongeveer $0,045 per song — en het is hetzelfde getal of we nu htdemucs, htdemucs_6s of htdemucs_ft draaien. De vaste overhead per call overspoelt het marginale compute-verschil tussen modellen. Dit ene feit veranderde hoe we over modelkeuze nadenken: kies op kwaliteit, niet op theoretische compute-kosten, want het kostenverschil verschijnt in de praktijk niet op je factuur.
Formaatconversie telt zwaarder dan het model. htdemucs accepteert alleen WAV-input. Gebruikers uploaden MP3, FLAC, M4A, OGG en steeds vreemdere WebM containers. De pre-processing ffmpeg-laag goed krijgen op schaal is verre van triviaal.
YouTube/SoundCloud URL-ingest is de helft van de UX-winst. Gebruikers vragen een file te downloaden en daarna te uploaden kost je ~40% van ze. Directe URL-ingest via yt-dlp is fiddly om te onderhouden (age-restricted videos, region locks, livestreams) maar is het waard.
De 6-stem case is waar gebruikers de magie zien. Wanneer iemand voor het eerst gitaar geïsoleerd hoort van piano op hun favoriete song, vertellen ze het hun vrienden. De 4-stem case is "leuk"; de 6-stem case is "wacht, hoe kan dit".

Wil je horen hoe 6-stem htdemucs op echte audio klinkt zonder de toolchain op te zetten — onze site geeft gratis credits om een paar songs te proberen.

Wat is er volgend in dit veld

Een paar open vragen om in 2026 in de gaten te houden:

Wordt 8-stem (vocalen/backing-vocalen/drums/bas/gitaar/piano/synth/other) standaard? Community fine-tunes bewegen die kant op, maar trainingsdata voor losse synth- en backing-vocal stems is de bottleneck.
Real-time op consumer hardware? Geen enkel huidig open model draait op real-time snelheid op een CPU bij acceptabele kwaliteit. Dit gaat veranderen met model distillation, maar waarschijnlijk niet in 2026.
Meertalige / niet-Westerse vocal scheiding. De meeste gepubliceerde benchmarks worden gedomineerd door Engelstalige pop en rock. We zien merkbaar lagere prestaties op talen met andere zangtechnieken (Mandarijn, Cantopop met zware auto-tune, Bollywood vocal stacks). Dit is een echt gat in het veld, geen modeldeployment-issue.

Werk je in dit veld en heb je data die we interessant zouden vinden — of ben je iets tegengekomen op deze modellen dat wij niet zagen — stuur ons een berichtje.

Referenties

htdemucs — Rouard, S., Massa, F., Défossez, A. Hybrid Transformers for Music Source Separation. arXiv:2211.08553
Demucs v4 (hybrid) — Défossez, A. Hybrid Spectrogram and Waveform Source Separation. arXiv:2111.03600
BS-RoFormer — Lu, W.-T., Wang, J.-C., et al. Music Source Separation with Band-Split RoPE Transformer. SDX23 Challenge results
Spleeter — Hennequin, R., Khlif, A., Voituret, F., Moussallam, M. Spleeter: a fast and efficient music source separation tool with pre-trained models. JOSS 2020
MUSDB18 dataset — Rafii, Z., Liutkus, A., Stöter, F.-R., Mimilakis, S. I., Bittner, R. The MUSDB18 corpus for music separation. Zenodo
Sound Demixing Challenge 2023 — Mitsufuji et al., SDX23 results
MVSep model leaderboard — mvsep.com/en/algorithms

Laatst bijgewerkt: april 2026. Vind je een fout in de data, de SDR-cijfers of een van de praktische claims, stuur ons een correctie en we werken het artikel bij met vermelding.