Thanks @RhnSharma
I personally don't oppose this change, but I think it would be good to get input from multiple devs whether this is desirable.
As for the PR itself, the documentation in Server.schelp (maybe elsewhere as well? haven't looked closely) should also be updated.

As far as I am concerned, it is ok. I am not sure about possible downsides of wav though. I think there used to be a difference in the way headers could be extended, but I don't know.

I've just realized: what about files >4GB? Currently, AFAICT, wav's data is being written above that level, but the header does not support that size (some programs will read the whole file, some will only read data up to what's specified in the header). I'm not sure what's the state of supporting RF64/BWF to get around the 4GB limit with wav files. I think the 4GB limit is something we should consider when making changes to the default format.

EDIT: FWIW the 4GB limit might also apply to AIFF, but I'd need to check that.

FWIW the 4GB limit might also apply to AIFF

https://manual.audacityteam.org/man/export_formats_supported_by_audacity.html :

"Size limits for WAV and AIFF PCM-encoded files
"WAV and AIFF files are limited to a maximum size of 4GB (this is a general restriction and not an Audacity one)."

So we don't lose anything by switching to WAV.

I think this change is fine esp. for the benefit of Windows users. (FWIW, #5557 reports problems opening AIFF files in Linux, which I have never experienced, so I found that a puzzling remark.)

I think this change is fine esp. for the benefit of Windows users. (FWIW, #5557 reports problems opening AIFF files in Linux, which I have never experienced, so I found that a puzzling remark.)

This is generally true - sorry, I should have specified (was in a hurry when reporting - bad idea). The only program really that struggles with this is lame, it simply refuses to use aiff. Of the programs I use daily - sox and Reaper seem ok with AIFF for example. I don't use audacity and ardour so I don't know how they behave. Still, I think the argumentation holds - that having something more universal than an apple format as the default would be cool

The only program really that struggles with this is lame, it simply refuses to use aiff.

FWIW I couldn't reproduce this: lame -V5 SC_210703_134352.aiff SC_210703_134352.mp3 produced a valid mp3 file.

But again, I don't mind the change for the sake of Windows players.

It's more common to find audio apps that don't like 32-bit float samples, but we shouldn't change that -- floats prevent irreversible clipping.

If we are to move ahead with this change, the documentation should be updated as well.

To clarify: I'm now also OK with this change, but the PR needs to have the documentation updated, as indicated earlier.

WAV is a simpler format and don't have extended 80 bit IEEE Standard 754 floating point number just for the sample rate... Which is a technological mystery for me.

Hello @RhnSharma
Would you be able to add documentation changes to this?

Okay, I'm going to push documentation changes for this PR

Please note:

• I did make changes to the Non-Realtime Synthesis guide replacing aiff with wav
• Buffer -write still uses aiff as the default format; as this was not the objective of this PR, I did not change that
• ProxySpace recording uses aiff by default (present in the documentation in the main repo, but the classes are in the JITLibExtensions quark; again, I haven't touched these

Please note:

• I did make changes to the Non-Realtime Synthesis guide replacing aiff with wav
• Buffer -write still uses aiff as the default format; as this was not the objective of this PR, I did not change that
• ProxySpace recording uses aiff by default (present in the documentation in the main repo, but the classes are in the JITLibExtensions quark; again, I haven't touched these

Thanks a bunch Marcin !

All right, seems like there are no objections, I'll merge this. Thanks!