[FFmpeg-devel] Re: [PATCH] avformat/wavenc: use RF64 when needed

[Daniel Verkamp via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org