# FMOD\_CREATECOMPRESSEDSAMPLE and Tracker files behaviour is suboptimal **URL:** \ **Category:** FMOD Engine\ **Created:** [November 10, 2019, 4:09pm UTC](https://qa.fmod.com/t/fmod-createcompressedsample-and-tracker-files-behaviour-is-suboptimal/15201 "2019-11-10T16:09:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Kaufel](https://avatars.discourse-cdn.com/v4/letter/k/958977/32.png) [@Kaufel](https://qa.fmod.com/u/Kaufel)\ **Post date:** [November 10, 2019, 4:09pm UTC](https://qa.fmod.com/t/fmod-createcompressedsample-and-tracker-files-behaviour-is-suboptimal/15201/1 "2019-11-10T16:09:11Z")
> [@](#): > > FMOD\_CREATECOMPRESSEDSAMPLE > > Load MP2/MP3/FADPCM/IMAADPCM/Vorbis/AT9 or XMA into memory and leave it compressed. Vorbis/AT9/FADPCM encoding only supported in the .FSB container format. During playback the FMOD software mixer will decode it in realtime as a ‘compressed sample’. Overrides [FMOD\_CREATESAMPLE](https://fmod.com/resources/documentation-api?version=2.0&page=core-api-common.html#fmod_createsample). If the sound data is not one of the supported formats, it will behave as if it was created with [FMOD\_CREATESAMPLE](https://fmod.com/resources/documentation-api?version=2.0&page=core-api-common.html#fmod_createsample) and decode the sound into PCM. 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. ---
**Author:** ![Kaufel](https://avatars.discourse-cdn.com/v4/letter/k/958977/32.png) [@Kaufel](https://qa.fmod.com/u/Kaufel)\ **Post date:** [November 11, 2019, 11:32am UTC](https://qa.fmod.com/t/fmod-createcompressedsample-and-tracker-files-behaviour-is-suboptimal/15201/2 "2019-11-11T11:32:18Z")
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. ---
**Author:** ![Kaufel](https://avatars.discourse-cdn.com/v4/letter/k/958977/32.png) [@Kaufel](https://qa.fmod.com/u/Kaufel)\ **Post date:** [November 11, 2019, 6:56pm UTC](https://qa.fmod.com/t/fmod-createcompressedsample-and-tracker-files-behaviour-is-suboptimal/15201/3 "2019-11-11T18:56:29Z")
Would FMOD\_OPENMEMORY | FMOD\_CREATESTREAM create an internal copy of the data? FMOD\_CREATESTREAM really just mentions files on disk. ---
**Author:** ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)\ **Post date:** [November 17, 2019, 10:09pm UTC](https://qa.fmod.com/t/fmod-createcompressedsample-and-tracker-files-behaviour-is-suboptimal/15201/4 "2019-11-17T22:09:34Z")
By just using the [`FMOD_CREATECOMPRESSEDSAMPLE`](https://fmod.com/resources/documentation-api?version=2.0&page=core-api-common.html#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](https://fmod.com/resources/documentation-api?version=2.0&page=core-api-common.html#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.