Fix three failures when exporting on Windows

[svaningelgem]

Three small fixes I hit while exporting DeepFilterNet3 to ONNX on Windows. They're independent, so happy to split them if you'd rather take them separately.

1. get_test_sample builds its URL with os.path.join

df/io.py:

file_path = os.path.join("assets", "clean_freesound_33711.wav")
url = "https://github.com/Rikorose/DeepFilterNet/raw/main/" + file_path

On Windows that gives .../raw/main/assets\clean_freesound_33711.wav, and the download fails:

ERROR | DF | Error downloading file https://github.com/Rikorose/DeepFilterNet/raw/main/assets\clean_freesound_33711.wav (404): Not Found

Since export.py calls get_test_sample() before it exports anything, the whole export is unreachable on Windows unless you happen to be inside a git checkout.

Fixed by joining with / for the URL. The else branch still uses os.path.join, because that one really is a filesystem path.

2. download_file doesn't create its target directory

df/utils.py opens os.path.join(download_dir, ...) for writing, but get_cache_dir() only names a directory — nothing creates it. On a machine that has never downloaded anything, the first call raises:

FileNotFoundError: [Errno 2] No such file or directory:
  'C:\Users\<name>\AppData\Local\DeepFilterNet\DeepFilterNet\Cache\clean_freesound_33711.wav'

Not Windows-specific — it just tends to be masked on Linux, where ~/.cache/... often already exists. Added os.makedirs(download_dir, exist_ok=True).

3. The export tarball stores full build paths

df/scripts/export.py calls tarfile.add() without arcname, so each entry keeps the exporter's export_dir:

$ tar tzf DeepFilterNet3_onnx.tar.gz
Users/<name>/AppData/Local/Temp/dfn3test2/enc.onnx
Users/<name>/AppData/Local/Temp/dfn3test2/erb_dec.onnx
...

Two consequences: extracting recreates that directory tree rather than dropping five files, and a published artefact carries whatever path it was built in — which on Windows includes the builder's username. Passing arcname stores bare filenames:

enc.onnx
erb_dec.onnx
df_dec.onnx
config.ini
version.txt

DfParams::from_targz already matches on path.ends_with(...), so existing tarballs keep loading either way.

Verification

Windows 10, Python 3.11, torch 2.1.2, against this branch:

• the sample downloads after deleting the cache directory entirely (exercises 1 and 2 together)
• the tar contains exactly the five bare filenames above

Not included

Two other things I ran into, mentioned only in case they're useful — I haven't touched either, since both are judgement calls rather than clear bugs:

• On Windows, torchaudio has no WAV backend unless soundfile is installed, so load_audio raises Couldn't find appropriate backend. Installing the soundfile extra fixes it; possibly worth a note in the README.
• libDF requests tract-core = "^0.21.4" and uses ndarray 0.15, but tract moved to ndarray 0.16 later in the 0.21.x line, so a fresh cargo build --features tract resolves to 0.21.17 and fails to compile libDF/src/tract.rs with expected tract_core::ndarray::Axis, found ndarray::Axis. Pinning =0.21.5 works. Happy to open that as a separate issue or PR if it'd help.