[Bug]: RIFF and data chunk sizes incorrect on wav export

[sam1am]

Before reporting

• I'm on the latest release and the issue still happens.
• I searched existing issues and didn't find a duplicate.

What happened?

When a wav is exported, the RIFF and data chunk sizes are never written, so the placeholders are left at 0xFFFFFFFF (~4GB). This causes breaking issues on some playback devices.

app/api/stems.py, get_mixdown() around line 734–740 at HEAD 6ab7edc:

cmd += [
    "-filter_complex", ";".join(filters),
    "-map", out_label,
    *post_seek,
    *codec,        # for wav: ["-c:a","pcm_s16le","-f","wav"]
    *rate,
    "pipe:1",      # <-- the problem
]
return StreamingResponse(_stream_ffmpeg(cmd, ..., cache_path=cache_path), ...)

ffmpeg's WAV muxer writes the RIFF and data chunk sizes as placeholders (0xFFFFFFFF) and patches them at the end by seeking back. pipe:1 is not seekable, so the placeholders are never patched. Every WAV streamed from these endpoints ends up with header sizes claiming ~4 GB of audio.

A few ways to fix this, but I suggest rendering to a temp file, then stream that. The cache temp file already exists, so write ffmpeg output to tmp_path directly and stream/rename it after exit.

I'd be happy to submit a PR implementing this approach. I have a commit on my fork here: sam1am@5ae52b4

I didn't see any direct report of this issue, but I did see several upstream issues that this could potentially be a root cause of.

Steps to reproduce

1. Export the mix as a wav
2. Check it with ffprobe [file.wav]

A file with incorrect RIFF and data chunk sizes will show something like:

[wav @ 0x121904080] Ignoring maximum wav data size, file may be invalid
[wav @ 0x121904080] Estimating duration from bitrate, this may be inaccurate

You will not see this on a file with correct values.

Operating system

macOS (Apple Silicon)

StemDeck version

0.14.2

How did you install it?

macOS DMG

Logs / screenshots

No response

[thcp]

You were right, and the report did most of the work. It is up as #473, with your commit first, pulled from your fork.

Your diagnosis was the whole thing. Placeholder written, seek back to patch it, pipe:1 cannot seek. Nothing to add to that, and rendering to a file is the right answer.

Three things came out of following it.

MP3 is affected too, which surprised me. On a pipe ffmpeg does not write a wrong Xing frame, it writes none at all, and these are VBR, so the file has no duration and no seek table. A four second export reported 00:00:03.87. There is also a second MP3 endpoint for region exports that was still on pipe:1, sitting right beside the WAV one.

FLAC was in the same state and just as quiet about it: STREAMINFO total samples and all sixteen MD5 bytes were zero, and ffprobe read the duration as N/A. You said you suspected this was the root cause of other reports, and I think you were right about that too.

The other one you had no way to see from outside. The render cache key had no version in it, so every broken file already cached would have kept being served for the same export parameters after the fix landed. Anyone who exported once before upgrading would have gone on getting the same file back.

I also moved your generator to returning a path so the endpoints answer with FileResponse. Not for tidiness: awaiting the render means ffmpeg's exit code is known before any byte is sent, so a failed export is a 500 now instead of a truncated 200 that only the log knew about.

Your ffprobe reproduction is what the verification is built on. Running it on real exports through the API, in every format, is what turned up the FLAC and MP3 cases.

Thank you for this. A precise report, the mechanism worked out, a branch ready to pull, and an offer to do the work. That is about as good as a bug report gets.