FMOD_CREATECOMPRESSEDSAMPLE and Tracker files behaviour is suboptimal

FMOD Engine
1

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.

2

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)
{
	*type = FMOD_SOUND_TYPE_UNKNOWN;

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

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

	FMOD_Sound_Release(sound);
	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.

FMOD_OPENMEMORY_POINT

“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.

3

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

4

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.