All, just been catching up on the discussions on CDP versus HDD in this thread and thought that I would just post this snippet from the CD Paranoia FAQ (http://www.xiph.org/paranoia/faq.html) which kind of opened my eyes to what is actually involved in a Red Book Audio CD playback system (admittedly in a CROM context, but the same problems will have to be addressed in a dedicated audio machine):-
--------------------------------------- I can play audio CDs perfectly; why is reading the CD into a file so difficult and prone to errors? It's just the same thing. Unfortunately, it isn't that easy. The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec. When the CD is being played as audio, it is not only moving at 1x, the drive is keeping the media data rate (the spin speed) exactly locked to playback speed. Pick up a portable CD player while it's playing and rotate it 90 degrees. Chances are it will skip; you disturbed this delicate balance. In addition, a player is never distracted from what it's doing... it has nothing else taking up its time. Now add a non-realtime, (relatively) high-latency, multitasking kernel into the mess; it's like picking up the player and constantly shaking it. CDROM drives generally assume that any sort of DAE will be linear and throw a readahead buffer at the task. However, the OS is reading the data as broken up, seperated read requests. The drive is doing readahead buffering and attempting to store additional data as it comes in off media while it waits for the OS to get around to reading previous blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA restrictions), one has to get off 208 read requests a second, minimum without any interruption, to avoid skipping. A single swap to disc or flush of filesystem cache by the OS will generally result in loss of streaming, assuming the drive is working flawlessly. Oh, and virtually no PC on earth has that kind of I/O throughput; a Sun Enterprise server might, but a PC does not. Most don't come within a factor of five, assuming perfect realtime behavior. To keep piling on the difficulties, faster drives are often prone to vibration and alignment problems; some are total fiascos. They lose streaming *constantly* even without being interrupted. Philips determined 15 years ago that the CD could only be spun up to 50-60x until the physical CD (made of polycarbonate) would deform from centripetal force badly enough to become unreadable. Today's players are pushing physics to the limit. Few do so terribly reliably. Note that CD 'playback speed' is an excellent example of advertisers making numbers lie for them. A 36x cdrom is generally not spinning at 36x a normal drive's speed. As a 1x drive is adjusting velocity depending on the access's distance from the hub, a 36x drive is probably using a constant angular velocity across the whole surface such that it gets 36x max at the edge. Thus it's actually spinning slower, assuming the '36x' isn't a complete lie, as it is on some drives. Because audio discs have no headers in the data to assist in picking up where things got lost, most drives will just guess. This doesn't even *begin* to get into stupid firmware bugs. Even Plextors have occasionally had DAE bugs (although in every case, Plextor has fixed the bug *and* replaced/repaired drives for free). Cheaper drives are often complete basket cases. Rant Update (for those in the know): Several folks, through personal mail and on Usenet, have pointed out that audio discs do place absolute positioning information for (at least) nine out of every ten sectors into the Q subchannel, and that my original statement of +/-75 sectors above is wrong. I admit to it being misleading, so I'll try to clarify. The positioning data certainly is in subchannel Q; the point is moot however, for a couple of reasons. 1. The SCSI and ATAPI specs (there are a couple of each, pick one) don't give any way to retrieve the subchannel from a desired sector. The READ SUB-CHANNEL command will hand you Q all right, you just don't have any idea where exactly that Q came from. The command was intended for getting rough positioning information from audio discs that are paused or playing. This is audio; missing by several sectors is a tiny fraction of a second. 2. Older CDROM drives tended not to expect 'READ SUB-CHANNEL' unless the drive was playing audio; calling it during data reads could crash the drive and lock up the system. I had one of these drives (Apple 803i, actually a repackaged Sony CD-8003). 3. MMC-2 *does* give a way to retrieve the Q subchannel along with user data in the READ CD command. Although the drive is required to recognize the fetaure, it is allowed to simply return zeroes (effectively leaving the feature unimplemented). Guess how many drives actually implement this feature: not many. 4. Assuming you *can* get back the subchannel, most CDROM drives seem to understand audio discs primarily at the "little frame" level; thus sector-level structures aren't reliable. One might get a reassembled subQ, but if the read began in the middle of a sector (or dropped a little frame in the middle; many do), the subQ is likely corrupt and useless. As reassembling uncorrupted frames is easy without the subchannel, and corrupted reads likely result in a corrupted subchannel too, cdparanoia treats the subchannel as more trouble than it's worth (during verification). At least one other package (Exact Audio Copy for Win32) manages to use the subchannel to enhance the Table of Contents information. I don't know if this only works on MMC-2 drives that support returning Q with READ CD, but I think I'm going to revisit using the subchannel for extra TOC information. -- alexfiennes ------------------------------------------------------------------------ alexfiennes's Profile: http://forums.slimdevices.com/member.php?userid=4286 View this thread: http://forums.slimdevices.com/showthread.php?t=22301 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
