Let’s say I wanted to create an audio importer for an audio format that is not supported by Unity - can this be done? Does Unity provide an API to allow a custom Audio Importer that would work seamlessly like the other Audio Importers ?
If so could someone point me to a some starting reference (API docs or example extension).
I can see that I can intercept the import pipeline by using an AssetPostprocessor but I’m not sure how that will enable me to import the audio and present unity with the WAV data (I expect that’s what I’ll be storing in the library somewhere?)
It seems like a simple thing to do, but I can’t find any info on how to store the results in the AssetDatabase (I assume that’s the destination of my eventual data ?)
Hey IzzySoft - that’s what I want to do - the converting of data is the simple bit, but I don’t want to create ‘another’ asset, I want to allow unity to process the asset in the original form (and I’ll provide the ability to decode it into standard wav data).
Essentially I want to provide the codec to unity via a nice API - if Unity has one, or is there is some way to achieve similar results.
Short of saving the FLAC audio file to a .txt resource (just in name), and later reading the TextAsset’s binary data at runtime, cant say there’s a better way, yet.
Well, Saving a ScriptableObject instance as a FLAC asset is doable, and might seem more appealing. It would mean you could Delete the Original FLAC audio file (originally Imported) at the end of the AssetPostprocessor call. Never did it, so can’t vouch, just brainstorming.
Thanks IzzSoft, they’re some good suggestions, but unless it could be as seamless (and integrated into) Unity’s import pipeline then I’ll just continue to use wav files.
Thanks @superpig a shame, but at least I know to not waste any time trying
This seems like a rather trivial extension for Unity to make that could vastly improve the 3rd party product support that could be added by extensions.
Perhaps my lack of knowledge about the import piepline and processing pipelines is what’s making me think it’d be trivial to allow - I’d have expected all your current audio codecs just implement some interface or expose an API, to add to these via extensions seem almost natural