Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!info-high-audio-request From: sethb@fid.Morgan.COM (Seth Breidbart) Newsgroups: rec.audio.high-end Subject: Re: data compression Message-ID: <11990@uwm.edu> Date: 9 May 91 12:54:42 GMT Sender: news@uwm.edu Lines: 37 Approved: tjk@csd4.csd.uwm.edu Originator: tjk@csd4.csd.uwm.edu In article <11954@uwm.edu> 09nilles%cuavax.dnet@netcon.cua.edu (Fiver Toadflax) writes: >> From: "William K. McFadden" >> This isn't as irrational as you might think. The problem with the DCC >> compression scheme is that signal degradation occurs with each >> encoding. >I haven't seen the details(algorithm) of the DCC compression scheme, but >if it is any decient, nothing will be lost. I've read articles about it in the popular press (e.g. stereophile). DCC is a lossy compression scheme. It has to be. > Afterall, look at programs >such as PCZIP, UUencode, compress. ALL of those programs take programs, >ASCII text files, etc and shrink them. Some better then others. But >no data is lost unless the file gets corrupted. 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. > 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"?) Seth sethb@fid.morgan.com