In-memory based parsing and some appreciation.

[follower]

Appreciation

Thanks for your efforts developing GDScriptAudioImport! I was glad to find this project existed when I discovered Godot unexpectedly didn't handle parsing WAV files at run time!

Modification to support in-memory (non file-based) parsing

A couple of suggestions if you or anyone else happens to develop the code any further:

• Consider extracting the WAV parsing code into a separate function so that it can be used with WAV files from non-file sources (e.g. HTTP request).
  I very hackily modified the code to do this when I re-used it here: lightly modified GDScriptAudioImport.gd.
  (Also, FWIW, removed the debug print statements too--although it'd probably be more useful to enable them to be able to be toggled on/off for development purposes.)
• When reading from a file consider using the get_* family of functions for the parsing data types rather than implementing the byte/offset handling "manually": https://docs.godotengine.org/en/stable/classes/class_file.html#class-file-method-get-16
  Edited to add: Forgot to mention, it's potentially possible to easily convert the code to get_* functions based on changing the set_* operations in Godot's WAV save implementation to get_* operations. :D (Or, indeed, some of the code in the WAV resource importer, e.g. here.)
• If changing to use a separate function to parse a non-file-based PoolByteArray in memory, it's still possible to use get_* family style parsing methods but it's not at all obvious how...
  The solution is to use the extremely un-intuitively named & under-documented StreamPeerBuffer class which also supports the get_*/set_* data type parsing methods--but this isn't immediately obvious because the methods are actually implemented on the StreamPeer class from which it inherits.
  Here's an example of StreamPeerBuffer class in use.
  And some more notes about StreamPeerBuffer.
  Which includes this summary: :D

  The...ah..."un-intuitively"-named StreamPeerBuffer is un-intuitively named because it has no Peer :) and it's not a Stream. It's just a Buffer...with some useful helper methods.

  The naming is because it's based on a class that is used by the family of classes that do have Peer(s) & are Streams.

I would be inclined to make the modifications myself just to tidy up the implementation a bit but given this functionality will hopefully be (re-)implemented in engine at some point* it's not obvious that it's worth spending the time refining the existing code further.

Anyway, thanks again & hope some of these notes are useful to someone along the way. :)

[Gianclgar]

Thanks a lot for your comment, thoughts and research!

I would be inclined to make the modifications myself just to tidy up the implementation a bit but given this functionality will hopefully be (re-)implemented in engine at some pointhttps://github.com/godotengine/godot/pull/47389 it's not obvious that it's worth spending the time refining the existing code further.

I feel exactly the same way. Hope this gets implemented soon in Godot core so this project become successfully useless hahaha. Maybe it'll still help someone learn about WAV parsing and / or Godot itself.

Cheers!