Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!csd4.csd.uwm.edu!info-high-audio-request From: 09nilles%cuavax.dnet@netcon.cua.edu (Fiver Toadflax) Newsgroups: rec.audio.high-end Subject: Re: data compression Message-ID: <12149@uwm.edu> Date: 15 May 91 12:48:18 GMT Sender: news@uwm.edu Lines: 40 Approved: tjk@csd4.csd.uwm.edu Originator: tjk@csd4.csd.uwm.edu > From: sethb@fid.Morgan.COM (Seth Breidbart) > Subject: Re: data compression > Date: 8 May 91 22:25:26 GMT > > And sometimes they just can't compress a file at all. But at least no > data is lost, so who cares? But with music, I want one second of > music per second. If this current second happens to be hard to > compress, I don't want to wait 3 seconds to hear it. This is a matter of 'horse power' and only a real problem when actually encoding the music. Decodeing can be done faster on the same machine or just as quickly on a slower machine. > >And there is no difference > >between a CD with music recorded on it then the CD ROMS used by computers. > >I mean that both are simply a long string of 1's and 0's. So a well written > >compression routine should not have, on the average any data loss. > ^^^^^^^ > > What do you mean? Either it can lose data or it can't. If it > sometimes loses data, it can't make up for it by gaining data > somewhere else. (How else would you "not lose data on the average"?) What I mean by that is that not all the data/music is going to appear as a worst case situation where it takes at least as much space to encode as it takes up unencoded. So it will loose data when those worst case situations are encountered. But on average the music is not a worst case and then no data would be lost. Dave +-----------------------------------------+ | 09nilles@cuavax.dnet.cua.edu | | Fiver.Toadflax@f329.n109.z1.FIDONET.ORG | +-----------------------------------------+ Money Talks. Mine Only knows how to say bye.