Hi Daniel, On Tue, Dec 30, 2025 at 5:50 AM Daniel Verkamp <[email protected]> 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 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
