Return to the archive index

Re: Hardware Sound Compression?

1 bit Ato D is simple... at the clock rate a 1 means go up in voltage while
0 means go down in voltage.  each 1 brings the signal voltage out up 1mv
(or whatever step they have) and each 0 brings it down the same so a sine
wave would be 111111101010000000000101011111111101010000000001010111111
It is actually a crappy way of doing AtoD but is extremely cheap.

----------
> From: 
> To: 
> Cc: Wearable Computers Mailing List <>
> Subject: Re: Hardware Sound Compression?
> Date: Monday, November 02, 1998 8:56 AM
> 
> On Sun, 1 Nov 1998, Rodney Arne Karlsen wrote:
> 
> > I think if you converted the audio to 1bit information like in an audio
CD
> > that would bring down the size. 1 bit  vs. 16 bit at same quality. I am
not
> > shure how the 1 bit DAC works, baybe somone in the group could explain
it to
> > us.
> 
> I'm not sure about how 1-bit DAC works, either, although I suspect that
it
> is something that decreases a manufacturer's costs more than it increases
> sounds quality. I think they put it on portable CD players for purely
> marketing reasons, eg. "Now with 1-bit DAC and Fritzen Jammin circuits!"
> In any case, CDs still store the audio information in 16 bit per sample
> per channel, 44,000 (or is it 48,000? I forget) samples per second. Sum
> total: about 10MB per minute of music.
> 
> There are only two ways to decrease the storage requirements for sound
that
> I know of. The first is the easiest. You simply decrease the sample size
> and/or rate. This has the obvious effect of decreasing quality as well.
> However, in a wearable, CD-quality audio is probably not the biggest
> concern, and telephone-quality audio would be acceptable for verbal
alerts
> and such, and is relatively low bandwidth.
> 
> The other way to decrease your storage requirements is to go the route of
> mp3s (MPEG-II, layer three, to be precise), which uses perceptual
encoding.
> This is the process of removing the parts of the sound that we know from
> experience that a human won't be able to hear. To use a slightly flawed
> example, if you recorded the sound of a pin dropping on a table, you'd be
> able to hear that in the playback; and if you recorded a brick dropping
on
> the same table, you'd be able to hear that in the playback as well; but
if
> you recorded the pin and the brick dropping at the same time, you
probably
> wouldn't be able to hear the sound of the pin over the sound of the
brick.
> So, why encode the sound of the pin in the first place? To achieve this,
mp3
> encoding breaks up the signal into 40 different frequency bands, and cuts
> the sound into 70 (or is it 72?) frames a second. It performs this
> pin-vs-brick comparison on all the frequency bands in each frame.
> The problem with perceptual encoding is that it is processor-intensive.
As
> has been noted on this list, it would take a very fast processor to
encode
> CD-quality sound at realtime, and it takes at least a Pentium-100 or so
to
> decode the same in realtime. Not to mention patent problems with the
> Fraunhofer Institute.
> 
> I hope I didn't bore those of you who already know this. I wanted to
> get it out there for everyone, just in case.
> 
> Paul Archer
> 
> ----------------------------------------------------
> A key to the understanding of all religion is that
> a god's idea of amusement is Snakes And Ladders with
> greased rungs.   -- Terry Pratchett, "Wyrd Sisters"
> ----------------------------------------------------
> 
> --
> Subcription/unsubscription/info requests: send e-mail with subject of
> "subscribe", "unsubscribe", or "info" to 
> Wear-Hard Mailing List Archive (searchable): http://wearables.ml.org

--
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to 
Wear-Hard Mailing List Archive (searchable): http://wearables.ml.org

From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty

Archive created with babymail