What libraries/formats is everyone using? I have a small game and 3 minutes of wav files that almost make my game 50MB completely finished. If I can get away with compressed sounds then it will go down to 5MB.
OGG and WAV have no distribution or licensing issues. If you distribute MP3 files with your game, then you are fine as long as you do not distribute any more than 5000 copies. Distribute more than 5000 copies and you must pay the USD$2500 licensing fee. See mp3licensing.com for more details. You might also consider AAC/MP4. There are no restrictions or licenses due for distribution of AAC/MP4 files.
I suggest compressing the sounds as a zip, then decompress and load them at game load time.
This is fast/simple and there are open source libs for this in C/C++ and C# ect...
I would not suggest that.
Sound waveform data is one of the worst case scenarios for zip compression. Zip compression depends on repeating patterns to achieve good compression. Sound data is more like random data than repeating patterns. You might only save a few KB by using zip compression on the sound data.
Android packages are already zip compressed and decompress at load time.
You will still be using a bucketload of memory with uncompressed sounds if they are loaded into memory.
Your choice of compression will also depend on how you use the sounds in the game. If they are used like a music track (one sound streamed from file at a time), use OGG or MP4. If they are sound effects that will be loaded into memory and potentially have several playing at any one time, have a look at IMA/ADPCM. These are compressed to 4 bits per sample rather than the 16 bits per sample of the uncompressed sounds.
I suggest compressing the sounds as a zip, then decompress and load them at game load time.
This is fast/simple and there are open source libs for this in C/C++ and C# ect...
I would not suggest that.
Sound waveform data is one of the worst case scenarios for zip compression. Zip compression depends on repeating patterns to achieve good compression. Sound data is more like random data than repeating patterns. You might only save a few KB by using zip compression on the sound data.
Was about to say the same thing. ZIP compression highly depends on repeating patterns, which are unlikely to be found in sound files (unless they are VERY simple waveforms, like tones)
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
I suggest compressing the sounds as a zip, then decompress and load them at game load time.
This is fast/simple and there are open source libs for this in C/C++ and C# ect...
I would not suggest that.
Sound waveform data is one of the worst case scenarios for zip compression. Zip compression depends on repeating patterns to achieve good compression. Sound data is more like random data than repeating patterns. You might only save a few KB by using zip compression on the sound data.
Android packages are already zip compressed and decompress at load time.
You will still be using a bucketload of memory with uncompressed sounds if they are loaded into memory.
Your choice of compression will also depend on how you use the sounds in the game. If they are used like a music track (one sound streamed from file at a time), use OGG or MP4. If they are sound effects that will be loaded into memory and potentially have several playing at any one time, have a look at IMA/ADPCM. These are compressed to 4 bits per sample rather than the 16 bits per sample of the uncompressed sounds.
I ment if he just wants to load normal WAV files "AS IS" and without having to go through other sounds formats and or hoops, just compress them as zip. Sure its not as compressed as some formats, but its simple and clean if you just want pure 16bit WAV files at the end of the day. Depends on what he wants I guess and what tool he is using to play and load sounds. Maybe my suggestion is bad for his case, but I don't rly know what that case is.
But you are right a different compression method would be much smaller. I guess you could take that 50mb down about 25% with zip.
What they are trying to say is that Zip'ing an audio file not only does not compress the file, (beyond a miniscule amount), it's superfluous as the APK is already zipped.
You add your wav file to your assets directory and it already gets zipped automatically by your build environment. Manually zip'ing it before hand would do nothing but make the loading process take longer as it would have to be uncompressed twice.
The formats that have been suggested are much better as they are equivalent to "hardware happy" formats, meaning the audio driver stack + underlying hardware either understand the compression format or are able to efficiently decode it in real time, so that the savings in secondary storage that is realised is also passed on as RAM savings.
Your file is smaller on disc/SD, it's faster to load, is smaller in RAM and is efficiently processed by Audio driver stack as a native format. win...Win...WIn...WIN.
Worried about size? OGG. Not? WAV. Not much options here, you probably shouldn't overthink it.
OGG is actually better at compression/audible quality ratio than MP3, as Killa_Maaki mentioned.
The archiving/compression scenarios will not work on audio unless it's FLAC, which is actually supported by the system-- but there's no real reason to use it over lossy compression.
Ogg is the obvious choice. While I would never advocate switching to OGG for one's personal music collection, licensing costs with MP3 make OGG a no brainer. And zipped WAV inside an already zipped container? No. I would fail a student in a High School class that suggested that.
GrenadeGames
OrlandoPosts: 25Member
Comments
I would not suggest that.
Thanks.
You add your wav file to your assets directory and it already gets zipped automatically by your build environment. Manually zip'ing it before hand would do nothing but make the loading process take longer as it would have to be uncompressed twice.
The formats that have been suggested are much better as they are equivalent to "hardware happy" formats, meaning the audio driver stack + underlying hardware either understand the compression format or are able to efficiently decode it in real time, so that the savings in secondary storage that is realised is also passed on as RAM savings.
Your file is smaller on disc/SD, it's faster to load, is smaller in RAM and is efficiently processed by Audio driver stack as a native format. win...Win...WIn...WIN.