what are some of the methods that are used to compress audio?

[Modus]

Sorry to be a party pooper, but the bit-reduction method you describe wouldn't work either. Why?

Well, when an audio player reads the file, it assumes that each sound is a 16 bit integer. For sure, you could store some of the values as 15 bit integers and just throw them into the data stream, but the problem is that the audio player has to KNOW when it is reading a 15 bit value as opposed to a 16 bit one.

Remember, to the player, the file is just a long stream of 0's and 1's, which get grouped into chunks of 16. So to tell the player the next value is a 15bit integer as opposed to a 16 bit one, you'd have to use some kind of flag. At the very best, this flag would be one bit long, using 0 to denote a 16 bit value would follow, and 1 to denote a 15 bit value would follow. But of course this defeats the purpose, because even the 16 bit values would have to have this flag in front to differentiate them. In fact, the data stream would actually take MORE space, because each value would effectively be either 17 or 16 bits.

Modus

 

[Becks2k]

Hmm the problem with the above way is when you get past 512 or 9bits, alot of the numbers are just duplicates 512 and 511 are the same for example, it gets worse the more bits you use.

If instead of dividing 65536 by the number and instead do this....

When the number isn't 16bits it take that number, X, and does 6.5536*X. This you could use a 13bit number and each one would work, all 8192, 8192/65536 = 12.5%

Actually it would be more because a 13bit number would give you 8192 possibilities, but it could be a 12bit number. if you add up 2^1+2^2+2^3 up to ^13 you get 16382 diff numbers, 25% of 2^16. ALot of those would overlap one way or anohter, but you could make the equation even more complex, if it is a 13bit number you do 6.5536*X and if its a 12bit you would do 65536-6.5536X and you would eleminat alot of the duplicates.

--edit--
Awe i thought about how it knew when one number ended and the next began but I was having fun hehe, oh well.

 

[kuk]

Some quick math here, and it's late at night here where I am, correct me if i'm wrong, plzzz:

0.08% of 170Kb/s = 1,36

50% of 1,35 = 0,68

170kb/s - 0,68 = 169,32kb/s


Maybe there's something I didn't pick up there ... probably I'm insane. But for me it makes sense.

 

[Soccerman]

heh my question on number crunching was to be sure that it would only be .08% or whatever that number was! sorry bout being vague..

now, we're not talking any normal playback system first of all.

second of all, how does a player distinguish every 16 bits from each other? does it just count? wouldn't that be prone to lots of errors?

if it just counts every 16 bits, then yeah, it would be alot more difficult to just reduce the bit count, however there are probably ways around this (by including certain logic algorithms in the decoder, rather then tacking it into the audio file).