FMOD_CREATECOMPRESSEDSAMPLE and Tracker files behaviour is suboptimal

Now it turns out that it actually exactly does that. Tracker formats are none of the supported formats, so it tries again FMOD_CREATESAMPLE, which for Tracker formats (gladly) fails.

However my issues is that I do not have any a priory knowledge about whether a file I intend to play or not is a Tracker based format, but otherwise also want mp3, ogg, etc. to remain compressed.

I guess the approach here would be, to try again without the the FMOD_CREATECOMPRESSEDSAMPLE flag set, but is there a better way to do this? I kinda just want the files either way to remain compressed.

Might be worth to note that I prefer FMOD to keeping it’s own copy of the data, as in my use case I would otherwise need to create a copy on my own.

I sort of solved my issue about querying the type of the sound I want by opening my (in memory) data with FMOD_CREATESTREAM | FMOD_OPENMEMORY_POINT.

FMOD_RESULT __FMOD_System_PeekSoundTypeFromMemory(FMOD_SYSTEM *system, const char *data, FMOD_CREATESOUNDEXINFO *exinfo, FMOD_SOUND_TYPE *type)

	FMOD_SOUND *sound;
	FMOD_RESULT result = FMOD_System_CreateSound(system, data, FMOD_CREATESTREAM | FMOD_OPENMEMORY_POINT, exinfo, &sound);
	if (result!=FMOD_OK)
		return result;

	int channels, bits;
	result = FMOD_Sound_GetFormat(sound, type, &format,&channels, &bits);

	return result;

However documetention about FMOD_OPENMEMORY_POINT states that this is supposed to fail for for compressed sound data, but FMOD_SOUND_TYPE_OGGVORBIS and FMOD_SOUND_TYPE_MPEG work just fine.


“name_or_data” will be interpreted as a pointer to memory instead of filename for creating sounds. Use FMOD_CREATESOUNDEXINFO to specify length. This differs to FMOD_OPENMEMORY in that it uses the memory as is, without duplicating the memory into its own buffers. Cannot be freed after open, only after Sound::release. Will not work if the data is compressed and FMOD_CREATECOMPRESSEDSAMPLE is not used.

So now afterwards my approach is to determine storage strategy based on the type.
For FMOD_SOUND_TYPE_FSB, FMOD_SOUND_TYPE_MPEG and FMOD_SOUND_TYPE_XMA, I set FMOD_CREATECOMPRESSEDSAMPLE as it would either keep the MP2/MP3 compressed and otherwise I think I wouldn’t mind, as most it would just store the uncompressed data in the soundbanks in a more efficient memory way.

For Tracker formats, i can now just omnit the FMOD_CREATECOMPRESSEDSAMPLE sample flag, and be fine.

Now as far as I understand it, if I want to keep FMOD_SOUND_TYPE_OGGVORBIS (and others) compressed I would have to keep a local copy around and make use of FMOD_CREATESTREAM. If streaming is not desired for that particular sound, I would need to fall back to just use FMOD_CREATESAMPLE, which should behave in the same way as not setting it in this case?

Do I miss something? All I want to do is to have FMOD to copy of the data in it’s best suited internal storage format, while at the same time keeping compressed audio data compressed.

Would FMOD_OPENMEMORY | FMOD_CREATESTREAM create an internal copy of the data? FMOD_CREATESTREAM really just mentions files on disk.

By just using the FMOD_CREATECOMPRESSEDSAMPLE flag, FMOD will create a copy of the file in memory and:

If the sound data is not one of the supported formats, it will behave as if it was created with FMOD_CREATESAMPLE and decode the sound into PCM.

So you don’t have to manually determine if you need to use FMOD_CREATESAMPLE or FMOD_CREATECOMPRESSEDSAMPLE.