Move WAV loading functionality to a wav_loader module with dr_wav (adds AIFF support)

[DeeJayLSP]

Changes

Moves the entire AudioStreamWAV load functionality into a module, which uses dr_wav to read and decode data and will be required to use the respective AudioStreamWAV::load_from_* functions (not required for playing AudioStreamWAV audio or creating streams through AudioEffectRecord).

Formats already supported by Godot and loop info detection should remain supported without regressions.

Extra WAV encoding formats like A-law, μ-law, MS ADPCM and IMA ADPCM can now be imported.

Note: All of them will be decoded on load, so any loss will be retained and passed to the compress modes.

Note 2: Even if Godot is able to compress and play audio as IMA ADPCM, the way it's compressed within Godot doesn't match the usual compression done in WAV files, so those couldn't be imported without decoding anyway, unless a compatibility breaking change is done to modify how Godot encodes and plays it.

Indirectly fixes #90957.

AIFF support

dr_wav is also able to read AIFF files, so ResourceImporterWAV was enabled to recognize it too.

load_from_buffer and load_from_file should recognize AIFF data/files as well.

The importer was renamed from Microsoft WAV to Microsoft WAV/Apple AIFF to reflect that.

When it comes to sound effects, freesound.org provides much more AIFF than Ogg Vorbis files, so I thought adding support was reasonable:

wave, aif, aiff and aifc file extensions have been added as recognized extensions alongside wav in the importer.

Actually load from file instead of a file buffer

#93831 changed the load function to copy the entire file data into memory from using FileAccess to get values.

You can tell dr_wav to use specific read/seek callbacks, so I wrote callbacks to make load_from_file read using FileAccess instead of a memory copy.

Caveats

I noticed a 36 KiB size penalty on production template_release builds (71991600 -> 72028464). This PR was opened when the load procedure was editor-only, and during its development was moved into AudioStreamWAV to serve as a load function. I don't know if 36 KiB is too much for this, but as a side effect reduces the probability of errors.

And once again, it is a module that can be disabled.

[DeeJayLSP]

Despite not using libsndfile, the way Godot converts streams from/to f32 follows similar calculations, therefore not defining this leads to some test errors (save/reimport datas being different).

[fire]

Horray

[DeeJayLSP]

Added a check to detect if the container is RF64 or W64.

Even if they could be imported in theory, this is the best non-compatibility breaking way to deny getting a stream that is too big for AudioStreamPlaybackWAV. And it's not like anyone would export to those formats with a .wav extension.

[DeeJayLSP]

Modified the check again, this time it actually checks the amount of samples (maximum of 2147483647).

Normally, the importer uses an int to store the total amount of samples, therefore using a limit shouldn't actually break compatibility (in fact, probably fixes a potential overflow on import).

[fire]

Does the dr mp4 problem affect dr_wav? Not sure of the exact problem.

[DeeJayLSP]

Does the dr mp4 problem affect dr_wav? Not sure of the exact problem.

The problem with dr_mp3 is that it doesn't read a VBR header that informs an amount of samples to skip at the start.

Doesn't apply to WAV.

[DeeJayLSP]

Added .aifc extension to the list as it's supported too.

[DeeJayLSP]

The "Byte" in the names here is misleading, it's actually the offsets of loop begin/end in frames, not bytes.

I have tested this considering the old read code actually copied a sample value directly, not a byte offset.

Works the same way as the previous implementation just fine.

[DeeJayLSP]

Updated ResourceImporterWAV documentation to point out it also supports AIFF.

[DeeJayLSP]

Rebased.

I took the opportunity to redo how the data is read. dr_wav offers 3 ways: From a file through stdio, from memory and from custom read/seek functions.

Before the last push, it was loading the entire file data into the memory, then reading from memory, which resulted into a massive increase in memory usage during import if the file was too large.

Now it uses custom functions (lambdas) that tell FileAccess to react accordingly, effectively being an integration between FileAccess and dr_wav.

I don't know if I violated any Godot style guideline, so I'd like to ask for another review.

The patch in dr_wav could be applied directly into a define, so it was removed.

[migueldeicaza]

AIFF is also the default format for Garage Band, so it comes in very handy to have this support.

[adamscott]

I don't really like the idea of having a function load_from_dr_wav. It exposes needlessly the thirdparty used.

[DeeJayLSP]

I realized removing a check from the file seek callback would speed up imports without making anything fail. I thought it was some kind of overhead from dr_wav.

[DeeJayLSP]

Something that just came to mind: how about making this a module similar to vhacd?

All the vhacd module does is enabling Mesh::convex_decompose() to work. How about reworking this into something that makes AudioStreamWAV::load_from_buffer() and AudioStreamWAV::load_from_file() work?

The size penalty would still exist in distributed editor and template builds, but at least there would be an easy option to make a custom build without it.

[DeeJayLSP]

Rework done.

The entire AudioStreamWAV::load_from_* functions have been reworked into a dr_wavwav_loader module that can be left out of engine builds.

Much like the vhacd module is required to use Mesh::convex_decompose(), the dr_wavwav_loader module will be required to use AudioStreamWAV::load_from_buffer() and AudioStreamWAV::load_from_file().

Since there is a small but considerable demand for AIFF support, but in order to do so in an easy way would result into a big size penalty, I thought a module would be the best approach.

[DeeJayLSP]

Rebased and renamed to a more specific title.

[DeeJayLSP]

Renamed the module to wav_loader to better reflect its purpose and avoid ambiguity, as it could cause people to think it is necessary for WAV playback.