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

**URL:** <https://qa.fmod.com/t/c-createsound-fails-with-e-in-the-folder-name/18424>\
**Category:** FMOD Engine\
**Tags:** cpp\
**Created:** [February 22, 2022, 6:39pm UTC](https://qa.fmod.com/t/c-createsound-fails-with-e-in-the-folder-name/18424 "2022-02-22T18:39:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![MikeZ1](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@MikeZ1](https://qa.fmod.com/u/MikeZ1)\
**Post date:** [February 22, 2022, 6:39pm UTC](https://qa.fmod.com/t/c-createsound-fails-with-e-in-the-folder-name/18424/1 "2022-02-22T18:39:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![joseph](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/joseph/32/264_2.png) [@joseph](https://qa.fmod.com/u/joseph)\
**Post date:** [March 9, 2022, 4:38am UTC](https://qa.fmod.com/t/c-createsound-fails-with-e-in-the-folder-name/18424/2 "2022-03-09T04:38:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![joseph](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/joseph/32/264_2.png) [@joseph](https://qa.fmod.com/u/joseph)\
**Post date:** [March 9, 2022, 11:05pm UTC](https://qa.fmod.com/t/c-createsound-fails-with-e-in-the-folder-name/18424/3 "2022-03-09T23:05:02Z")

</div>

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`](https://fmod.com/resources/documentation-api?version=2.02&page=core-api-system.html#system_createsound)) expect strings as to be in UTF-8 format, as documented [here](https://www.fmod.com/resources/documentation-api?version=2.02&page=glossary.html#string-format) in the [FMOD API User Manual](https://www.fmod.com/resources/documentation-api). 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:

```cpp
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:

```cpp
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`](https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar) on a Windows machine).