Take the 2-minute tour ×
Sound Design Stack Exchange is a question and answer site for sound engineers, producers, editors, and enthusiasts. It's 100% free, no registration required.

Hey guys, I am in the process of making sounds for my first game. The project is for an iOS game app and given the 20mb size limit, my audio files have to be really small. As such I would like to deliver some of the shorter sounds at a 24khz sample rate. However, using Logic Pro, I can't seem to figure out how to do that! Obviously when I bounce the file and just simply change the sample rate from 44 to 24, the file is played back twice as fast. How do I make this not happen?

On a related note, how should the files be delivered? Apple seems to stress that the sounds should be in Linear PCM or IMA4 codec, but these files are huge. If you use the bash script afconvert to put them in a smaller file format, it always leads to some awful aliasing. Why would I not just deliver it as an mp3 or AAC? On the other hand, even if I did that, don't the more compressed formats like mp3 require more work for the CPU to encode them on the iPhone?

Sorry for the large amount of questions, if you can answer any one of them, I would be very grateful.

share|improve this question

3 Answers 3

Hi there. I use Logic 9 and save PCM Wav at 22050hz and play back is fine. I'm not sure why you're getting problems with the speed?

20mb goes a long way if you use it efficiently. Keep files sizes low by saving as mono, keep SFX to <0.5sec. Loop SFX for longer instances. Use pitch changes to create variations.

share|improve this answer
    
Hey David, thanks for responding. Yep, your right this does work fine. I was previewing the downsampled files IN Logic who's project setting were set to playback at 44.1khz. Outside Logic I discovered they playback fine. As for pitch change, do you mean deliver one file and then use code like Open AL to do the pitch changes? –  anonymous Jul 21 '12 at 16:49

First of all what game engine are you using?

If its something like Unity then generally for SFX you would use wav and for large sound files use mp3 or ogg (although you would use ogg for seamless loops).

share|improve this answer

It's playing back too fast because a program or the hardware is resampling the sound file to 44.1 or 48kHz sample rate without compensating for the original file length, which leads to doubling its playback speed. In other words, the file might be 22.5/24kHz, but you're playing it back at 44.1/48kHz. Usually resampling algorithms do compensate by default and software/hardware adjusts to the correct sample rate. Otherwise you would use the terms pitch- or timestretching (or -compression) to describe the software process. So the application/hardware (your sound card or playback software) is set up wrong or you're feeding it wrong formats.

You should consider your game engine's or SDK's manual for the supported audio formats on the target platform. Ogg Vorbis is widely supported and highly recommended for games, but it all depends on whether it's supported or not. Otherwise MP3 for most sounds and WAV/AIFF for everything that needs looping (i.e. BG tracks), unless there are other options.

You would be putting a lot of simultaneous sound to make CPU use of any concern, and application perfomance is mainly the developer's problem, so don't worry about it too much, other than going for the most efficient formats that you can use. This applies to sound in all game development.

share|improve this answer
    
Thanks for the response. You were right, it was my playback system that was screwing up the downsampled sounds. Just so I can wrap my head around this: the trade-off for the developer is the more compressed a file, the bigger the CPU hit, but the less compressed file, will take up more space. However because encoding compressed formats delivers such a relatively small CPU hit, for the developer the main concern is almost always how can we make these sounds smaller. Correct? –  anonymous Jul 21 '12 at 16:56
    
Using storage space (and memory) is continuous resource use, using CPU cycles is temporary use. On handheld devices the storage space is the main problem. To make continuous and potentially excessive CPU use the audio would need to be decompressed "on the fly" and you would have too many sounds playing simultaneously (= too many files to decompress on the fly). I would assume that the decompression is not performed in real-time, but rather when the sounds are loaded into memory, i.e. generally when loading all resources (e.g. for a game level). –  Internet Human Jul 21 '12 at 17:32
    
Of course not everything can fit into the memory simultaneously and there might be a need to load/unload resources during playing the game, in which case the game may slow down. But even then, we would be talking about a rather large game with lots of sounds to make it a (developer) concern. –  Internet Human Jul 21 '12 at 17:36
    
Additionally, when/if there's hardware decoding support (in the device/platform) for a certain compressed file format, it should be used. In which case the decompression isn't performed by the general CPU, but a specialized processing unit. –  Internet Human Jul 21 '12 at 17:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.