htdemucs vs. BS-RoFormer vs. Spleeter: Audio-Quellentrennung im Benchmark 2026

Wer sich in den letzten zwölf Monaten mit KI-basierter Musik-Quellentrennung beschäftigt hat, ist mit ziemlicher Sicherheit über dieselben drei Namen gestolpert: Spleeter, htdemucs (Hybrid Transformer Demucs) und BS-RoFormer. Sie tauchen in jedem Vergleichsartikel, jedem Forschungspapier und jedem „So entfernst du Vocals"-Tutorial auf — aber die Art, wie sie verglichen werden, ist meistens falsch. Die meisten Beiträge zitieren eine einzige SDR-Zahl aus einem Paper von 2019 und sind damit fertig.

Das hilft niemandem, der ein Produkt ausliefern, eine Pipeline bauen oder ein Modell für echtes Audio auswählen will.

Dieser Beitrag vergleicht die drei Modelle entlang der Dimensionen, die beim produktiven Einsatz von Audio-Quellentrennung wirklich zählen:

Qualität — SDR-Werte aus peer-reviewten Quellen, kein Bauchgefühl
Inferenz-Geschwindigkeit — worauf du in Produktion tatsächlich wartest
Kosten pro Song — auf handelsüblichen GPUs zu Preisen von 2026
Output-Flexibilität — 2 Stems vs. 4 Stems vs. 6 Stems
Wann welches Modell die richtige Wahl ist — und wann nicht

Alles weiter unten basiert auf veröffentlichten Benchmarks plus unserem eigenen produktiven Einsatz von htdemucs im großen Maßstab. Wo wir Zahlen zitieren, nennen wir die Quelle.

TL;DR (für Leser, die jetzt sofort die Antwort wollen)

Modell	Am besten geeignet für	Output-Stems	Qualität (Ø SDR)	Geschwindigkeit
Spleeter	Echtzeit, ressourcenarm, Batch-Verarbeitung	2, 4 oder 5	~5,9 dB (Vocals)	~100× Echtzeit auf GPU
htdemucs	Produktive C2C-Apps, Balance aus Qualität und Tempo	4 oder 6	~9,0 dB (Ø)	~5–8× Echtzeit auf A40
BS-RoFormer	Höchste Klangqualität für Offline-Workflows, Mastering, Archiv	4 (typisch)	~9,80 dB (Ø)	~2–3× Echtzeit auf A40

Wenn du nur eine Sache aus diesem Beitrag mitnimmst: htdemucs ist der richtige Default für fast jedes Produkt, und du solltest wahrscheinlich htdemucs_ft statt des Standard-Checkpoints fahren. Bei der Serverless-Abrechnung von Replicate kosten alle drei Demucs-Varianten (default, 6s, ft) pro Aufruf praktisch gleich viel — aber ft liefert spürbar bessere Trennung. Damit haben wir am Anfang nicht gerechnet; klar wurde es erst, als wir uns die tatsächliche Abrechnung angeschaut haben.

BS-RoFormer ist nur beim Bass deutlich besser und auch nur dann, wenn Latenz keine Rolle spielt. Spleeter ist ein Modell von 2019 auf Hardware von 2026 — schnell, aber der Qualitätsabstand ist mittlerweile hörbar.

Der Rest dieses Beitrags erklärt, warum.

Was wir mit „Qualität" meinen — SDR kurz erklärt

Die Qualität von Music Source Separation wird üblicherweise über die Signal-to-Distortion Ratio (SDR) in Dezibel gemessen. Höher ist besser. Der Referenz-Datensatz ist MUSDB18 (oder MUSDB18-HQ für hochauflösendes Audio); er enthält 150 Tracks in voller Länge mit isolierten Stems für Vocals, Drums, Bass und „Other".

Ein paar praktische Anker:

<6 dB SDR: deutlich hörbare Artefakte, „phasige" Vocals, hörbares Übersprechen zwischen den Stems
6–8 dB SDR: brauchbar für lockere Anwendungen (Karaoke, Songs lernen, Ideen skizzieren)
8–10 dB SDR: sauber genug für Content-Produktion und die meisten DJ-Anwendungen
>10 dB SDR: für den Durchschnittshörer praktisch transparent; nach leichtem Cleanup Release-tauglich

Alles oberhalb von ~9 dB bei Vocals liegt in dem Bereich, in dem die meisten Hörer im Blindtest keinen Unterschied mehr feststellen. Was darüber hinaus kommt, dreht sich um Edge Cases — starker Hall, doppelte Vocals, komplexe Mixes.

Eine Anmerkung zu SI-SDR: Manche neueren Papers berichten SI-SDR (scale-invariant SDR), das einfache Pegelunterschiede herausrechnet und robuster ist. Wenn Zahlen in diesem Beitrag von anderen Quellen abweichen, liegt das meistens an der Definition der Metrik.

Die drei Modelle, kurz vorgestellt

Spleeter (Deezer, 2019)

2019 vom Forschungsteam bei Deezer veröffentlicht, ist Spleeter eine U-Net-Architektur, die im Spektrogramm-Bereich arbeitet. Es kommt in 2-Stem- (Vocals/Begleitung), 4-Stem- (Vocals/Drums/Bass/Other) und 5-Stem-Konfigurationen (zusätzlich Klavier).

Damals war das ein Meilenstein — zum ersten Mal konnte jeder ohne Lizenzgebühren brauchbare Quellentrennung auf einer Laptop-CPU laufen lassen. Sechs Jahre später wurde es qualitativ von jedem modernen Modell überholt, bleibt aber mit großem Abstand die schnellste und leichtgewichtigste Option.

htdemucs (Meta AI, 2022)

Das Demucs-Modell der vierten Generation aus dem Forschungsteam von Meta AI. Anders als Spleeter ist htdemucs ein hybrides Modell — es arbeitet sowohl im Zeitbereich (Wellenform) als auch im Frequenzbereich (Spektrogramm), mit einem Transformer-Backbone, der beide verbindet. Das Original-Paper berichtet eine SDR-Verbesserung von 1,4 dB gegenüber der vorherigen Demucs-Generation auf MUSDB-HQ.

In der Praxis sind zwei Varianten relevant:

htdemucs — das Standard-4-Stem-Modell
htdemucs_6s — eine 6-Stem-Variante, die isolierte Gitarren- und Klavier-Stems hinzufügt

Daneben gibt es htdemucs_ft, eine fine-tuned Version, die langsamer, aber bei einzelnen Stems leicht genauer ist.

htdemucs hat in der Sony Music Demixing Challenge 2021 konkurrenzfähig abgeschnitten und ist nach wie vor der Default für die meisten produktiven Pipelines, die nicht zwingend SOTA jagen.

BS-RoFormer (2023)

Aktueller State of the Art auf MUSDB18-HQ: BS-RoFormer (Band-Split RoPE Transformer) ist eine reine Transformer-Architektur, die RNN-Module durch einen hierarchischen RoPE Transformer ersetzt. Es zerlegt das Eingangs-Spektrogramm in mehrere nicht überlappende Frequenz-Subbänder und nutzt aus, dass verschiedene Instrumente charakteristische Frequenzbereiche belegen (Bass tief, Cymbals hoch usw.).

BS-RoFormer, trainiert auf MUSDB18-HQ plus 500 zusätzliche Songs, belegte den ersten Platz im Music Source Separation Track der Sound Demixing Challenge 2023 (SDX23). Auch die kleinere Version, ohne zusätzliche Daten trainiert, erreicht laut Bericht 9,80 dB durchschnittliche SDR auf MUSDB18-HQ.

Der Haken: Es ist langsamer und speicherhungriger als htdemucs, und produktionsreife offene Gewichte sind nach wie vor über mehrere Community-Implementierungen verteilt statt als ein kanonischer Release verfügbar.

1. Qualitäts-Benchmark (veröffentlichte SDR-Werte)

Hier fallen die meisten Vergleichsbeiträge auseinander — sie picken sich eine einzige Zahl heraus. Hier sind die SDR-Werte pro Stem aus der veröffentlichten Literatur, auf MUSDB18-HQ (ohne zusätzliche Trainingsdaten, sofern nicht anders angegeben):

Modell	Vocals	Drums	Bass	Other	Durchschnitt
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 (ohne Zusatzdaten)	—	—	~11,28 dB	—	~9,80 dB
BS-RoFormer (mit 500 Zusatzsongs)	—	—	—	—	~9,76 dB+

Quellen: Spleeter-Werte aus dem Spleeter JOSS Paper und dem BeatsToRapOn Separation Benchmark. htdemucs-Werte aus Hybrid Spectrogram and Waveform Source Separation und Benchmarks and leaderboards for sound demixing tasks. BS-RoFormer-Werte aus den SDX23-Ergebnissen, dokumentiert im selben Paper.

Ein paar Beobachtungen aus der Tabelle:

Der Sprung Spleeter → htdemucs ist größer als der Sprung htdemucs → BS-RoFormer. Von Spleeter zu htdemucs gewinnst du im Durchschnitt rund +2,3 dB. Von htdemucs zu BS-RoFormer rund +1,3 dB. Genau deshalb ist htdemucs für die meisten Anwendungsfälle der praktische Sweet Spot.

Der größte Vorsprung von BS-RoFormer liegt beim Bass. Die Bass-Trennung springt von ~8,6 dB (htdemucs) auf ~11,28 dB (BS-RoFormer) — ein Unterschied, den man im Blindtest hört. Die Gewinne bei Vocals und Drums sind kleiner. Wer etwas baut, das speziell sauberen Bass braucht (DJ-Tools, Transkription, Musikausbildung für Bassisten), für den ist der Mehraufwand an Compute bei BS-RoFormer gerechtfertigt. Für alles andere liegt der Gewinn an der Wahrnehmungsschwelle.

htdemucs_ft wird unterschätzt. Viele Vergleichsartikel testen nur den Standard-Checkpoint htdemucs. Die fine-tuned Version (htdemucs_ft) schließt den größten Teil des Abstands zu BS-RoFormer — zum Preis von rund 4× Inferenzzeit, in der Praxis aber immer noch schneller als BS-RoFormer.

2. Inferenz-Geschwindigkeit (real, nicht theoretisch)

Ungefähre End-to-End-Zeit für einen 3-minütigen Song auf einer einzelnen A40-GPU, gemessen vom API-Aufruf bis zum download-fertigen Output:

Modell	End-to-End-Zeit	Echtzeit-Multiplikator
Spleeter (4-Stem, GPU)	~2–5 Sekunden	~40–90× Echtzeit
htdemucs (default, 4-Stem)	~30–45 Sekunden	~4–6× Echtzeit
htdemucs_6s (6-Stem)	~40–60 Sekunden	~3–5× Echtzeit
htdemucs_ft (fine-tuned)	~90–150 Sekunden	~1,2–2× Echtzeit
BS-RoFormer	~60–120 Sekunden	~1,5–3× Echtzeit

Anmerkungen:

End-to-End-Zeit ≠ reine GPU-Inferenzzeit. Öffentliche Benchmarks berichten meist nur den Forward-Pass des Modells auf sauberen Inputs. Echte Produktionszeit umfasst Container-Cold-Start (5–30 s bei Serverless), Audio-I/O (Datei-Download, ffmpeg-Vorverarbeitung) und Result-Upload. Unsere Zahlen oben sind End-to-End auf Replicate.
Spleeter spielt geschwindigkeitsmäßig in einer eigenen Liga. Es ist das einzige Modell, das auf reiner CPU komfortabel schneller als Echtzeit läuft.
Der overlap-Parameter von htdemucs ist ein großer Geschwindigkeitshebel. Der Default overlap=0.25 ist ein vernünftiger Kompromiss; overlap=0.5 verbessert die Qualität leicht bei ~2× Kosten; overlap=0 macht es spürbar schneller, führt aber zu hörbaren Chunking-Artefakten an den Segmentgrenzen.
Die Referenz-Implementierungen von BS-RoFormer schwanken in der Geschwindigkeit stark — abhängig davon, wessen Checkpoint und Inferenz-Code du verwendest. Die Zahlen oben beziehen sich auf den in der Community beliebten MVSep BS-RoFormer SW-Build.

Wenn du ein Consumer-Produkt baust, in dem Nutzer auf Ergebnisse warten, fängt nach unserer Erfahrung alles ab ~60 Sekunden für einen 3-minütigen Song an, der Conversion zu schaden. Damit bleiben htdemucs (default und 6s) im akzeptablen Bereich, während htdemucs_ft und BS-RoFormer eher in asynchrone/queue-basierte Flows rutschen, bei denen Nutzer später wiederkommen.

3. Kosten pro Song (Ökonomie eines produktiven Deployments)

Das ist der Abschnitt, in dem die meisten Online-Vergleiche komplett danebenliegen. Die öffentliche Preisgestaltung auf Replicate sieht simpel aus — A40 zu $0.000725/Sekunde, mit der Inferenzzeit multiplizieren, fertig. In der Praxis liegt diese Rechnung um etwa Faktor 2 daneben gegenüber deiner echten Rechnung — und es gibt einen interessanteren Twist, den fast kein Vergleichsbeitrag erwähnt.

Das wichtigste Ergebnis aus unserem produktiven Deployment

Wir betreiben htdemucs seit mehreren Monaten produktiv auf aistemsplitter.org, und zwar über alle drei Demucs-Varianten — htdemucs (default 4-Stem), htdemucs_6s (6-Stem) und htdemucs_ft (fine-tuned). Auf den A40-GPU-Instanzen von Replicate kosten alle drei Varianten in unserer tatsächlichen Abrechnung pro Aufruf etwa gleich viel: rund 22 Aufrufe pro $1, also etwa $0.045 pro Song.

Das ist einen kurzen Stopp wert, weil es dem widerspricht, was man aus den veröffentlichten Inferenzzeiten erwarten würde.

Modell	Naive Kosten (öffentl. Preis × Inferenzzeit)	Unsere tatsächlich gemessenen 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 (variiert)

Warum alle drei Demucs-Varianten zu denselben Kosten konvergieren

Das naive Preismodell unterstellt, dass du nur für reine GPU-Inferenzzeit zahlst. Tatsächlich umfasst jeder Replicate-Aufruf zusätzlich:

Container-Cold-Start-Zeit (5–30 Sekunden beim Hochskalieren von null)
Laden der Modellgewichte in den GPU-Speicher
Audio-Datei-Download und ffmpeg-Vorverarbeitung
Result-Encoding und Upload zurück in den Storage
Eine minimale abrechenbare Dauer pro Aufruf

Diese Overheads sind in etwa Fixkosten pro Aufruf — sie skalieren nicht damit, wie komplex dein Modell ist. Wenn der GPU-Forward-Pass von 30 Sekunden (htdemucs default) auf 90 Sekunden (htdemucs_ft) wächst, fällt die zusätzliche Compute-Zeit weniger ins Gewicht als gedacht, weil der Per-Call-Overhead bereits den größten Teil des Budgets auffrisst.

Die praktische Konsequenz: Wer ohnehin schon auf der htdemucs-Plattform ist, hat fast keinen ökonomischen Grund, nicht die hochwertigste Variante zu nehmen, die das Latenz-Budget erlaubt. Wenn deine Nutzer 60 Sekunden warten, nimm htdemucs_6s (6 Stems, default-Tempo). Wenn sie 2 Minuten warten, nimm htdemucs_ft (fine-tuned, bei den meisten Stems nahe an BS-RoFormer-Qualität). Die Rechnung bleibt gleich.

Das ist das Gegenteil der Schlussfolgerung, zu der man kommt, wenn man akademische Papers und die ausgeschriebenen GPU-Preise von Replicate liest. Es zeigt sich erst, wenn man am Monatsende tatsächlich auf seine Rechnung schaut.

Konsequenzen für die Unit Economics

Wer Unit Economics für ein Stem-Separation-Produkt modelliert, sollte mit $0.04–$0.05 pro Song als Boden planen, unabhängig davon, welche Demucs-Variante er wählt. Das setzt:

Free-Tier-Obergrenze — bei 10 Gratis-Minuten pro Nutzer (≈3 kostenlose Songs) absorbierst du rund $0.13 pro Anmeldung, bevor überhaupt eine Conversion stattfindet
Minimal sinnvoller Credit-Pack-Preis — alles unter ~$0.10/Song im Verkaufspreis lässt keine Marge für Stripe-Gebühren, Support und Infrastruktur-Overhead
Bulk-Verarbeitungskosten — bei 10.000 Songs/Monat liegst du bei ~$450 reiner Inferenz, vor Storage, Bandbreite und sonstiger Infrastruktur

Zwei wichtige Einschränkungen:

Cold Starts dominieren bei niedrigem Traffic. Wenn dein Service weniger als ein paar hundert Songs pro Tag verarbeitet, wird der Cold-Start-Overhead proportional größer. Bei sehr niedrigem Traffic können die echten Kosten in Richtung $0.06–$0.07 pro Song wandern.
Self-Hosting schlägt das erst oberhalb von ~$2k/Monat an Inferenzausgaben. Solange du nicht genug Dauerlast hast, um eine dedizierte GPU zu >40 % auszulasten, ist Serverless-GPU billiger als RunPod, Vast.ai oder eine eigene Colocation. Wir haben das direkt gemessen — Replicate war während unserer gesamten Launch-Phase günstiger als dedizierte Infrastruktur.

4. Output-Flexibilität (Stem-Anzahl und Format)

Modell	Verfügbare Stem-Konfigurationen	Anmerkungen
Spleeter	2, 4 oder 5 Stems	5-Stem fügt Klavier hinzu (separates Modell)
htdemucs	4 oder 6 Stems	`htdemucs_6s` ergänzt Gitarre + Klavier
BS-RoFormer	4 Stems (überwiegend); einige 6-Stem-Community-Builds	Qualität sinkt bei den selteneren Gitarren-/Klavier-Stems

Hier steht htdemucs_6s wirklich allein. Wenn dein Use Case isolierte Gitarren- oder Klavier-Stems erfordert (Musikausbildung, Multitrack-Remixing, Transkription), ist htdemucs_6s das einzige weit verbreitete Modell, das diese in produktiver Qualität liefert. BS-RoFormer-6-Stem-Varianten existieren in der Community, sind aber weniger ausgereift; das kanonische BS-RoFormer ist ein 4-Stem-System.

Für „nur Vocals" oder „nur Instrumental" (das Karaoke-Lager) funktionieren alle drei Modelle gut, und du solltest nach Geschwindigkeit auswählen, nicht nach Qualität. Spleeter mit 90× Echtzeit liefert dir ein brauchbares Instrumental in Millisekunden.

5. Wann welches Modell

Nachdem wir diese Modelle mehrere Monate produktiv betrieben haben, hier der einfache Entscheidungsbaum, den wir jemandem geben würden, der bei null anfängt:

Spleeter, wenn:

Du Audio in Echtzeit oder Quasi-Echtzeit verarbeiten musst
Du auf CPU oder eingeschränkter Hardware läufst
Du Batch-Durchsatz brauchst (z. B. Feature-Extraktion über einen Musikkatalog)
Die Qualitätshürde „brauchbar" ist, nicht „gut"

htdemucs, wenn:

Du ein Consumer-Produkt baust, in dem Nutzer <60 Sekunden warten
Du 6 Stems brauchst (verwende htdemucs_6s)
Du das beste Qualitäts-pro-Dollar-Verhältnis in Produktion willst
Du keinen eigenen Inferenz-Code pflegen willst (es ist auf jeder größeren Model-Serving-Plattform gut unterstützt)

BS-RoFormer, wenn:

Du Offline- oder Batch-Jobs fährst, bei denen 1–2 Minuten pro Song okay sind
Speziell die Bass-Qualität wichtig ist (DJ-Tools, Transkription, Audio-Analyse)
Du Release-taugliche Arbeit produzierst und das marginale SDR zählt
Du bereit bist, Engineering-Zeit dafür zu investieren, mit Community-Releases Schritt zu halten

Keines davon, wenn:

Du nur Vocal Removal für Karaoke brauchst. Nimm Spleeter 2-Stem; der Qualitätsunterschied spielt für Mitsing-Audio, das über ein Mikrofon abgespielt wird, keine Rolle.
Du Echtzeit-Stem-Separation in einer DJ-Anwendung brauchst. Keines davon ist auf Consumer-Hardware echtzeitfähig. Nimm eine DAW mit eingebauter Echtzeit-Trennung (Ableton 12 etc.) oder verarbeite Tracks vorab offline.

Wie das in der Praxis aussieht

Wir betreiben htdemucs_6s produktiv auf aistemsplitter.org — eine gehostete Variante der 6-Stem-Trennung, gedacht für Leute, die sich die lokale Toolchain nicht einrichten wollen (was zwischen PyTorch-Versionen, CUDA-Versionen und Audio-Dependency-Hölle bei den meisten einen halben Tag verschlingt).

Ein paar Dinge, die wir gelernt haben und die nicht in den Papers stehen:

Echte Produktionskosten liegen rund 2× über naiven Berechnungen — und sind über die Demucs-Varianten hinweg ungefähr flach. Öffentlicher GPU-Preis × Inferenzzeit liefert eine Zahl, die den Plattform-Overhead ignoriert. Unsere tatsächliche Replicate-Rechnung läuft auf etwa $0.045 pro Song hinaus — und die Zahl ist dieselbe, egal ob wir htdemucs, htdemucs_6s oder htdemucs_ft fahren. Der fixe Overhead pro Aufruf erschlägt den marginalen Compute-Unterschied zwischen den Modellen. Diese eine Tatsache hat unsere Sicht auf die Modellauswahl verändert: Wähle nach Qualität, nicht nach theoretischen Compute-Kosten — denn der Kostenunterschied taucht auf der Rechnung schlicht nicht auf.
Format-Konvertierung ist wichtiger als das Modell. htdemucs akzeptiert nur WAV-Input. Nutzer laden MP3, FLAC, M4A, OGG und immer abenteuerlichere WebM-Container hoch. Die ffmpeg-Vorverarbeitungs-Schicht im großen Maßstab sauber hinzubekommen, ist nicht trivial.
YouTube-/SoundCloud-URL-Ingestion ist der halbe UX-Gewinn. Nutzer aufzufordern, eine Datei runterzuladen und wieder hochzuladen, kostet ~40 % von ihnen. Direkte URL-Ingestion via yt-dlp ist mühsam zu pflegen (altersbeschränkte Videos, Region-Locks, Livestreams), aber es lohnt sich.
Beim 6-Stem-Fall sehen Nutzer die Magie. Wenn jemand zum ersten Mal Gitarre isoliert von Klavier in seinem Lieblingssong hört, erzählt er es seinen Freunden. Der 4-Stem-Fall ist „cool"; der 6-Stem-Fall ist „warte, wie ist das überhaupt möglich".

Wer hören will, wie 6-Stem htdemucs auf echtem Audio klingt, ohne sich die Toolchain einzurichten: Auf unserer Seite gibt es Gratis-Credits, um ein paar Songs auszuprobieren.

Was als Nächstes in diesem Bereich kommt

Ein paar offene Fragen, die 2026 beobachtenswert sind:

Wird 8-Stem (Vocals/Backing-Vocals/Drums/Bass/Gitarre/Klavier/Synth/Other) zum Standard? Community-Fine-Tunes bewegen sich in diese Richtung, aber Trainingsdaten für einzelne Synth- und Backing-Vocal-Stems sind der Engpass.
Echtzeit auf Consumer-Hardware? Kein aktuelles offenes Modell läuft auf einer CPU mit akzeptabler Qualität in Echtzeit. Das wird sich mit Modell-Distillation ändern, aber wahrscheinlich nicht 2026.
Mehrsprachige / nicht-westliche Vocal-Trennung. Die meisten veröffentlichten Benchmarks werden von englischsprachigem Pop und Rock dominiert. Wir sehen spürbar schlechtere Performance bei Sprachen mit anderen Gesangstechniken (Mandarin, Cantopop mit starkem Auto-Tune, Bollywood-Vocal-Stacks). Das ist eine echte Lücke im Feld, kein Modell-Deployment-Problem.

Wer in diesem Bereich arbeitet und Daten hat, die uns interessieren — oder bei diesen Modellen auf etwas gestoßen ist, das wir nicht haben — meldet euch bei uns.

Referenzen

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 Datensatz — 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-Ergebnisse
MVSep Modell-Leaderboard — mvsep.com/en/algorithms

Stand: April 2026. Wenn ihr einen Fehler in den Daten, den SDR-Zahlen oder einer der praktischen Aussagen findet, schickt uns eine Korrektur, und wir aktualisieren den Beitrag mit Quellenangabe.