Xref: utzoo comp.compression:433 alt.comp.compression:226 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!carbon!stanford.edu!snorkelwacker.mit.edu!ai-lab!life!tmb From: tmb@ai.mit.edu (Thomas M. Breuel) Newsgroups: comp.compression,alt.comp.compression Subject: Re: Compression of 16-bit sound files. Message-ID: Date: 22 Apr 91 03:12:00 GMT References: <1991Apr21.002203.4414@nntp-server.caltech.edu> <1991Apr21.020231.8109@bmerh408.bnr.ca> <9741@castle.ed.ac.uk> Sender: news@ai.mit.edu Organization: MIT Artificial Intelligence Lab Lines: 14 In-reply-to: aipdc@castle.ed.ac.uk's message of 21 Apr 91 19:57:33 GMT One possibility: some parts of the music could be more compressible than others. That means that you might get 50k of data one second and 20k the next. But you can't change the speed the disc spins at quickly: you have to get the same amount of data in one second as the next. Therefore no compression. Data compression only speeds up transfers (for regions that compress poorly, you simply turn it off), so data compression never causes the disk reads to fall behind. On the other hand, and you can start/stop reading from a CD easily when data is coming in too fast. Maybe data compression would increase the amount of buffering needed somewhat, but it is unlikely that the effect would be large enough to make the use of data compression impractical even on low-end systems.