Before you train — Requirements, datasets and validation

Requirements

This is the complete shopping list. Nothing here is optional, and two items — the GPU and Python — are the ones people underestimate.

What you need

A dataset made of official stems for whatever you want to separate — in the reference case, instrumentals and vocals from official releases.
A validation dataset, laid out per track as stem 1, stem 2 and a mixture (the two stems summed together).
The training repository — the code that does the work.
A model to train: a checkpoint plus its YAML config. The repository ships several; you can train any architecture that has both files.

Hardware and software, honestly

Item	Minimum	Comfortable	Notes
`GPU`	NVIDIA, 8 GB VRAM	24 GB+ VRAM	Required — AMD and Apple GPUs are not supported by this training stack.
`Use case`	Pre-training, shifting a target	Full training runs	An 8 GB card is fine for prototyping; real training belongs on rented hardware.
`Python`	3.10+	Latest stable	Needed to run the training scripts locally. Not required if you only ever use a cloud notebook image.
`Disk`	~100 GB free	250 GB+	Datasets, checkpoints written every epoch, and cached tensors add up quickly.
`Audio tools`	Any DAW or converter	A stem-aware editor	You will trim, align and export stems by hand at some point.

What fits in how much VRAM

8 GB

the stated floor

24 GB

a 24 GB card

140 GB

H200 · batch 4

Bars are drawn to the same scale. They are guidance, not gospel: chunk_size and batch_size decide what actually fits, so a smaller card becomes usable if you lower them — it just takes longer to converge.

The cloud alternative

If your card is too small, rent one. Services such as vast.ai and runpod.io rent fast GPUs by the hour, and you can train on hardware you could never justify buying. The trade-off is setup overhead and the pressure of paying for every idle minute — see Chapter 12.

Building a dataset

The dataset is the part that takes longest, because it is mostly research and file management rather than compute. You are hunting official stems across the internet and arranging them so the trainer can read them.

Format rule

Every track in your dataset must be FLAC or WAV. MP3 will not work — lossy compression changes the waveform enough that the model learns the codec's artefacts.

If you have no dataset yet

Start with Bas Curtiz's walkthrough, which covers dataset creation in far more depth than a written chapter can: youtube.com/watch?v=Wmt_0zu94L8. What follows is how that dataset must be laid out for this specific trainer.

Type 1 — one folder per song, one file per stem

Type 1 layout · modelled on MUSDB18 · 4-stem models

MAIN_DATASET/
├── song name 1/
│   ├── bass.flac
│   ├── drums.flac
│   ├── other.flac
│   └── vocals.flac
└── song name 2/
    ├── bass.flac
    ├── drums.flac
    ├── other.flac
    └── vocals.flac

Type 1 mirrors the MUSDB18 structure and is what 4-stem models expect. Every stem of a song lives together, and all stems of a song must end at the same time — the trainer reads them as one aligned example.

Mismatched stem lengths

If stems differ in length you will hit this while the metadata is being collected:

Error · dataset_type 1

Warning: lengths of stems are different for path:
  [C:\PATH_TO_DATASET\SONG_FOLDER].  (25666810 != 28057480)

Trim or pad the offending stems so every file in the folder ends on the same sample.

Type 2 — one folder per stem, all songs inside

Type 2 layout · 2-stem models · drums/bass merged into “other”

MAIN_DATASET/
├── other/
│   ├── song 1 (Instrumental).flac
│   ├── song 2 (Instrumental).flac
│   ├── song 3 (Instrumental).flac
│   └── song 4 (Instrumental).flac
└── vocals/
    ├── song 1 (Vocals).flac
    ├── song 2 (Vocals).flac
    ├── song 3 (Vocals).flac
    └── song 4 (Vocals).flac

Type 2 has exactly two folders: dump every instrumental into other and every vocal into vocals. Track lengths do not need to match, because the loader picks random songs, splits each into chunks (exactly like an inference pass), mixes them and feeds the result to the model.

Schematic · how the loader reads each layout

Why the two layouts behave differently. Type 1 gives the model one aligned song at a time, so the stems have to match sample-for-sample. Type 2 never sees a whole song: it draws random windows from each stem folder and mixes them, which is why track lengths can differ.

How many files?

The original documentation recommends at least 200 audio files, and more is always better. As a real reference point, the finished metal dataset in the source guide holds 2135 instrumentals and 1779 vocals — 3914 tracks in total.

Short files

More tracks, more variety

Standard 3–5 minute songs need volume: a few hundred tracks minimum, ideally thousands. Breadth is what teaches a model to generalise.

Long files

Fewer tracks, still long runs

If your source material is 10 minutes or more per file, you can get away with a lower file count — the model still chunks the audio according to the chunk_size in your YAML.

Where the audio should come from

Use official sources. For vocals you can sometimes substitute a separation — a good Mel-Roformer pass, or inverting an official instrumental — but the recommendation stands: official instrumentals and official vocals give the cleanest training signal. Anything synthesised teaches the model the artefacts of whatever made it.

Switching a 4-stem model to 2 stems

When training SCNet from 4 stems down to 2, the config must declare only the stems you actually want. Set target_instrument to null and list the instruments explicitly — otherwise the loss cannot match shapes:

config.yaml

target_instrument: null
instruments:
  - vocals
  - other

The symptom of getting it wrong is this runtime error:

RuntimeError

output with shape [1, 2, {chunk size}] doesn't match with
  the broadcast shape [2, 2, {chunk size}]

Time budget

Expect the dataset to be the slowest stage of the whole project — not because of processing power, but because you are scouring the internet for clean, official stems. Budget weeks, not evenings.

Building a validation set

The validation set is your scoreboard. It is small, it is read after every epoch, and its only job is to tell you whether the model is actually improving.

Validation layout · 2-stem example

validation_dataset/
├── song name 1/
│   ├── mixture.wav   ← stem 1 + stem 2 summed
│   ├── other.wav
│   └── vocals.wav
└── song name 2/
    ├── mixture.wav
    ├── other.wav
    └── vocals.wav

For a Type 1 (4-stem) setup, each song folder also carries drums.wav and bass.wav. The mixture is not an approximation — it is the stems summed, so the model's output can be compared directly against the truth.

Schematic · validation/song name 1

The relationship the metrics depend on. The model is asked to reproduce vocals and other from mixture, so the three files have to describe exactly the same stretch of time. Shapes are illustrative, not real audio.

16-bit WAV only

The validation loader accepts 16-bit WAV files. Export them correctly: FLAC or 24-bit files can throw errors during validation, which is exactly the kind of problem you do not want to discover after a week of training.

Choose your tracks wisely

Reuse tracks already in your dataset. You already have their stems, so assembling the mixture and the folder is quick.
Full tracks give higher metrics — more audio means a more representative score, and it is what the model will face in real use.
Clips make validation faster. Cutting to 30 seconds–1 minute speeds up every epoch, at the cost of lower metrics. That is a fine trade while you are testing a config and a bad one when you are judging a finished model.

Validation source	Speed	Reported metrics	Use it when
Full tracks	slower	higher, more honest	You are judging the final quality of a run.
30 s – 1 min clips	faster	lower	You are iterating on config, or your GPU is small.

Everything must end at the same time

Inside each validation song folder, mixture, the stems and any other files must be identical in length. If they are not, validation fails with a broadcast error:

ValueError · validation stage

ValueError: operands could not be broadcast together with shapes

Trim the longest file down, or re-export all of them from the same edit session.

Sanity checklist

Before you spend GPU time

Every training file is FLAC or WAV; every validation file is 16-bit WAV.
Type 1 song folders: all stems end at the same sample.
Validation folders: mixture and stems are identical in length.
instruments in the YAML lists exactly the stems your folders contain.
At least a few hundred tracks; the validation set is a small, representative subset.