Downloads · 30 days
0
musetric/uvr-mdxnet-kara2-onnx
uvr-mdxnet-kara2-onnx is a audio-to-audio model from musetric. Use it for the audio-to-audio task on the model card, and read the license before you ship it in a product. It is set up for onnxruntime-web. The card lists the license as mit.
Musetric no longer runs this graph: since musetric/musetric1157 its separation model, musetric/mel-band-roformer-duality-kara2-student-onnx, gives the lead and the backing in one pass, with a split distilled from KARA 2.
Downloads · 30 days
0
Access
Public
Updated Nov 1, 2026
Repo size
159 MB
Likes
1
Public
Click a slice to open those files.
.onnx52.8 MB · 100%
From the Hugging Face model README
Musetric no longer runs this graph: since
musetric/musetric#1157 its
separation model,
musetric/mel-band-roformer-duality-kara2-student-onnx,
gives the lead and the backing in one pass, with a split distilled from KARA 2.
This repository stays for the builds that pin it.
ONNX graph of the UVR-MDX-NET KARA 2 karaoke model from Ultimate Vocal
Remover, packaged for the musetric packages/ai runtime
(onnxruntime-web on WebGPU).
The graph is the network only: it takes a complex spectrogram chunk and
returns the complex spectrogram of everything except the lead vocal. The weights
and operators are those of the UVR release file; the time axis of the U-Net is
carried as bands in the batch axis, so that the WebGPU execution provider
computes it correctly on Adreno 6xx GPUs too (see the known defect below). STFT,
chunking, overlap-add and the lead/backing split run in the host. This is not a
drop-in audio -> stems model.
vocal stem, 44100 Hz stereo, peak-normalized
-> STFT (n_fft 5120, hop 1024, periodic Hann, reflect-padded center frames)
-> bins 0..2047, bins 0..2 zeroed -> input [1, 4, 2048, 256] per chunk
-> kara2.onnx -> output [1, 4, 2048, 256] per chunk
-> bins 2048..2560 zeroed, iSTFT, overlap-add across chunks -> separated
-> backing = separated · peak
-> lead = (vocal − 1.065 · separated) · peak
Intended:
onnxruntime-web, on desktop and on
mobile GPUs alike. The wasm EP gives the same result.Out of scope:
Limitations:
n_fft 5120, hop 1024,
periodic Hann window 0.5 − 0.5·cos(2πn/N), frames centered with reflect
padding of n_fft/2; the first 2048 of 2561 bins, with bins 0–2 zeroed;
channels ordered [left real, left imaginary, right real, right imaginary].
A different window, bin count or channel order gives wrong output without an
error.onnxruntime-web runs Conv, ConvTranspose and BatchNormalization on
WebGPU in NHWC and inserts a layout Transpose around each of them. For a batch
of one, that Transpose reduces to a single [C, H·W] matrix swap and takes a
tiled kernel that loses a quarter of its writes on Adreno 6xx; the source graph
then comes out silently wrong there (2,094,338 of 2,097,152 elements off by more
than 1e-2 on an Adreno 660, and different from run to run). The operators
themselves compute correctly. Probed one by one on an Adreno 660 with this
model's weights:
| Operator | Batch 1 | Batch 2 |
|---|---|---|
Transpose NCHW → NHWC | wrong (5.9 dB) | exact |
Conv 3×3, 2×2 stride 2, 1×1 | wrong (5–8 dB) | 143.5 dB to exact |
ConvTranspose 2×2 stride 2 | wrong (4.1 dB) | 137.2 dB |
BatchNormalization | wrong (5.5 dB) | 145.1 dB |
This revision keeps every operator of the source graph and holds each tensor of
the U-Net body, [1, C, 256, F] in the source, as [4, C, 64, F]: four bands of
64 time frames, one per batch item, so every layout transpose swaps a batch of
matrices. Only a 3×3 convolution mixes neighbouring frames; it takes its halo
rows from the neighbouring bands (zeros at the ends of the plane) and runs with
no padding along time. The 2×2 strided and transposed convolutions pair frames
inside a band; the frequency-axis MatMuls, BatchNormalization, Relu, Add
and Mul act per frame. The input 1×1 convolution runs on the bands; the
output 1×1 convolution runs as a MatMul followed by a rank-3 Reshape
before the bands are joined back into time, so that no layout transpose lands on
a batch of one. Rebuild: fold_time_bands.py --bands 4 in musetric-toolkit
scripts/onnx/kara2/.
Revisions 7d49dab and 8f6d5fe shipped a static rewrite instead, with every
convolution unrolled into MatMuls (8f6d5fe cut into row bands); it was
correct everywhere and 1.1–2.1 times as slow.
The session runs one chunk; the host supplies input and consumes output.
import * as ort from 'onnxruntime-web/webgpu';
const session = await ort.InferenceSession.create('kara2.onnx', {
executionProviders: [{ name: 'webgpu', storageBufferCacheMode: 'simple' }],
});
// spectrum: Float32Array of shape [1, 4, 2048, 256], produced host-side from one
// 261,120-sample stereo chunk of the vocal stem (see the contract above).
const input = new ort.Tensor('float32', spectrum, [1, 4, 2048, 256]);
const { output } = await session.run({ input });
// output: float32 [1, 4, 2048, 256] -> iSTFT and overlap-add host-side.
See the musetric host code at
33d010c8,
the last to run this graph (packages/ai/src/runtime/leadBacking/,
packages/server/src/analysis/voices.rs), for the full STFT, chunk plan and
lead/backing split.
| File | Size | SHA256 |
|---|---|---|
kara2.onnx | 52,832,612 B | f90e997ad60af6bf25bac77ad02f5e127a564d363a2b60ecb41100cd83e4ba12 |
Signature — float32 weights, opset ai.onnx 13, IR 6:
| Tensor | Type | Shape | Meaning |
|---|---|---|---|
input (in) | float32 | [1, 4, 2048, 256] | complex spectrogram of the vocal stem chunk |
output (out) | float32 | [1, 4, 2048, 256] | complex spectrogram of the backing vocals |
Against the source graph. On the onnxruntime CPU provider the output equals the source graph's exactly on the deterministic input. On WebGPU it equals the source graph run on the same device on desktop NVIDIA, Adreno 750 and Apple M3 (iPad Air), and it is the same on Adreno 750 and Adreno 660.
Parity. The musetric parity gate (torch reference, ONNX on the CPU, wasm, WebGPU and the product's runtime, on two cases of an openly licensed song) passes on desktop NVIDIA, Adreno 750, Adreno 660 and Apple M3; the product's chunk output lies 111.7–117.3 dB from the original model.
Speed and responsiveness, against the previous revision 8f6d5fe, as
musetric runs a chunk (paced one submission at a time), three loads of each
revision alternated. The foreign job wait is how long a one-dispatch job
submitted every 100 ms on another GPU device waits for its turn:
| Device | Chunk p50, previous | This | Foreign job wait p50 / p95 / worst, previous | This | Peak GPU memory, previous → this |
|---|---|---|---|---|---|
| desktop NVIDIA, Chrome 154 | 670 ms | 329 ms | 3 / 5 / 60 ms | 3 / 8 / 14 ms | 1.69 → 1.21 GiB |
| Adreno 750, Chrome 154 | 3.20 s | 1.93 s | 19 / 93 / 335 ms | 53 / 215 / 548 ms | 1.92 → 1.44 GiB |
| Adreno 660, Chrome 154 | 8.24 s | 7.21 s | 36 / 131 / 270 ms | 186 / 765 / 984 ms | 1.90 → 1.42 GiB |
| Apple M3 (iPad Air), Safari 26.4 | 3.89 s | 1.59 s | 2 / 32 / 80 ms | 14 / 60 / 85 ms | 3.96 → 1.92 GiB (the tab's process) |
Re-run the parity gate on the exact published bytes before relying on it.
Code license and weight license are separate; ONNX conversion does not change the weight license. Documented only as far as it is verifiable.
kuielab/mdx-net.UVR_MDXNET_KARA_2.onnx from the UVR model release
TRvlvr/model_repo all_public_uvr_models — 52,786,726 B, sha256
bf32e15105a09c0f7dddd2b67346146334d6f3ecb399ed7638eba2ab07cbf5f4. A release
asset is not content-addressed, so the sha256 is the pin.scripts/onnx/kara2 in musetric-toolkit.packages/ai and packages/server in musetric.This graph preserves the upstream MIT license; we do not claim authorship of the original weights.
MIT, inherited from the upstream weights.