On Sat, Dec 20, 2025 at 1:29 PM Jason A. Donenfeld via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Currently if you encode a large wav, ffmpeg will hint after the fact that the resultant file is corrupted, because traditional wav cannot handle lengths greater than 32-bits. This isn't very useful; nobody benefits from getting garbage files.
You can manually work around this by adding `-rf64 always`, which most players have support for. Most people don't remember to do this until after the fact when their file is corrupted, or they don't figure it out at all and wind up using the w64 container instead.
And so that's what `-rf64 auto` is for. It uses the larger format when needed, and if not, uses the traditional wav that is probably more compatible. The result of using `-rf64 auto` is that you can add it to every command line -- and should add it to every command line -- to get either a normal small file, or a non-corrupt large file.
This is a very sensible default to have on, rather than just producing corrupt files and having users scrambling for solutions, and then having to do a potentially expensive reencode after. With `-rf64 auto` on by default, the user always gets a readable good file. And for users who sometimes want corrupt files, there still exists `-rf64 never` that can be enabled. ---
Hi, I am not opposed to changing the default, but I recall there were some reports of problems[1] when ffmpeg began to stray from the "classic" WAV file layout. The `-rf64 auto` option adds an extra junk chunk near the beginning of the file, before the "fmt " chunk, to reserve space for the extended header if needed. While most WAV-consuming software will ignore unknown chunk types gracefully, some tools assume a fixed header layout and will produce garbage audio data when reading a file with extra header chunks or with "fmt " not being the first chunk (at least this is my vague recollection when looking into this some time ago). That said, these issues happened years ago, and perhaps most software is fixed by now (and arguably, any software that does not handle these files is buggy); on the other hand, attempting to put more than 4 GB of audio data in a WAV file is probably pretty uncommon, and there are other formats that can handle large audio data if the specific format doesn't have to be WAV. (WAV probably has better name recognition, though.) Thanks, -- Daniel [1]: A related mailing list thread from 2013, which unfortunately doesn't name the specific broken software: https://ffmpeg.org/pipermail/ffmpeg-devel/2013-April/thread.html#142560