C++ CreateSound() fails with é in the folder name

FMOD Engine
1

Attempting to open a file named é_test\announcer\win1.ogg I get the following message:
FMOD error! (28) "An error occurred that wasn't supposed to. Contact support.", filename C:\é_test\announcer\win1.ogg.

This issue was reported by a user who had no sound because the base directory they had placed the application in had an é in it, and I narrowed it down to FMOD itself not liking the é character in a sound filename:

  • Renaming the directory to anything without an é in it works just fine.
  • Opening the same const char *filename passed to the function myself, reading the contents into memory, and using FMOD_OPENMEMORY with an FMOD_CREATESOUNDEXINFO also works fine. The problem is that that incurs the overhead I’d like to avoid with FMOD_NONBLOCKING.

I’d be surprised if this hasn’t been reported/fixed before, so please tell me I’m doing something wrong!
Mike Z

2

Thanks for contacting us about this issue. I’ve added it to our bug tracker, so it’ll be fixed in an upcoming version of the FMOD Engine.

Unfortunately, I wasn’t able to find any easy workaround to use in the mean time, other than avoiding the é character in path names.

3

After consulting with some of our developers, I’ve learned that this may not actually be a bug, depending on exactly how the user is passing that path to CreateSound().

All strings used in FMOD are in UTF-8 format, and all FMOD APIs (including System::createSound) expect strings as to be in UTF-8 format, as documented here in the FMOD API User Manual. We standardized on UTF-8 format because it covers all possible characters, is universally recognized, and falls back gracefully to ASCII when necessary.

If the user is instead passing in a string encoded using the ACP (ANSI code page) of for their local machine, errors like they one you described are to be expected. ACPs can vary widely, especially from region to region, and so are not guaranteed to output compatible strings.

For example, the following simple string, encoded as ACP (Windows-1252 for me), will not work in FMOD:

const char *path = "C:\é_test\announcer\win1.ogg";
system->createSound(path, ...)

Whereas the same string with the u8 prefix does work, as it marks the string as UTF-8:

const char *path = u8"C:\é_test\announcer\win1.ogg";
system->createSound(path, ...)

You can test for string formatting issues by using the logging version of FMOD. If you do, and a string is in the wrong format, you’ll see this warning: “Path is not a valid UTF-8 string.”

Whether the string is being manually typed by the user or generated by some other API or code, it’s important to ensure it’s in UTF-8 format, and to convert it to UTF-8 format if it is not (for example, by using MultiByteToWideChar on a Windows machine).