Add support for AIFF files and other WAV formats

[DeeJayLSP]

Changes

In AudioStreamWAV::load_from_buffer(), replaces the entire data read step with one that uses dr_wav.

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.

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.

[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.

[DeeJayLSP]

Addressing changes from #93831, which moved most of the WAV loading code from ResourceImporterWAV to AudioStreamWAV.

AudioStreamWAV documentation updated to explain that the load functions also work with AIFF files and data.

Since the load now requires loading into memory anyway, the old init_memory read has been restored.

[DeeJayLSP]

For some reason, when the tests call save_to_wav with an empty data, a SIGSEGV happens. And only on template builds.

This is odd since I didn't even touch that function.

Edit: it seems like getting the data pointer directly instead of using get_data() solved something. I don't get how it makes sense, but it fixes, so I applied it.

[DeeJayLSP]

Any probability of this being approved for 4.4?

[DeeJayLSP]

Rebased on top of master. I have undone a few adjustments to other unrelated things and kept mostly a direct dr_wav implementation.

[fire]

The best I can do is review for 4.5 and queue it for merge.

Test plan

• Find a few WAV and AIFF files from Wikipedia Commons and archive.org
• Test if the first 30 seconds sounds ok
• Try writing wav (optional?)

[DeeJayLSP]

Since the WAV import procedure was moved from the editor into the templates during the development of this PR (which was relying on it being editor only), I decided to make some builds for measurement.

On Linux builds, template_release got a binary size increase of 36 KB (71,979,280 -> 72,016,144). Would this be too impactful?

I don't see a solution to this other than making AudioStreamWAV::load_from_*() functions separate from the importer (but then template builds wouldn't be able to load AIFFs).

[DeeJayLSP]

The best I can do is review for 4.5 and queue it for merge.

Test plan

• Find a few WAV and AIFF files from Wikipedia Commons and archive.org
• Test if the first 30 seconds sounds ok
• Try writing wav (optional?)

This PR only changes function to read non-imported WAV files, not the playback (in fact, this should have gotten a topic:import label). Saving still uses Godot's own procedure.

Additionally, modifying AudioStreamWAV to use dr_wav's save procedure (not done in this PR) increases binary size by an additional 4KB.

Unit tests already cover this by generating a PCM stream, saving it, loading and comparing if the loaded stream is 1:1 to the generated one before saving. It's the reason DR_WAV_LIBSNDFILE_COMPAT is even defined, as the test was failing without it.

[DeeJayLSP]

Rebased once more.

A modification from #93831 bothered me. It changed the file read procedure to load the entire file into memory instead of using FileAccess to get values from disk.

Thanks to dr_wav, we can initialize a drwav with either memory or a custom FileAccess API. I brought back this solution, modified both functions and made a third one to receive an initialized drwav and do the rest of the load procedure.

[DeeJayLSP]

I was doing an experiment with dr_flac. By cuttting AudioStreamWAV::load_from_buffer in half, it is possible to make this editor-only by implementing dr_wav solely on ResourceImporterWAV.

On the other hand, I decided to wait for a patch in dr_wav as #40320 comes back worse with these changes.

[migueldeicaza]

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