Audio Compression...

Alright, I'm a bit  on this...

In a 44,100hz 16-bit mono channel, there's approximately
1,740,509,884,615,490,592,578 different audio possibilities per 10,000th
of a second (88,200 / 10,000 = 8.82 | 256^8.82).  I know the human ear
couldn't differentiate even a fraction of this many possibilities...
even in an ENTIRE SECOND.  So, with this stated... am I wrong to assume
that there's still ALOT to be gained in lossy audio compression?

Or, am I'm referencing to something that would be more of trying to
index all those audio possibilities?  Even if we only had a specific
library of 300,000 possible sounds per second, per channel... we'd have
to store 26,460,000,000 bytes for the dictionary (88,200 * 300,000).
This wouldn't be that beneficial; however, would it be impossible to
find a mathematical process to calculate (or some kind of mathematical
hash on a sample of audio) to differentiate similar sounds over a period
of time?

I hope I'm not confusing you in my post... and I hope that it's not too
far fetched!

"Eric D. Brown" <nospam@nowhere.com> :

> Alright, I'm a bit  on this...
>
> In a 44,100hz 16-bit mono channel, there's approximately
> 1,740,509,884,615,490,592,578 different audio possibilities per 10,000th
> of a second (88,200 / 10,000 = 8.82 | 256^8.82).  I know the human ear
> couldn't differentiate even a fraction of this many possibilities...
> even in an ENTIRE SECOND.  So, with this stated... am I wrong to assume
> that there's still ALOT to be gained in lossy audio compression?
>
> Or, am I'm referencing to something that would be more of trying to
> index all those audio possibilities?  Even if we only had a specific
> library of 300,000 possible sounds per second, per channel... we'd have
> to store 26,460,000,000 bytes for the dictionary (88,200 * 300,000).
> This wouldn't be that beneficial; however, would it be impossible to
> find a mathematical process to calculate (or some kind of mathematical
> hash on a sample of audio) to differentiate similar sounds over a period
> of time?
>
> I hope I'm not confusing you in my post... and I hope that it's not too
> far fetched!

No, you are just so far off that is not even funny.  Most sounds in reallife
don't have the waveforms jumping up and down at random.  The range of
possible sounds of interest to a human being is a fraction the possible
waveforms.  Compression software is designed for those types of sounds.  In
the case where there is true random/chaostic values in a waveform we just
used lossless recording techquinces.  Always remember also that the sampling
equipment's limits will do some filtering of the recorded sound also.

However in reallife even the limited range of sounds that humans are
interested will cover far more than your very limited 300,000 possible
sounds.  Remember you need to cover every possible sound a human may hear
from traffic noise, to speech, to singing, to musical instruments and lots
more and every combination of them all.  Never watched a movie with
background music, two people talking and the traffic noise fading out?
Earl Colby Pottinger

--
I make public email sent to me!  Hydrogen Peroxide Rockets, OpenBeos,
SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC.  What happened to
the time? http://webhome.idirect.com/~earlcp

Eric D. Brown wrote:

> Alright, I'm a bit  on this...
>
> In a 44,100hz 16-bit mono channel, there's approximately
> 1,740,509,884,615,490,592,578 different audio possibilities per 10,000th
> of a second (88,200 / 10,000 = 8.82 | 256^8.82).  I know the human ear
> couldn't differentiate even a fraction of this many possibilities...
> even in an ENTIRE SECOND.  So, with this stated... am I wrong to assume
> that there's still ALOT to be gained in lossy audio compression?
>
> Or, am I'm referencing to something that would be more of trying to
> index all those audio possibilities?  Even if we only had a specific
> library of 300,000 possible sounds per second, per channel... we'd have
> to store 26,460,000,000 bytes for the dictionary (88,200 * 300,000).
> This wouldn't be that beneficial; however, would it be impossible to
> find a mathematical process to calculate (or some kind of mathematical
> hash on a sample of audio) to differentiate similar sounds over a period
> of time?

Have you read about MP3? That is just one example of a lossy compression
algorithm that first throws out the parts of the sounds that most people can
not
differentiate.

Or are you thinking you might have an idea for a new algorithm?

> I hope I'm not confusing you in my post... and I hope that it's not too
> far fetched!

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

"Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10lpo5gprjnfg31@corp.supernews.
com>...
> In a 44,100hz 16-bit mono channel, there's approximately
> 1,740,509,884,615,490,592,578 different audio possibilities per 10,000th
> of a second (88,200 / 10,000 = 8.82 | 256^8.82).

I can't even begin to explain how screwed up your math is.  Where did
the "10,000th of a second" value come from and why is it factored into
your calculations?

In any digitized sound sampled at 44100 samples per second, there are
up to 22050 frequencies represented in that second.  This is standard
Nyquist.  With that in mind, try asking your question again.

Jim Leonard wrote:
> "Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10lpo5gprjnfg3
1@corp.supernews.com>...
> 
>
>
> I can't even begin to explain how screwed up your math is.  Where did
> the "10,000th of a second" value come from and why is it factored into
> your calculations?

I beg your pardon...

Is not 44,100 bytes x 16 bit = 88,200 bytes?

Is not 88,200 bytes (per second) / 10,000 (10,000th of a second) = 8.82
bytes per 10,000th of a second?

Is not 256^8.82 = approx. 1,740,509,884,615,490,592,578 different
possibilities?

My math is screwed up, eh?

>
> In any digitized sound sampled at 44100 samples per second, there are
> up to 22050 frequencies represented in that second.  This is standard
> Nyquist.  With that in mind, try asking your question again.

Yes, I understand that you need double the sampling rate of the desired
frequency (Nyquist), to reconstruct the frequency.  If there's 44,100
bytes per second recorded on a mono, 8-bit channel... then changing just
the LSB of 1 byte of the sample will change the sound (though, probably
not audible by the human ear).  That being said, refer back to my
original question.

It's great how somebody can ask a simple question in this place... and
quickly get thrown at with stones by those of you who think your shit
don't stink.  News flash:  Grab your next turd and stick it in your
nose... see how fast reality knocks your ass over!

Earl Colby Pottinger wrote:
> "Eric D. Brown" <nospam@nowhere.com> :
>
> 
>
>
> No, you are just so far off that is not even funny.  Most sounds in realli
fe
> don't have the waveforms jumping up and down at random.  The range of
> possible sounds of interest to a human being is a fraction the possible
> waveforms.  Compression software is designed for those types of sounds.  I
n
> the case where there is true random/chaostic values in a waveform we just
> used lossless recording techquinces.  Always remember also that the sampli
ng
> equipment's limits will do some filtering of the recorded sound also.
>
> However in reallife even the limited range of sounds that humans are
> interested will cover far more than your very limited 300,000 possible
> sounds.  Remember you need to cover every possible sound a human may hear
> from traffic noise, to speech, to singing, to musical instruments and lots
> more and every combination of them all.  Never watched a movie with
> background music, two people talking and the traffic noise fading out?
>                  Earl Colby Pottinger
>

Thanks Earl... BTW, the 300,000 index was just an example.  I know the
human ear can differentiate over 300,000 different audio samples within
a one-second duration.

trixter@despammed.com (Jim Leonard) writes:

> "Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10lpo5gprjnfg3
1@corp.supernews.com>... 
>
> I can't even begin to explain how screwed up your math is. Where did
> the "10,000th of a second" value come from and why is it factored into
> your calculations?

He came up with it. He's permitted to do that, it's his post.
What period of time should he have used as an example? If 1/44100-th of
a second then his figure would be 65536. If he used 1 second then the
figure would be 5.82*10^212406, and if he used 1/10000-th of a second,
which he did, then the figure is 1740509884615490592578.  He even
explains, using somewhat unusual punctuation and logic, where he got
the figure from - it's the parenthetical remark. (2^16)^(44100/10000)
would have been a more sensible remark, but both evaluate to the same
thing.

> In any digitized sound sampled at 44100 samples per second, there are
> up to 22050 frequencies represented in that second.  This is standard
> Nyquist.  With that in mind, try asking your question again.

You have a plank in your eye, sir. Try reading his post again.

Phil
--
They no longer do my traditional winks tournament lunch - liver and bacon.
It's just what you need during a winks tournament lunchtime to replace lost
... liver.   -- Anthony Horton, 2004/08/27 at the Cambridge 'Long Vac.'

"Eric D. Brown" <nospam@nowhere.com> :

> Alright, I'm a bit  on this...
>
> In a 44,100hz 16-bit mono channel, there's approximately
> 1,740,509,884,615,490,592,578 different audio possibilities per 10,000th
> of a second (88,200 / 10,000 = 8.82 | 256^8.82).  I know the human ear
> couldn't differentiate even a fraction of this many possibilities...
> even in an ENTIRE SECOND.  So, with this stated... am I wrong to assume
> that there's still ALOT to be gained in lossy audio compression?
>
> Or, am I'm referencing to something that would be more of trying to
> index all those audio possibilities?  Even if we only had a specific
> library of 300,000 possible sounds per second, per channel... we'd have
> to store 26,460,000,000 bytes for the dictionary (88,200 * 300,000).
> This wouldn't be that beneficial; however, would it be impossible to
> find a mathematical process to calculate (or some kind of mathematical
> hash on a sample of audio) to differentiate similar sounds over a period
> of time?
>
> I hope I'm not confusing you in my post... and I hope that it's not too
> far fetched!

No, you are just so far off that is not even funny.  Most sounds in reallife
don't have the waveforms jumping up and down at random.  The range of
possible sounds of interest to a human being is a fraction the possible
waveforms.  Compression software is designed for those types of sounds.  In
the case where there is true random/chaostic values in a waveform we just
used lossless recording techquinces.  Always remember also that the sampling
equipment's limits will do some filtering of the recorded sound also.

However in reallife even the limited range of sounds that humans are
interested will cover far more than your very limited 300,000 possible
sounds.  Remember you need to cover every possible sound a human may hear
from traffic noise, to speech, to singing, to musical instruments and lots
more and every combination of them all.  Never watched a movie with
background music, two people talking and the traffic noise fading out?
Earl Colby Pottinger

--
I make public email sent to me!  Hydrogen Peroxide Rockets, OpenBeos,
SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC.  What happened to
the time? http://webhome.idirect.com/~earlcp

Earl Colby Pottinger <earlcp@idirect.com> wrote in message news:<C9udnYDHQ8P-GMLcRVn-rg@loo
k.ca>...
> "Eric D. Brown" <nospam@nowhere.com> :
> 
>
> No, you are just so far off that is not even funny.  Most sounds in realli
fe
> don't have the waveforms jumping up and down at random.  The range of
> possible sounds of interest to a human being is a fraction the possible
> waveforms.  Compression software is designed for those types of sounds.  In[/color
]

I think that what he means is that the human ear can only hear that
many distinct sounds at any particular instant.  That in the normal
range of hearing, based on frequency (and 'other' stuff), the human
ear can only differentiate between "X" number of sounds.

Kind of like human sight.  It can only see around 16 million different
shandes of color.  By sheer chance, that works out pretty well with
computer's using 8 bits for each RGB, for a total of 24 bits, or a
total of 16,777,216 different colors.  Doing colors as 64 bits would
be a waste because no human could tell the difference.

A picture is made up of many of those seperate distictly visible
pixels.  Picture compression takes advantage of redundancy and
patterns.  Motion picture image compression takes advantage of
multiple frames and the similarities between them.  Including possibly
non-identical similarities.

I think he's saying that the human ear is a little like that.  With
what we call "sound" being made up of many instances of seperate
things.

And he's wondering if there was some way to take advantage of those
discrete sound events, and use some method to predict what the next
one would be, and so on.  And use things like that as a form of audio
compression.  Rather than basing it on more traditional methods, like
mp3 etc.

Kind of like compressing a regular text dictionary by using spelling
rules.

Or compressing a full book by using spelling and punctuation rules to
remove redundancy.  And then throw in a pkzip style dictionary based
compression method where previous snippets are stored for later use.
With a possible "lossy" nature to allow very similar snippets to be
used instead of identical snippets.


I'm not so sure of his numbers, or even that the idea is a good idea,
though.

"Eric D. Brown" <nospam@nowhere.com> :

> Thanks Earl... BTW, the 300,000 index was just an example.  I know the
> human ear can differentiate over 300,000 different audio samples within
> a one-second duration.

Ok, and Bumped has also pointed out to me that if appoached right with enoug
h
diffirent samples that there may be something to your idea, so don't give up
- Don't make the mistake that you are the new genuis of compression, but als
o
don't give up if you have the time, you may figure out something new too.

Earl Colby Pottinger


--
I make public email sent to me!  Hydrogen Peroxide Rockets, OpenBeos,
SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC.  What happened to
the time? http://webhome.idirect.com/~earlcp