Closed sevagh closed 5 months ago
@sevagh interesting, we have a regression test that did compare the SDR against vs. 1.0, so that at least on that one track it doesn't seem to have changed.
did you make sure that the separator
settings are the same in your code?
@sevagh did you manage to figure out what the issue is?
Forgot to follow up - I will try to replicate later today.
The regression test uses the 7s MUSDB18 excerpt (which may not even be in the wav format). I wonder if that's related.
I think it's because you evaluated on HQ as opposed to the normal musdb18.
@sevagh i think we can close this. I had to lower the regression test tolerance in #144 :-/
Hi all,
So, when I evaluated UMX and X-UMX (to compare with my model, xumx-sliCQ), in my MDX published paper, I reported the following median SDR values:
I noticed this wasn't aligning with published performance of UMX/X-UMX (in the X-UMX paper):
UMX is supposed to be closer to X-UMX, not almost 1 dB SDR apart.
The way I generate my old (seemingly incorrect) values of 4.64 dB for UMX and 5.54 dB for X-UMX was using the standard sigsep tools to loop over MUSDB18-HQ (50 test tracks), store the evaluation json file, and then aggregate using the aggregation + boxplot scripts:
Then I added this script (from the sisec 2018 repo):
The X-UMX evaluation, using the same set of json files, gives me an SDR of 5.91 dB (higher than 5.54) because the compare_json_results.py gives me a different median (across targets + frames) than 5.54.
The UMX evaluation of the old release corresponding to the published paper (https://github.com/sigsep/open-unmix-pytorch/releases/tag/v1.0.0) got much better results, leading to a median SDR of 5.41 dB (exactly as the X-UMX publication).
The UMX evaluation of the latest tip of master gives me the median SDR significantly lower than 5.41 dB. I think that the new code of UMX has a performance regression.