Xref: utzoo comp.compression:419 alt.comp.compression:219 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!dce From: dce@smsc.sony.com (David Elliott) Newsgroups: comp.compression,alt.comp.compression Subject: Re: Compression of 16-bit sound files. Message-ID: <1991Apr21.162259.2092@smsc.sony.com> Date: 21 Apr 91 16:22:59 GMT References: <1991Apr17.140822.23647@thebox.rain.com> <1991Apr21.002203.4414@nntp-server.caltech.edu> Organization: Sony Microsystems Corp, San Jose, CA Lines: 23 In article <1991Apr21.002203.4414@nntp-server.caltech.edu> madler@nntp-server.caltech.edu (Mark Adler) writes: >They use Reed-Solomon codes. As I recall, it is a 3/4 rate (which means >one-fourth of the bits are for error-correction) 6-bit symbol code, with >some amount of interleaving. These codes have excellent burst correction >capabilities, so macroscopic scratches in the CD result in no loss of >data. Correct. According to Pohlmann, all of the interleaving, multiple error-correction sets (before and after interleaving), and the eight-to-fourteen modulation (EFM) used to make the difference between the number of 1's and 0's small make the actual audio data on an audio CD about 1/4 the possible data space on a CD. The results are that a CD player that handles all of the levels of error correction can correct a bad burst of 3874 bits (2.5mm) or conceal a bad burst of 13,282 bits (7.7mm). On the compression side, I suspect that when the audio CD was being designed that processor technology wasn't advanced enough. The extra costs of adding a processor to do the decompression were probably just too high. The same types of problems befell MIDI.