Demucs 4 (+ Colab) (4, 6 stem)
4 stem, SDR 9 for vocals on MUSDB HQ test, and SDR 9 for mixdowned instrumentals (5, 6 stem - experimental piano [bad] and guitar)
https://github.com/facebookresearch/demucs (all these models available in UVR 5 GUI or MVSEP [just x-minus doesn’t have ft model for at least free users, it was mmi model at some point, but then got replace by MDX-B which “ turned out to be not only higher quality, but also faster”])
Google Colab (all 4-6 stem models available, 16-32 bit output)
https://colab.research.google.com/drive/117SWWC0k9N2MBj7biagHjkRZpmd_ozu1
or Colab with upload script without Google Drive necessity:
https://colab.research.google.com/drive/1dC9nVxk3V_VPjUADsnFu8EiT-xnU1tGH?usp=sharing
or Colab by Bezio with batch processing, (only mp3 output and no overlap/shifts parameters beside model choice - choose demucs_ft for 4 stems):
https://colab.research.google.com/drive/15IscSKj8u6OrooR-B5GHxIvKE5YXyG_5?usp=sharing
or Colab with batch processing by jarredou (less friendly GUI, but should be usable too, lossless):
https://colab.research.google.com/drive/1KTkiBI21-07JTYcTdhlj_muSh_p7dP1d?usp=sharing
or UVR | MVSep.com | uvronline.app
"I'd recommend using the “htdemucs_ft” model over normal “htdemucs” since IMHO it's a bit better", also SDR measurements confirm that. 6s might have more vocal residues than both, but will be a good choice in some cases (possibly songs with guitar).
All the best stock models:
- htdemucs_ft (f7e0c4bc-ba3fe64a.th, d12395a8-e57c48e6.th, 92cfc3b6-ef3bcb9c.th, 04573f0d-f3cf25b2.th [drums, bass, other, vocals])
“fine-tuned version of htdemucs, separation will take 4 times more time but might be a bit better. Same training set as htdemucs”.
Can be obtained with UVR5 in download center (04573f0d-f3cf25b2.th, 04573f0d-f3cf25b2.th, d12395a8-e57c48e6.th, f7e0c4bc-ba3fe64a.th; not in order)
- htdemucs - “first version of Hybrid Transformer Demucs. Trained on MusDB + 800 songs.”
Default Demucs model in e.g. UVR5 (955717e8-8726e21a.th)
- htdemucs_mmi = Hybrid Demucs v3, retrained on MusDB + 800 songs
htdemucs_6s = 6 sources version of htdemucs, with piano and guitar being added as sources. Note that the piano source is not working great at the moment.”
“nowhere near Logic Pro” from May 2025 update.
- mdx_extra: The best Demucs 3 model from MDX 2021 challenge. Trained with extra training data (including MusDB test set), ranked 2nd on the track B of the MDX 2021 challenge.
- mdx_extra_q: a bit worse quantized version of the above (a bit faster)
Be aware that also UVR team and also ZFTurbo [available on MVSEP and GitHub] trained their own Demucs models (respectively instrumental and vocal ones), but there are some issues with ZFTurbo model using inference other than provided on his GitHub (so it’s so far not compatible with e.g. UVR giving “KeyError: "'models'" for ckpt Demucs models insteat of th).
To use the best Demucs 4 model in the official Colab (the 2nd link) rename model to e.g. “htdemucs_ft”. It can behave better than 6 stems if you don’t need extra stems.
In other cases, extra stems will sound better in the mix, although using 6s model, vocal residues are usually louder than in ft model (but that might depend on a song or genre).
Despite the fact that 6s is an electric guitar model, it can also pick up acoustic guitar very well in some songs.
The problem with 6s models is that “when a song has a piano because not only the piano model is not the best, but it also makes the sound itself worse
rather than just very filtered piano, it sounds like distorted filtered piano”
Sometime Gsep can be “still better because each stem has its dedicated model" but it depends on a song (other stem in GSep can be better more frequently, but now MDX23 jarredou fork or Ensemble models on MVSEP returns good other stems as well)
Gsep instead of inverting the whole result among stems like Demucs, won’t preserve all the instruments occasionally.
"htdemucs (demucs 4) comes a bit closer [vs Gsep], most of the time the bass is better and there are few instances where demucs picks up drums better"
“From my experience and testing: If you decide to process an isolated track through Demucs, it has no trouble identifying what is bass guitar and what isn't bass guitar [does not matter if it's finger/pick/slap, it works on all of them for me, except distorted wah-wah bass]. The leftover noise [the part's that demucs did not pick up, and left it in the (No Bass) stem] is usually lower than minus 40 - 45 DB, and it's either noise, or hisses usually.
The problem comes when there are instruments besides the bass guitar that are playing beside it [a.k.a. music], since these are separation models, not identification models. It starts having trouble grabbing all the upper harmonics [which is the multiple of the root note frequency], and the transients, potentially starts mis-detecting, or in extreme cases, it does not pick up the bass at all.”
“When used with "--shifts" > 0, demucs gives slightly different results each time you use it, that can also explain some little score differences”
https://github.com/facebookresearch/demucs/issues/381#issuecomment-1262848601
Initially, Shifts 10 was considered as max, but it turned out 20 can be used.
Overlap 0.75 is max before it gets very slow (and 0.95 when it becomes overkill).
While we also thought overlap 0.99 is max, it turned out you can use 0.99999 in UVR, and 0.999999 in CLI mode, but both make separations tremendously long, even 0.999 much longer than 0.99.
On GTX 1080 Ti on 1 minute song:
`0.99` = Time Elapsed: `00:09:45`
`0.999` = Time Elapsed: `01:36:45`
Also, shifts can be set to 0.
With htdemucs_ft, shifts doesn't matter nearly as much as overlap, I recommend keeping (shifts) at 2 [for weaker GPUs].
The drum SDR with 1 and 10 shifts difference is about 0.005
So overlap impacts SDR a bit more than shifts.
“The best way to judge optimum settings is to take a 10-second sample of a vocal extraction where there's evident bleeding and just keep trying higher overlaps etc until you're happy, or you lose patience, then you'll arrive at what I call the 'Patience Ratio'. For me, it's 2x song length.”
Installation of only Demucs for Windows
Use UVR, or:
Download the git repo, extract it, then open PowerShell and write
"pip install *insert the directory of the extracted repo here*"
https://github.com/facebookresearch/demucs#egg=demucs
Alternatively, execute this command:
pip install git+https://github.com/facebookresearch/demucs#egg=demucs
or download the git repo first and then
"pip install *insert the directory of the extracted repo here*"
In case of “norm_first_ error run this line or update torch to 1.13.1
python.exe pip install -U torch torchaudio
In Colab, judging by quality of drums track, I prefer using overlap 0.1 (better only for instrumentals) with shifts 10 (actually can be set to even 20), but default set by the author is 0.25 and is better for sound of instrumental as a whole.
Also, we have overall better separation quality results using shifts=10, but it increases separation time (it's also reflected by MVSEP's SDR calculations). Overlaps also increase general separation quality for instrumentals/vocals, at least up to 0.75, but everything above starts being tremendously slow (few hours for 0.99 max setting).
If you use particularly high overlap like 0.96 for a full length song, you can run out of Colab time limit if it’s not your first file being processed during this session (for cases when processing takes more than 1 hour). If you exceed the limit, you can change Google account in the right top (don’t use other account during mounting, or you’ll end up with error). The limit is reset after 12 hours (maybe sooner). It’s capable of processing one file for two hours, at least only if it’s the first file being processed for a longer time during this day. Also, rarely, it can happen that your file is being processed faster than usual despite the same T4 GPU.
If you have “something has gone terribly wrong” error right on the separation start, simply retry. If in the end of long separation - ignore it, and don’t retry - your result is in the folder.
- *clipclamp* - uncheck it to disable hard limiter, but it may cause separation artifacts on some loud input files or will change volume proportions of the stems. I like it enabled somehow.
- Q: How to stop Demucs from rescaling the volume of stems after they're extracted (without adjusting the volume of the input mixture and passing --clip-mode=clamp)?
A: Set “”--clip-mode none argument coupled with export to --float32” (jarredou)
Demucs parameters explained by jarredou
- “Overlap is the percentage of the audio chunk that will be overlapped by the next audio chunk. So it's basically merging and averaging different audio chunk that have different start (& end) points.
For example, if audio chunk is `|---|` with overlap=0.5, each audio chunk will be half overlapped by next audio chunk:
```
|---|
|---|
|---| etc...
|---| (2nd audio chunk half overlapping previous one)
|---| (1st audio chunk)
```
-shifts is a random value between 0 and 0.5 seconds that will be used to pad the full audio track, changing its start(&end) point. When all "shifts" are processed, they are merged and average. (...)
It's to pad the full song with a silent of a random length between 0 and 0.5 sec. Each shift add a pass with a different random length of silence added before the song. When all shifts are done (and silences removed), the results are merged and averaged.
Shifts is performing lower than overlap because it is limited to that 0.5 seconds max value of shifting, when overlap is shifting progressively across the whole song. Both works because they are shifting the starting point of the separations. (Don't ask me why that works!)
But overlap with high values is kinda biased towards the end of the audio, it's caricatural here but first (chunk - overlap) will be 1 pass, 2nd (chunk - overlap) will be 2 passes, 3rd (chunk - overlap) will be 3 passes, etc…”
So Overlap has more impact on the results than shift.
“Side-note: Demucs overlap and MVSEP-MDX23 by ZFTurbo overlap features are not working in the same way. (...)
Demucs is kinda crossfading the chunks in their overlapping regions, while MVSep-MDX23 is doing avg/avg to mix them together”
Why is overlapping advantageous?
Because changing the starting point of the separation give slightly different results (I can't explain why!). The more you move the starting point, the more different the results are. That's why overlap performs better than shifts limited to 0-0.5sec range, like I said before.
Overlap in Demucs (and now UVR) is also crossfading overlapping chunks, that is probably also reducing the artifacts at audio chunks/segments boundaries.
[So technically, if you could load the entire track in at once, you wouldn't need overlap]
Shifts=10 vs 2 gives +0.2 SDR with overlap=0.25 (the setting they've used in their original paper), if you use higher value for overlap, the gain will be lower, as they both rely on the same "trick" to work.
Shifts=X can give little extra SDR as it's doing multiple passes, but will not degrade "baseline" quality (even with shifts=0)
Lower than recommanded values for segment will degrade "baseline" quality.
So in theory, you can equally set shifts to 0 and max out overlap.
Segments optimum (in UVR beta/new) is 256.