Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!usc!bloom-beacon!eru!luth!sunic!draken!d88-jwa From: d88-jwa@nada.kth.se (Jon W{tte) Newsgroups: comp.dsp Subject: Re: Adjust-Speed CD player?? Message-ID: <1755@draken.nada.kth.se> Date: 24 Sep 89 11:23:34 GMT References: <6028@jpl-devvax.JPL.NASA.GOV> <89255.105143P85025@BARILVM.BITNET><7767@microsoft.UUCP> <89264.171306P85025@BARILVM.BITNET> <8909@batcomputer.tn.cornell.edu> <7814@microsoft.UUCP> Reply-To: d88-jwa@nada.kth.se (Jon W{tte) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 24 In article <7814@microsoft.UUCP> brianw@microsoft.UUCP (Brian Willoughby) writes: >In article <8909@batcomputer.tn.cornell.edu> sandell@tcgould.tn.cornell.edu (Gregory Sandell) writes: >On a side note, I have heard that someone has developed a compression >scheme to fit sixteen times as much data on a CD as is currently done. >The problem with storing sixteen times as much sound on a CD is that >the CD must still be accessed at the data rates it was designed for. >In other words, they are getting 16 times too much data at any given >time. Solution: read the CD from front to back sixteen times, each time >converting a different block of data. Data frames on the CD format are >broken into 16 blocks, and the player just cycles through these. No no. You still have exatly as many bits on the CD as before, only, the redundancy of the info kept there is minimized. If you read the CD at the original speed, and decompres it quickly enough, you'll have 16 times higher sampling speed, not 16 times longer play... The problem is; there's no standard. You can't get your CD player to recognize the compressed input, but if it's doable in real time, sampling synthesizers would benefit from this. h+@nada.kth.se -- Today is the tomorrow you worried about yesterday