At this stage AAC will not be a supported compression format for FSBank, the main reason for this is the licensing requirements for creating a codec.
On iOS you can use loose files encoded as AAC which are decoded using the native AudioQueue implementation in FMOD.
Sorry for the confusion regarding my usage of ‘loose format’, I use that term to mean independent files vs packed files. For instance you can play back .wav, .mp3, .ogg, etc with FMOD, these are considered loose files as there is 1 file per sound. The opposite in this case is our format, FSB in which you pack several sounds into 1 file. We recommend all developers use our FSB format as we control the encoding and decoding completely, this allows for efficient storage of data and lower CPU cost playback.
AAC is a high quality, high compression format, but the trade off here is performance. For iOS the only reason I recommend AAC is because of the single hardware decoder, as such I only recommend it for a single stream of music. Anything more than this will overburden the CPU. For general sound effects on iOS (or any mobile platform for that matter) I recommend ADPCM, the compression ratio (3.5:1) isn’t as good as AAC but the CPU cost is less. On platforms other than iOS I would recommend using FSB Vorbis for music streams, it’s high quality, high compression like AAC and free from licensing concerns.
The stretching is indeed as I describe, those docs are incorrect, apologies for the confusion.
Thanks for the additional information.
I totally understand the benefit of the FSB file format. My understanding though is that you can pack MP3 files into the FSB format. On iOS, you’ll have the same issue as AAC where only one MP3 stream can be decoded by the hardware at a time. The other MP3 streams will have to be decoded in software. Albeit the MP3 decoder is not as expensive as AAC, you do have more data to read from the file system, which is super expensive on flash based devices. Loading compressed samples ahead of time into memory takes more space too, leaving you less room for your OpenGL textures. It’s a tradeoff. Not sure which one is better.
However since we’re building a cross platform game, we would prefer using AAC streaming for background music to leverage the hardware decoder on iOS when available and not have to reencode a separate FSB Vorbis version for all other platforms. But since it’s not possible, we’ll default to FSB Vorbis for now until we have a software based AAC decoder implementation.
- Licensing issues around mp4 encoding can be resolved by having Fmod Studio leverage an external encoder as a plugin such as quicktime/ffmpeg. Is there such an API? (Perfect looping can be achieved using aac embedded in caf files)
- Any reason why mp4 decoder is not supported on OSX – AudioQueues work identically as iOS? Would be nice to enable it if possible.
- Is it possible to provide an aac decoder as a custom software decoder to FMod to support other platforms (win32, etc..) ?
- We would need to integrate with an encoder to support our FSB format, you can of course use your own encoder completely separate from FMOD though. We would need to license for the software decoding side though.
- As mentioned in other forum posts with this question, we only support AAC where there is a real benefit from using it, iOS can decode it in hardware for instance. On Mac there are better format options, would could use the AudioQueue code to implement here, but it hasn’t been a priority.
- Yes, FMOD codecs are extensible, we even have an example of a basic codec in our SDK package.
Thanks for the reply.
The aac decoder is usually coming for free of licensing issues nowadays on most platforms these days. iOS/OSX & Android all play natively aac without having to pay extra fees. So it’s really the encoder the issue and if you provide a codec interface, FMod would not have to bear the licensing cost.
The number one reason we would like to use FMod is because of our needs of a cross platform solution. As such, if we wanted to use aac/m4a on iOS for compression & hardware optimizations benefits, we would like to be able to use it on every platform we intend to deliver our product. It would be painful to have to encode 2 different versions of each asset. mp3 is a viable alternative but we can yield much better compression with aac for the same quality. Also the way mp3 are being looped in banks is not ideal, the potential pitch change in the last frame due to stretching is not acceptable. AAC inside a CAF container can provide accurate frame looping sequences.
I looked at FMod Studio SDK and didn’t find an implementation of a custom codec example, only a header file fmod_codec.h. Are you referring to the old FModEx SDK?
I’m talking more about integrating AAC into FSB which for us to adopt would require our own decoder implementation. Implementing AAC as a loose file format would have limited usefulness considering the alternatives.
The looping behavior of FSB requires the audio to be a multiple of the encoding block size, so 1152 samples for MP3. If the source wav is not 1152 aligned and you require seamless looping we stretch the whole sound slightly to achieve that alignment. Are you finding the pitch change to be noticeable? What length files are you encoding to MP3?
Ah yes, that example hasn’t been ported over yet but I believe it is still valid if you take the example from FMOD Ex.
I understand your concern about having to provide a software based AAC decoder. However I disagree when you say that AAC is a loose file format. And the only real viable alternative for an efficient hardware based decoder in FSB is MP3. For an app with lots of sounds, you can reduce the size of your app by a factor of 2 with AAC for the same quality level.
If you can contact me privately, I would love to help you with integrating a (non GPL) software based AAC decoder that would greatly benefit your user base.
Regarding the looping behavior of MP3, your documentation states that it’s only the last frame that is stretched, not the entire sound, is that not the case?:
"Firstly, FMOD’s encoder will resample and stretch the last frame to ensure that all 1152 samples of the frame are used. This will ensure the frame is not padded with silent samples."
Please login first to submit.