MDX v2 parameters (e.g. HQ_1-5, Kim inst, Inst 1-3, NET, Crowd)

Page 88 of 228 · Open the original GDoc ↗

(self.n_fft / dim_f / dim_t inference parameters later below)

Segments 512 had better SDR than many higher values on various occasions (while 256 has lower SDR, and has almost the same separation time).

Segments 1024 and 0.5 overlap are the last options before processing time increases very much.

Don't exceed an overlap of 0.93 for MDX models, it's getting tremendously long with not much of a difference.

Overlap 0.7-0.8 might be a good choice as well.

Segments can also ditch the performance AF -

segments 2560 and 2752 (for 6GB VRAM) might be still a high, but balanced value, although not fully justified SDR-wise, as 512 or 640 can be better than higher values for many songs.

In UVR and Not Eddy’s Colabs you can change segment size from 512 to 32 in order to possibly get better results with some older models like e.g. 438 (it tremendously increases separation time).

Overlap: 0.93-0.95 (0.7-0.8 seems to be the best compromise for ensembles, with the biggest measured SDR for 0.99)

Best measured SDR on MVSEP leaderboard have currently following settings (but it was measured on 1-minute songs, so it can be potentially different for your song):

Segment Size: 4096

Overlap: 0.99

with 512/0.95 worse by a hair (0.001 SDR) and 0.9 overlap for as long, but still not tremendously long processing time (1h30m31s vs 0h46m22s for multisong dataset on GTX 1080 Ti).

Also, segments 12K performed worse than 4K SDR-wise (counterintuitively to what it is said, that higher means better result, but maybe diminishing returns at some point here, so too big values maybe cause SDR drop in some cases)

It seemed to be correlated with set overlap.

For overlap 0.75, segments 512 was better than 1024,

but for overlap 0.5, 1024 was better, but the best SDR out of these four results has 0.75/512 setting, although it’s a bit slower than 1024, but for 0.99 overlap, 4096 segments were better than 512.

SDR difference between overlap 0.95 and 0.99 for voc_ft in UVR is 0.02.

Segment size 4096 with overlap 0.99 (here) vs 512/0.95 (here) showed only 0.001 SDR difference for voc_ft and vocals in favour of the first result.

Difference between segment size 512 with overlap 0.25 (here) vs 0.95 (here) is 0,1231 SDR for the latter.

The difference between default segment size 256 with overlap 0.25 (here) vs 512/0.95 (here) is 0,1948 SDR for vocals, and 0,1969 with denoiser on (standard, not model), and 0.95 is longer by triple.

1024/0.25 vs 256 has not much longer processing time (7 vs 6 mins) than default settings, and better SDR by 0.0865

For overlap 0.75, segments 512 were better than 1024 (at least on 1 minute audio).

Measurement is logarithmic, meaning that 1 SDR is 10x difference.

Be aware that increasing only overlap to e.g. 0.5 from default 0.25, when segments are still at default 256 will muddy the result a bit (might be more noticeable with denoise model enabled), while increasing segments (at least up to 480/512) suppose to add more clarity.

At least on the second beta Roformer patch, max supported segment size on 4GB AMD/Intel GPUs is 480 (at least for 4:58 and HQ 1-3 can sometimes only work with lower 448 - higher overlap and segment size crashes).

256/0.5 also works, at least with HQ 4 (but crashes with 480 segments)

480/0.38 works too, but you can settle on e.g. 0.31 if it’s too muddy.

Try not to keep too many opened apps during separation, as drawing their interface also eats up VRAM on the GPU.

MDX-Net v2 max balanced settings:

Segment Size: 2752 (1024 if it’s taking too long as it’s the last value before processing time increases really much; at least SDR-wise, 512 is better in every case than default 256 unless overlap is increased, and still gets good SDR results)

Overlap: 0.7-/0.8

Denoising

Denoise option used to increase SDR for MDX-Net v2, but instrumentals get a bit muddier (result).

Denoise model has slightly lower SDR (result).

For MDX23C models it somehow changed and using standard denoiser doesn’t change SDR.

Spectral Inversion

On bigger dataset like Multisong Leaderboard decreases SDR, but sometimes you can avoid some e.g. instrumental residues using it - can be helpful when you hear instruments in silent parts of vocals.

Explanation:

"When you turn on spectral inversion, the SDR algorithm is forced to invert the spectrum of the signal. This can cause the SDR to lose signal strength, because the inverse of a spectrum is not always a valid signal. The amount of signal loss depends on the quality of the signal and the algorithm used for spectral inversion.

In some cases, spectral inversion can actually improve the signal strength of the SDR. This is because the inverse of a spectrum can sometimes be a more accurate representation of the original signal than the original signal itself. However, this is not always the case, and it is important to experiment with different settings to find the best results.

Here are some tips for improving the signal strength of the SDR when using spectral inversion:

* Use a high-quality input. The better the quality of the signal, the less likely it is that the SDR will lose signal strength when the spectrum is inverted. (...)"

Further, there is also about picking a good inversion algorithm and experimenting with different ones, but UVR seems to have one to pick anyway.

Q: I noticed https://mvsep.com/quality_checker/leaderboard2.php?id=2967

has Spectral Inversion off for MDX but on for Demucs. The Spectral Inversion toggle seems to apply to both models, so should it be on or off?

A: Good catch.

Once u put it on for one or the other, both will be affected indeed.

I've enabled it (so for both, actually) [for this result].

_____

MDX v3 parameters (e.g. MDX23C-InstVoc HQ and 2 and MDX23C_D1581)

(biggest measured SDR)

Segment Size: 512

Overlap: 16

(default)

Segment Size: 256

Overlap: 8

The “512/16 is slightly better for big cost of time” vs the default 256/8.

- On a GPU with lots of VRAM (e.g. 24GB), you can run two instances of UVR, so the processing will be faster. You only need to use 4096 segmentation instead of 8192.

It might be not fully correct to evaluate segment and overlap SDR-wise based on measurements done on multisong dataset, as every single file in the dataset is shorter than average normal track, and that might potentially lead to creating more segments and different overlaps than with normal tracks, so achieved results won’t fully reflect normal separation use cases (if e.g. number of segments is dependent on input file). Potentially, the problem could be solved by increasing overlap and segments for a full length song to achieve the same SDR as with its fragment from multisong dataset.

Recommended balanced values for various archs

between quality and time for 6GB graphic cards:

_____

Window Size: 320 (best measured SDR)

Faster value for slow PCs: 512

Slower, might give more artefacts: 272

Worse: 768, 1024