Best Audio Compression
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm
Best Audio Compression
Use Microsoft ADPCM
Using multiquence many compressions for most formats can be used but the ultimate in size being Wav w/MP3 compression has only ever worked for me in windows although ADPCM is very small fewprograms like tron maintain quality using the format so i just tried several and this reduced my file size from 227k to 27
Using multiquence many compressions for most formats can be used but the ultimate in size being Wav w/MP3 compression has only ever worked for me in windows although ADPCM is very small fewprograms like tron maintain quality using the format so i just tried several and this reduced my file size from 227k to 27
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm
- philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
adpcm isn't proprietary, near as I can tell. It's still uncompressed audio, even though people say it's compressed. Basically, instead of storing the value of a sample, which takes 16 bits, you store only the difference between the current sample and the last sample, which only takes 4 bits.
Now, platform support is a different story. I assume there's good support for it on other platforms, since it's a basic and long-standing way of storing digital audio, but I haven't looked into it.
But it's such a simple way, and this guy hasn't given us any real data to work with. If ADPCM is so awesome, why do we have mp3 and ogg vorbis and the rest? Answer: it's limiting, when you need higher frequencies. Since it only stores a delta, rather than the actual sample, the upper limit on what frequencies can be reproduced is lower than it is for other compression techniques. Of course, you could fix that by using 8 bits or more to store the delta, but then you've gained nothing. (Well, arguably. Gained nothing compared to what you were aiming for, certainly)
Now, platform support is a different story. I assume there's good support for it on other platforms, since it's a basic and long-standing way of storing digital audio, but I haven't looked into it.
But it's such a simple way, and this guy hasn't given us any real data to work with. If ADPCM is so awesome, why do we have mp3 and ogg vorbis and the rest? Answer: it's limiting, when you need higher frequencies. Since it only stores a delta, rather than the actual sample, the upper limit on what frequencies can be reproduced is lower than it is for other compression techniques. Of course, you could fix that by using 8 bits or more to store the delta, but then you've gained nothing. (Well, arguably. Gained nothing compared to what you were aiming for, certainly)
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
With a lossy mapping.Lucifer wrote:adpcm isn't proprietary, near as I can tell. It's still uncompressed audio, even though people say it's compressed. Basically, instead of storing the value of a sample, which takes 16 bits, you store only the difference between the current sample and the last sample, which only takes 4 bits.
BTW, how do you define compression? I think that any successful attempt at reducing the amount of space needed to store some raw thing classifies as compression, whether it involves DCTs or predictors or something else, and whether entropy coding or other coding techniques are used or not. This makes PCM compressed and even lossy, if the signal isn't exactly what PCM can represent. The difference is that PCM is very close to the actual signal in its representation whereas MP3/Vorbis/... are not, and I think ADPCM isn't close enough either.
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm
To start I don't think technical terms matter at to what to call compression and what not who cares.
All that matters are universally supported formats to reduce the file sizes and therefore increase the programs stability.
I use windows btw/ on a slow celeron computer, and I must remove the movie pack for now to save space BUT
I am also aware of jpeg formats that are also much smaller and plan on saving my moviepacks images using different available settings so I can find a working one that is small so on this stupid intel celeron my game will be as good on the other unworked on computer.
AND a word about sound quality it doesn't matter what it sounds in any other program but TRON where it will be heard and the format i suggested has suffered no loss of quality.
That is the point this idea is PROGRAM SPECIFIC (i.e. intended for one and only one purpose)
All that matters are universally supported formats to reduce the file sizes and therefore increase the programs stability.
I use windows btw/ on a slow celeron computer, and I must remove the movie pack for now to save space BUT
I am also aware of jpeg formats that are also much smaller and plan on saving my moviepacks images using different available settings so I can find a working one that is small so on this stupid intel celeron my game will be as good on the other unworked on computer.
AND a word about sound quality it doesn't matter what it sounds in any other program but TRON where it will be heard and the format i suggested has suffered no loss of quality.
That is the point this idea is PROGRAM SPECIFIC (i.e. intended for one and only one purpose)
- philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
Hi,
First of all, could I ask you to be careful of your use of grammar. Not all of us are native english speaker. I am myself French-Canadian. Sinueus sentences are difficult to read through and leave the reader uncertain of the meaning. A good idea can be severly diminished when badly presented.
IIRC, for fast processing (this is a game after all), the images used are first uncompressed into memory before being used for the rendering of the game. This means that heavily compressed images will gain you a few kbytes on disk, require more time to decompress when loaded, and will not free any amount of RAM during execution.
Lowering the size of the textures on the other hand will lower the memory requirement, probably render faster, but will produce a somewhat degraded visual effect. For better results, be sure to keep the size of the textures to powers of 2 (or "powers of 2" + 2)
Seeing as I'd guess your celeron doesn't have under 32 megs of RAM, I dont think trying to free some of it will result in any performance gain (beside the one mentionned). So this leave disk usage. Pulling values out of the air, I'd guess that the moviepack uses 1 meg of disk (probably much less, but lets keep that value). If you half all the dimensions of all the textures, what remains should use about 250k, freeing 750k in the process. The real question is, are you so short on disk space that this 750k would matter? And wouldn't just filling a floppy (1.44 megs, about twice as much at the space gained here) with documents you dont require often be a much better gain (and gain per time invested)?
This seems a bit extreme. Care to enlighten us with some specific details of your set-up?
/ph
First of all, could I ask you to be careful of your use of grammar. Not all of us are native english speaker. I am myself French-Canadian. Sinueus sentences are difficult to read through and leave the reader uncertain of the meaning. A good idea can be severly diminished when badly presented.
vibesofecstasy wrote:I am also aware of jpeg formats that are also much smaller ... find a working one that is small so on this stupid intel celeron my game will be as good on the other unworked on computer.
IIRC, for fast processing (this is a game after all), the images used are first uncompressed into memory before being used for the rendering of the game. This means that heavily compressed images will gain you a few kbytes on disk, require more time to decompress when loaded, and will not free any amount of RAM during execution.
Lowering the size of the textures on the other hand will lower the memory requirement, probably render faster, but will produce a somewhat degraded visual effect. For better results, be sure to keep the size of the textures to powers of 2 (or "powers of 2" + 2)
Seeing as I'd guess your celeron doesn't have under 32 megs of RAM, I dont think trying to free some of it will result in any performance gain (beside the one mentionned). So this leave disk usage. Pulling values out of the air, I'd guess that the moviepack uses 1 meg of disk (probably much less, but lets keep that value). If you half all the dimensions of all the textures, what remains should use about 250k, freeing 750k in the process. The real question is, are you so short on disk space that this 750k would matter? And wouldn't just filling a floppy (1.44 megs, about twice as much at the space gained here) with documents you dont require often be a much better gain (and gain per time invested)?
This seems a bit extreme. Care to enlighten us with some specific details of your set-up?
/ph
Canis meus id comedit.
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
I would define compression like so:
In raw data, there is a 1:1 relationship between each byte of data stored and each byte of data in the original. So if there's a byte for every sample, that's raw data. So compressed data is obviously when you try to screw with that ratio in order to get a smaller file size.
I know, adpcm is called "compressed wav", so I'm willing to ignore the point and move on. I'm also willing to look at tests and a link someone might show me that shows that adpcm is well supported in linux and os x, but not terribly willing to do it. 16 bits to 14 bits is 4:1, and we can get higher compression ratios with ogg vorbis.
In raw data, there is a 1:1 relationship between each byte of data stored and each byte of data in the original. So if there's a byte for every sample, that's raw data. So compressed data is obviously when you try to screw with that ratio in order to get a smaller file size.
I know, adpcm is called "compressed wav", so I'm willing to ignore the point and move on. I'm also willing to look at tests and a link someone might show me that shows that adpcm is well supported in linux and os x, but not terribly willing to do it. 16 bits to 14 bits is 4:1, and we can get higher compression ratios with ogg vorbis.
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm
-
- Adjust Outside Corner Grinder
- Posts: 2003
- Joined: Tue Nov 07, 2006 6:02 pm
- Location: paris
- Contact:
http://wiki.armagetronad.net/index.php? ... on_effectsLucifer wrote:We have a list of sound effects needed somewhere
-
- On Lightcycle Grid
- Posts: 10
- Joined: Fri Sep 14, 2007 7:32 pm