Audio banks reimporting before each build

Hi there,

I’d appreciate if someone from the FMOD team could help me with this.

My team and I are noticing something odd and time consuming. Every time we build we see the dialog “Importing: Exemple.bytes” for each one of our binary bank files.


At the moment, it’s OK because it takes only about 1-2 mins, but we’re about to implement our audio localization system and that will make the number of banks explode. I’m worried to build time will be much longer.

Is there a reason for that reimport? Or are we potentially doing something wrong?

We use FMOD Integration 2.02


When the asset bundle import mode is selected, the resulting text assets are just stubs that get swapped in for the real banks at build time. More info can be found here in the docs.
It doesn’t seem like you are doing anything incorrectly; that does seem like a long build time but I am not sure there’s much you can do about it currently. How many banks do you have and how many events would you say are in them on average?

Thanks for your reply!

At the moment, we have 32 banks containing about 10-20 events each.

14 of them are Localized Audio Tables. We are about to add 8 languages meaning 112 more banks. These banks must be built separately because they need to be independently downloaded (using the Unity Addressables system). And our content is expecting to grow.

Do real banks you’re mentioning above need to be reimported everytime we build ? Even when the stubs didn’t change? Would there be any way around that?

This behaviour appears to be a regression introduced in 2.01.11 and 2.02.02. There shouldn’t be any need to reimport these TextAssets every build, and it’s redundant if you are just going to be loading them from your own asset bundles anyway.
I have let the Dev team know of the issue and they will investigate further. You could potentially work around it for now by commenting out the call to CopyToStreamingAssets inside the OnBuildStarted Action in EventManager.cs (line 536 in 2.02.02). This will prevent those TextAssets being reimported every build, and doesn’t seem to affect behaviour as long as you are already loading banks from your own asset bundles.

1 Like

Awesome, thanks for the great support Jeff.

I’ll let you know how that goes next time we make a build.

Unfortunately that does speed up the build time but then I get errors at build time:


Edit: not sure what happened to the image..

Couldn't load Main bank. INVALID format (something like that)

Uncommenting that CopyToStreamingAssets line, rebuilding Adressables, rebuilding the app fixes the errors above.

Here it is- just some weird markdown behavior:

I didn’t come across this issue in my testing- but probably best to wait until we get a proper solution rather than hacking the integration. Hopefully we’ll resolve this before your banks explode in size, but please let me know if build times get unreasonable and I’ll see what else can be done.

1 Like

hey @jeff_fmod , just following up on this.

So we added tens of new localized banks to our project and that did increase the build time but only by about 1 sec per bank which is definitely not a big deal at this stage.

We’d love to see that re-import gone in future updates though! :slight_smile:

Good to hear it isn’t affecting things too much. This issue should be resolved in an update soon, hopefully before your build times get unreasonably long.

1 Like

Hey @jeff_fmod , any update on this? We’re adding more content by the day and this is now getting problematic. Because we need to build often, we need to optimize our build time as much as we possibly can and this “reimport” now costs 4-5 mins for each build. Literally hours wasted per week…

Please let me know if you have any crunchy news or even a temporary workaround.

Hello, that is definitely getting out of hand- we removed this unnecessary copy step when using asset bundles in 2.01.15 and 2.02.06. Please try updating to either of those, or the latest version of FMOD and let me know if you are still running into issues.


Just wanted to say thank you very much for providing a fix for this in the 2.01 branch, as this bug was starting to drive me crazy

1 Like