MDX23 by ZFTurbo (jarredou fork) - 2, 4 stems
(2-4 stems, max 32-bit float output)
As of October 2025, Colabs are defunct due to Google’s runtime changes
(possible fix - make the dependencies look like here).
v2.5 (broken mirror to change repo), v2.5 /w HQ_5 (experimental - muddiness, residues - set HQ_5 weight to 2.5 or lower), /w SCNet XL (weights not measured), WebUI fork (for local installation), 2.4 (dead, added BS-Roformer model), 2.3 (Kubinka fork of jarredou’s Colab /w FLAC conversion, ZIP unpacking, new fullband preservation), 2.1 (voc_ft instead of Kim Vocal 2, a bit better SDR over 2.0 in overall), 2.2 (dead, with MDX23C model, may have more vocal residues vs 2.1), org. 2.3 (dead, with VitLarge model instead instr-HQ3), GUI/CML (GUI only for older original 1.x release by ZFTurbo), instructions for local installation at the button
The ZFTurbo 1.0 Colab was further modified by jarredou to alleviate vocal residues. It adds better models and volume compensation, fullband trick for narrowband vocal models, higher frequency bleeding fix and much more. Currently, it achieves not much worse SDR as current “Ensemble 4 models” on MVSEP utilizing some newer private models available only on MVSEP already. Initially released 1.x code by ZFTurbo received 3rd place in the latest MDX 2023 challenge.
“I have successfully processed a ~30min track with vocals_instru_only mode [on Colab] while I was working on that 2.3 version, but it was probably with minimal settings.
[Errors/freezes are] already happening during Demucs separation when you do 4-stem separation with files longer than ~10-15 min” jarredou
With v. 2.4, a 30 minute file was too long, and the Colab hung on Roformer model separation.
The Colab combines results of then the best public models of different architectures using custom weights for every model (like a manually set volume for every stem, then mixed with others together), instead of usual methods of ensembling as in UVR, which in e.g. “avg” averages results of all models (so there the same volume is used for every stem). More tricks in the Colab explained further below.
As of v. 2.5 “Baseline ensemble is made with Kim Melband Rofo, InstVocHQ and selected 1296 or 1297 BS Rofo” (so Kim Rofo was added, and VitLarge is no longer default).
~“Free Google Colab gives you 3h per day, then you need to wait 24h, and next day it gives you 2 free hours, after 24h wait you'll get only 1h, and 24h later, 2h of free credits, the day after 1h of free credits, etc... and once in that pattern, you have to wait 48h to recover the 3h back.” You can just change your Google account when the GPU limit is reached, but remember to use the same new account during mounting GDrive, otherwise you may get an error.
Troubleshooting
- “PytorchStreamReader error”
simply restart the environment, it’s a random issue occurring in the Colab.
- “usage: inference.py [-h] --input_audio INPUT_AUDIO [INPUT_AUDIO ...] --output_folder”
(and the whole list of arguments is shown below)
launch mount to GDrive cell (it’s not being done automatically) or change file input and output path
- “ValueError: Mountpoint must not already contain files”
(on attempt of mounting GDrive), go to file manager on the left, and you probably have GDrive folder with empty folders you need to delete from there first, and retry (might happen when you use GDrive on this account while it’s nto mounted yet, but Colab works).
- "no such file"
(error in v2.3 while batch processing)
“it's square brackets [ ]
when it sees a [ in the filename, it then thinks there's two additional [ ] in the name
changing to regular parentheses does work”
- “If I input more than a single song it just starts building up on model data without clearing the old one, so it slowly starts running out of VRAM and then gets stuck”
Experimenting with settings
- Default settings of the Colab are a good starting point in general
- Some people like to increase BigShifts to 20 or even 30 with all other default settings (some songs might be less muddy that way), but default 3 is already balanced value, but exceeding 5 or 7 may not give a noticeable difference, while increasing separation time severely.
- Switching from 1296 to 1297 model produces more muddy/worse instrumentals in this Colab (more sudden jumps of dynamics from residues). Similar situation with decreasing BigShifts to 1.
- voc_ft enabled might give less muddy results, but with more residues in instrumentals
- In 2.5 you can try out the following settings by mesk:
“Set the weights of BS-RoFormer & MDX23C to 0, enable VitLarge, and set the weights of Mel-RoFormer & VitLarge to 8 & 3 respectively.
You can set BigShifts to whatever you'd like, I think 5 or 7 is optimal” but mesk uses even 9.
VitLarge overlap can no longer be changed in v2.5 of the Colab, probably only in CLI version.
- Or you can test ensemble of only Kim weight 10 + Vit weight 5, BigShifts e.g. 9
- Or BS-Roformer with MDX23C
- Experimentally set “Separation_mode:” to 4 stems (slower) and "filename_instrum2" will be the sum of the Drums + Bass + Other stems that are obtained by processing "instrum" with multiple Demucs models. It might have a bit less vocal residues or be a bit muddier. Vs 2.1 denoiser is less aggressive as its disabled for some stems to save on VRAM.
- Increasing overlap might give muddier results, but potentially better if you hear some vocal residues
- In e.g. older v. 2.4 you might want to disable VitLarge to experiment (it’s disabled in 2.5) - the model increases some noise at times
- Older versions than 2.4 have very clean results for instrumentals, although it can rarely fail in getting rid of some vocals in quiet fragments of a track, but it has a bigger SDR than the best ensembles in UVR. Versions 2.4 and newer started to utilize BS-Roformer arch, which is pretty muddy itself, but deprived of the majority of vocal residues.
- For instrumentals, I’d rather stick to instrum2 results (so sum of all 3 stems instead of inversion with e.g. inst only enabled) but some fragments can sound better in instrum and it also slightly better SDR, so e.g. instrum can give louder snares at times, while instrum2 is muddier but sometimes less noisy/harsh. It can all depend on a song. Most people can’t tell the difference between both.
- If you suffer from some vocal residues in v. 2.2.2, try out these settings
BigShifts_MDX: 0
overlap_MDX: 0.65
overlap_MDXv3: 10
overlap demucs: 0.96
output_format: float
vocals_instru_only: disabled (it will additionally give instrum2 output file for less vocal residues in some cases)
- You can manipulate with weights.
E.g. different weight balance, in 2.2 with less MDXv3 and more VOC-FT.
- For vocals in 2.2 (dead) you can test out these (dead link) settings (21, 0, 20, 6, 5, 2, 0.8)
- In older versions of the Colab Overlap large and small control overlap of song during processing. The larger value, the slower processing but better quality (for both), but bad setting will crash your separation at least on certain songs.
Q: is it possible to use v.2.5 for Melband inference without the need to run the BS model?
A: You can comment out the model(s) you don't want to disable them L621-627 in inference.py [in the line called “vocals_model_names”
Probably, you could also set BS weight to 0, but it might trigger separation of that model anyway, making it slower.]
- To experiment with parameters for just 4 stems separation, you can use:
- "overlap_demucs" in the Colab (not sure how in this Colab, but for demucs_ft, shifts 10 and overlap 0.1 worked the best for original instrumentals as input)
- shifts for demucs are in line probably 511 (formerly 618 in some other versions iirc): https://github.com/jarredou/MVSEP-MDX23-Colab_v2/blob/v2.5/inference.py (dead)
- In order to bypass models for 2 stem separation to use just instrumentals as input for 4 stem separation, “comment out/delete the name of the models you want to bypass” in the line 621 (screen). “If you want to use only VOCFT, you have to activate InstVoc too, else it will crash (as it's using InstVoc to fill the spectrum part that is missing because of VOCFT cutoff)” - jarredou
Using other models not included in the Colab
- (dead) https://github.com/jarredou/MVSEP-MDX23-Colab_v2/blob/v2.5/inference.py
E.g. in line 452 you can replace Kim model by any other vocal model, and replace that edited in file manager once Colab has executed initialization cell or fork the repo. As for using instrumental Roformer models instead of vocal models, I can't guarantee it will work correctly.
- “Easiest way [to replace MDX HQ model] should be to replace Inst-HQ4 link with HQ5 link line 480 https://github.com/jarredou/MVSEP-MDX23-Colab_v2/blob/36909309efd4a75dab9f1d093a112785a8f560fb/inference.py#L480 (dead)
If models parameters are same (iirc they are), drop-in replacement should work (and then you control HQ5 with HQ4 settings in colab GUI)”
- Change the args awaited by inference.py accordingly to the ones you've changed in the Colab notebook [if you decide to change models names in he Colab], it's at bottom of inference.py (line 874 and so on)
- Adding e.g. SCNet is not that easy task, it will also require to really add SCNet arch to the script, not only words (add its core files to "modules" folder, import them in main script, check if that work with existing "demix" functions, etc... else it can't work).
https://github.com/ZFTurbo/Music-Source-Separation-Training/tree/main/models/scnet
You can study how ZFTurbo is doing it with his script and then try to adapt it to MDX23 Colab. ~jarredou
- What weight should you use for your custom model?
“You must process an evaluation dataset with each model individually, download the separated audio and then use my "weight finder" script (here [mirrored]) with all the separated audios from each model. It will try many different weights until it find the best ones for the given model inputs.
Else you can set "random" weights, process the multisong dataset from MVSEP and upload the separated audios to the quality checker to get the evaluation scores https://mvsep.com/en/quality_checker (and repeat until you're satisfied)
Download the mutlisong eval dataset provided on the quality checker link I've shared above. Process the 100 tracks with the model/ensemble you want to evaluate. Download the separated audio.
Rename the files accordingly to guidelines provided in quality checker link, zip them, upload them and wait for the results
All in same folder, and named:
song_000_instrum.wav
song_000_vocals.wav
song_001_instrum.wav
song_001_vocals.wav
song_002_instrum.wav
song_002_vocals.wav
etc...
Software like https://www.advancedrenamer.com/ can be useful for this”
About
The Colab produces one of the best SDR scores for 4 stems (maybe with slightly better implementation on MVSEP as “Ensemble” 4/5 or more models, although it could be 24 or 32 bit output used for that evaluation which increases SDR (jarredou’s v2.3 evaluation was made using 16 bit).
In version 2.4, for 2 stems, UVR/ZFTurbo/Viperx following models are used:
MDX23C Inst Voc HQ/MDX-Net HQ_4 and voc_ft (optionally)/VitLarge/BS-Roformer
and for 4 stems:
How MDX23 Colab works under the hood in 2.3 iirc (more or less)
- MDX models vocal outputs (so inversion of one inst model there) + Demucs only vocals>inversion of these to get instrumental>demucs_ft+demucs 6s+demucs+mmi to get remaining 3 stems (weighted) to get remaining 3 stems (all steps weighted). Something in this recipe could be changed since then.
Or differently - “The process is:
1. Separate vocals independently with InstVocHQ, VitLarge (and VOC-FT as opt)
2. Mix the vocals stems together as a weighted ensemble to create final vocals stem
3. Create instrumental by inverting vocals stem against source
4. Save vocals & instrumental stems
5 (if 5). Take the instrumental to create the 3 others stems with the multiple demucs models weighted ensembles + phase inversion trick and save them.”
Modified inference will probably work locally too, e.g. if you use that 2.1 repo locally (and probably newer too), but the modified inferences from jarredou crashes the GUI, so you can only use CML version locally in that case.
Usage:
python inference.py --input_audio mixture1.wav mixture2.wav --output_folder ./results/
To separate locally, it generally requires a 8GB VRAM Nvidia card. 6GB VRAM is rather not enough but lowering overlaps (e.g. 500000 instead of 1000000) or chunking track manually might be necessary in this case. Also, now you can control everything from options: so you can set chunk_size 200000 and single ONNX. It can possibly work with 6GB VRAM that way.
If you have failed to allocate memory error, use --large_gpu parameter.
Chunks option have been deleted from newer Colab options.
Jarredou made some fixes in the 2.2.2.x version in order to handle memory better with the MDX23C fullband model.
“I've only removed the denoise double pass for demucs_6s, it's activated for other demucs models.”
jarredou:
“you can use a workaround to have MDX23C InstVoc-HQ results only with (dead) settings:
(all weights beside MDXv3 set to 0, BigShifts_MDX set to min. of 1, and demucs overlap 0 [at least for vocal_instru_only)
You can use a higher "overlap_MDXv3" value than in the screenshot to get slightly better results.
(and also, as it's only a workaround, it will still process the audio with other models, but they will not be used for final result as their weights = 0)
(MDX23C InstVoc-HQ = MDXv3 here)
You can also use the defaults settings & weights, as it scores a bit higher SDR than InstVoc alone ”
Be aware that 2.0 version wasn’t updated with:
!python -m pip install ort-nightly-gpu --index-url=https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ort-cuda-12-nightly/pypi/simple/
Or in case of credential issues, you can try out this instead:
!python -m pip -q install onnxruntime-gpu --extra-index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-cuda-12/pypi/simple/
Hence, it’s slow (so use 2.1-2.3 instead as they work as intended or add the line at the end of the first cell yourself)
Explanations on features added in 2.2 Colab (2.2 might have more residues vs 2.1) by jarredou
What are BigShifts?
It's based on Demucs' shift trick, but for Demucs it is limited to 0.5 second shifting max (with a randomly chosen value).
Each BigShifts here shifts the audio by 1 second, no more random shifting.
F.e. bigshifts=2, it will do 1 pass with 0 shifting, and a second pass with 1 second shifting, then merge the results
bigshifts=3 means 1 pass with 0 shifting + 1 pass with 1 sec shift + 1 pass with 2 sec shift, etc...
Overlap is doing almost the same thing but at audio chunks level, instead of full audio, and the way overlap is implemented (in MVSEP-MDX23), f.e. with overlap=0.99, the first audio chunk will have 1 pass, 2nd audio chunk will have 2 passes, etc... until the 99th audio chunk and following ones will have 99 passes. With BigShifts, the whole audio is processed with the same number of passes.
So BigShifts shifts the audio forward one second each time.
Overlap computing is different between MDXv2 models and the other ones in the fork:
For MDXv2 models (like VOC-FT), it uses the new code from UVR and goes from 0 to 0.99.
For MDXv3 (InstVoc) & VitLarge models [introduced in v2.3] it uses code from ZFTurbo (based on MDXv3 code from KUIELab, https://arxiv.org/abs/2306.09382) and it goes from 1 to whatever.
I'm using low overlap values in the fork because it's kinda redundant with the BigShifts experimental feature I've added and which is based on Demucs' "shift trick" (described here https://arxiv.org/pdf/1911.13254.pdf, chapter 4.4). But instead of doing shifts between 0 and 0.5 sec like Demucs by adding silence before input, BigShifts are much larger (and related to input length). Having larger time shifting gives more amplitude in possible results.
Instead of adding silence before input to shift it, which would be a waste of time & resources as BigShifts can be above 30s or 1 min of shifting, instead, it changes the shifted part position in audio input (like move the 1st minutes of audio at the end of the file before processing and restores it after processing).
Then like Demucs original trick all shifted & restored results are merged together and averaged.
From my tests, it can influence results from -2 SDR to +2 SDR for each shifted result, depending on input and BigShifts value. It's not linear!
Using BigShifts=1 (disabled) and high overlap value probably gives more stable results, on the other end, but maybe not always as high and/or fast as what BigShifts can give.
Weights have been indeed evaluated on MVSep's multisong dataset. I haven't tried every possible setting, but default values should be not far away from optimal settings, if not optimal [already].
Q: Wasn't the BigShifts trick in the MDX23 Colab relying on a slowed-down and sped-up separation ensembling?
I think increasing the parameter too much, rather tends to increase bleeding.
A: It's unrelated to bigshifts, but it was doing that for MDX2 models with a cutoff around 16-17khz (to get fullband results from them) but since it's using only fullband models, I've removed that part (in v2.2 iirc)
There are a few other "tricks" used in the [MDX23 Colab] fork:
The phase inversion denoise trick (was already in original code from ZFTurbo, also used in UVR):
Some archs (MDXv2 mostly, so VOC-FT here) are adding noise to output signals. So to attenuate it, we process the input 2 times, including one time with phase polarity inverted before processing, and restored after processing. So, only the model noise is phase cancelled when the 2 passes are mixed together. (It doesn't cancel 100%, but it's attenuated). This is also applied to Demucs processing (since original code).
MDXv3 & VitLarge don't seem to add noise (or at insignificant volume) so this trick is not used with these models.
Segment_size (dim_t) original model value has doubled since v2.3 of the fork.
Some benchmarks done by Bas Curtiz showed that it gives a little bit better results (here with VOC-FT, there's the same benchmark with the InstVocHQ model here).
Multiband ensembling:
I'm using a 2-band ensemble, with different ensemble in frequencies below 10 kHz and above. This is a workaround to get fullband final results even when not fullband models are part of the ensemble (like VOC-FT). Without it, the instrumental stem, obtained by vocals’ phase inversion against the input audio, would have small permanent vocals bleeding above VOC-FT's cutoff, as phase cancellation would be biased there.
It was a really more essential feature in previous versions when most of the models were not fullband.
VitLarge is not used too in high freq band, but it's a more personal taste (so in the end there's only InstVoc model results above the crossover region)
In fact, alternatively you could separate your instrumental with Demucs single models used by the Colab (demucs_ft, demucs 6s, demucs, mmi) and use SCNet XL and BS-Roformer models from here.
As, along with demucs_ft, they have the best overall SDR for 4 stems separation (actually MDX23C model1 can give interesting results too compared to demucs_ft).
And then perform manual weighted ensemble in DAW by setting volume of the stems manually to your liking after importing and aligning lossless stems.
Because rarely ensembling of more than 4 stems gives good results, IG you could get rid of some demucs models with lower SDR for it (I think the mmi has the lowest SDR, and then 6s).
If it's too much of a hassle, you could change the volume of the stems from a specific model by the same volume.
Guide how to use MDX23 Colab v 2.5
(reworked Infisrael text)
0. If you plan to use your GDrive for input files, go there now, and create folder called “input” and upload your files there. Create also output folder (not sure if the Colab creates both already). That way you may decrease the time till timeout when the Colab is initialized (esp. for people with slower connection).
Now open the Colab
1. Click the “play” button on the Installation cell and wait until it's finished (should show a green checkmark on the side)
2. Click the “play” button on the GDrive cell.
It will ask you for permission for this notebook to access your Google Drive files, you can either accept or deny it (it is recommended to accept it if you want to use Google Drive as i/o for your files).
After you've done installing it, go to the Separation section below.
Default settings are already balanced in terms of SDR, and too resource-intensive.
3. Click on the play button to start the Separation, **make sure** you uploaded the audio file in the `folder_path`.
After it's done, it will output the stems in the `output_folder`.
Also note, "`filename_instrum`" is the inversion of the separated vocals stems against the original audio.
"`filename_instrum2`" when “Separation_mode:” is set to 4 stems (slower) is the sum of the Drums + Bass + Other stems that are obtained by processing "`instrum`" with multiple Demucs models.
So "`instrum`" is the most untouched and "`instrum2`" can have fewer vocals residues or sound a bit muddier.
Experimenting on settings you can set BigShifts to 5 or 7, although it may not give a noticeable difference vs default 3, while increasing separation time severely, but some people use 20 or even 30.
Comparisons of MDX23 (probably v. 2.0) vs single demucs_ft model by A5
The Beatles - She Loves You - 2009 Remaster (24-bit - 44.1kHz)
So I tried out the MDX23 Colab with She Loves You, which is easily the most ratty sounding of all the Beatles recordings, as it is pure mono and the current master was derived from a clean vinyl copy of the single circa 1980. So if it can handle that, it can handle anything. And well, MDX23 is very nice, certainly on par with htdemucs_ft, and maybe even better. I'm surprised. You can hear the air around the drums. Something that is relatively rare with demucs. And the bass is solid, some bleed but the tone and the air, the plucking etc is all there. Plus, the vocals are nicer, less drift into the 'other' stem.
John Lennon - Now and Then (Demo) - Source unknown (16-bit - 44.1kHz)
OK, another test, this time on a John Lennon demo, Now and Then. The vocals are solid, MDX23 at 0.95 overlap is catching vocals that were previously in htdemucs_ft being lost to the piano. So, yeah, it's pretty good. MDX23 is now my favored model. In fact, upon listening to the vocals, it's picking up, from a demo, from a poor recording, on a compact cassette, lip smacks, breathing and other little non-singing quirks. It's like literally going back and having John record in multitrack.
Queen - Innuendo - CD Edition TOCP-6480 (16-bit 44.1kHz)
Every single model fell down with Freddie Mercury's vocals, not anymore. (...) I've heard true vocal stems from his vocals and the MDX23 separation sounds essentially like that. We're now approaching the 'transparent' era of audio extraction.
NOTE: [voc_ft not tested] for Innuendo, will be tested by 07/07/2023
Colab instruction by Infisrael for old versions
Install it, click on the play button and wait until it's finished (should show a green checkmark in the side).
It will ask you for permission for this notebook to access your Google Drive files, you can either accept or deny it (it is recommended to accept it if you want to use Google Drive as i/o for your files).
After you've done installing it, go to the configuration, it's below the 'Separation' tab.
https://i.imgur.com/qD9jsYG.png (dead)
(Recommended settings)
Input "`overlap_large`" & "`overlap_slow`" with what you desire, at the highest (1.0), it will process slower but will give you a better quality. The default values for large are (0.6), and for small (0.5) [with 0.8 still being balanced in terms of speed and quality].
Input "`folder_path`" with the folder destination where you have uploaded the audio file you'd like to separate
Input "`output_folder`" with the folder you'd like the stems to be separated
Change your desired path after `/content/drive/MyDrive/`, so for example:
> `folder_path: /content/drive/MyDrive/input`
> `output_folder: /content/drive/MyDrive/output`
You can also make use of "`chunk_size`" and put it in a higher value by a little, but if you experience memory issues, lower it, default value for it is 500000.
Afterwards, click on the play button to start the separation, **make sure** you uploaded the audio file in the `folder_path` you provided.
After it's done, it will output the stems in the `output_folder`.
Also note, "`filename_instrum`" is the inversion of the separated vocals stems against the original audio.
"`filename_instrum2`" is the sum of the Drums + Bass + Other stems that are obtained by processing "`instrum`" with multiple Demucs models.
So "`instrum`" is the most untouched and "`instrum2`" can have fewer vocals residues.
Installing MDX23 Colab locally
NVIDIA 12GB VRAM GPU recommended
"I think it's possible to use Colab notebook .ipynb files locally with anaconda and jupyter, but I've never tried.”
“I didn't get it to work yet but a simple tkinter gui should be easy to throw together I reckon”
Now you can use ready MDX23 WebUI fork by RedsAnalysis.
[Alternatively]
“You can git clone the repo, install requirements and use the inference.py script, but the command line can be really long to type manually (on Colab it's managed with the GUI):
python inference.py \
--input_audio "{file_path}" \
--large_gpu \
--BSRoformer_model {BSRoformer_model} \
--weight_BSRoformer {weight_BSRoformer} \
--weight_Kim_MelRoformer {weight_Kim_MelRoformer} \
--weight_InstVoc {weight_InstVoc} \
--weight_InstHQ4 {weight_InstHQ4} \
--weight_VOCFT {weight_VOCFT} \
--weight_VitLarge {weight_VitLarge} \
--overlap_demucs {overlap_demucs} \
--overlap_VOCFT {overlap_VOCFT} \
--overlap_InstHQ4 {overlap_InstHQ4} \
--output_format {output_format} \
--BigShifts {BigShifts} \
--output_folder "{output_folder}" \
--input_gain {input_gain} \
{filter_vocals} \
{restore_gain} \
{vocals_only} \
{use_VitLarge_} \
{use_VOCFT_} \
{use_InstHQ4_} \
{use_InstVoc_} \
{use_BSRoformer_} \
{use_Kim_MelRoformer_}
Q: How do you use the example {useVitLarge}
like the other stuff ik how to use
A: These last arguments are boolean based, there are generated before the command line and depending on the option selected in the GUI with:
use_InstVoc_ = '--use_InstVoc' #forced use
use_BSRoformer_ = '--use_BSRoformer' #forced use
use_Kim_MelRoformer_ = '--use_Kim_MelRoformer' #forced use
use_VOCFT_ = '--use_VOCFT' if use_VOCFT is True else ''
use_VitLarge_ = '--use_VitLarge' if use_VitLarge is True else ''
use_InstHQ4_ = '--use_InstHQ4' if use_InstHQ4 is True else ''
restore_gain = '--restore_gain' if restore_gain_after_separation is True else ''
vocals_only = '--vocals_only' if Separation_mode == 'Vocals/Instrumental' else ''
filter_vocals = '--filter_vocals' if filter_vocals_below_50hz is True else ''
Q: So you don't need to use them?
Only using the ones with the two -- before right
A: For example, if you want to activate vocals filtering below 50hz, you add "--filter_vocals" to the command line
Q: How do you do this
A: (click)
Q: oh yeah I just have to change the default number then right
It works #general
A: If you have multiple GPUs and the CUDA one is not labelled device "0", maybe that can be the cause too, it's hardcoded for Colab, but you can change it in first lines of inference.py file gpu_use = "0"
If your GPU is not detected in Anaconda, use Python (can be 3.12). If it's the same:
https://pytorch.org/get-started/locally/#start-locally
Where it says "run this command" I basically uninstalled the modules it had in there
so I did pip uninstall torch torchvision torchaudio
then ran that command to install it
and it fucking fixed it (knock)
1.0 original code used kim vocal 1 (later 2), kim inst and (at least for 4 stems) Demucs models.