Hi Daniel, On Tue, Dec 30, 2025 at 5:50 AM Daniel Verkamp <daniel@drv.nu> wrote:
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.
This is not what `-rf64 auto` does, and I think your reply might be skipping an important step. Namely, `-rf64 auto` only goes into riff64 mode when there's no way to construct a valid wav32 to hold the data. So, here are the effects of the different settings: - `-rf64 no`: makes a valid wav file, unless it's too long, and then it produces a corrupt file that can't be played anywhere. *This corruption-producing behavior is the current bad default.* - `-rf64 yes`: always makes a riff64 file, which these days generally has universal support, but ys, at some point long long ago, there were some old players that didn't know about it. *This is _not_ the option I'm proposing we make default.* - `-rf64 auto`: make a valid wav file if it can do so, but then, if it can't, rather than producing a corrupt output file, make a riff64 file, so that it'll still be playable in 99% of the places. *This is what I'm proposing we turn on by default." So, as you can see, `-rf64 auto` is strictly better than the status quo, offering no drawback. It produces a riff64 file only in the case when ffmpeg would _otherwise generate a corrupt unplayable file_. Jason