cd.htm

来自「各种文件格式说明及程序描述」· HTM 代码 · 共 498 行 · 第 1/2 页

    <br>
    the other type of track specified by the subchannel q control bit<br>
    field is the data track. these must conform to the cd-rom standard<br>
    described below. in general, a disc can have a mix of cd digital<br>
    audio tracks and a cd-rom track, but the cd-rom track must come first.<br>
    <br>
    editorial: this first level error correction (the only type used for<br>
    cd audio data) is extremely powerful. the cd specification allows for<br>
    discs to have up to 220 raw errors per second. every one of these<br>
    errors is (almost always) perfectly corrected by the circ scheme for a<br>
    net error rate of zero. for example, our tests using apple's cd-rom<br>
    drive (which also plays audio) show that raw error rates are around<br>
    50-100 per second these days. of course, these are perfectly<br>
    corrected, meaning that the original data is perfectly recovered. we<br>
    have tested flawed discs with raw rates up to 300 per second. net<br>
    errors on all of these discs? zero! i would expect a typical audio<br>
    cd player to perform similarly. thus i expect this raw error rate to<br>
    have no audible consequences.<br>
    <br>
    so why did i say &quot;almost always&quot; corrected above? because a<br>
    sufficiently bad flaw may produce uncorrectable errors. these very<br>
    unusual errors are &quot;concealed&quot; by the player rather than corrected.<br>
    note that this concealment is likely to be less noticeable than even a<br>
    single scratch on an lp. such a flaw might be a really opaque finger<br>
    smudge; cds do merit careful handling. on the two (and only two)<br>
    occasions i have found these, i simply sprayed on a little windex<br>
    glass cleaner and wiped it off using radial strokes. this restored<br>
    the cds to zero net errors.<br>
    <br>
    one can argue about the quality of the process of conversion of analog<br>
    music to and from digital representation, but in the digital domain<br>
    cds are really very, very good.<br>
    <br>
    <br>
    cd-rom data tracks<br>
    <br>
    each cd-rom data track is divided into individually addressable blocks<br>
    of 2352 data bytes, i.e. one subcoding block or 98 frames. a header<br>
    in each block contains the block address and the mode of the block.<br>
    the block address is identical to the encoding of minute, second, and<br>
    frame number in subcode channel q. the modes defined in the cd-rom<br>
    specification are:<br>
    <br>
    mode 0 -- all data bytes are zero.<br>
    <br>
    mode 1 -- (cd-rom data):<br>
    sync field - 12 bytes<br>
    header field - 4<br>
    user data field - 2048<br>
    error detection code - 4<br>
    reserved - 8<br>
    error correction - 276<br>
    <br>
    mode 2 -- (cd audio or other data):<br>
    sync field - 12 bytes<br>
    header field - 4<br>
    user data field - 2048<br>
    auxiliary data field - 288<br>
    <br>
    thus, mode 1 defines separately addressable, physical 2k byte data<br>
    blocks making cd-rom look at this level very similar to other digital<br>
    mass storage devices.<br>
    <br>
    <br>
    second level error correction<br>
    <br>
    an uncorrected error in audio data typically results in a brief, often<br>
    inaudible click during listening at worst. an uncorrected error in<br>
    other kinds of data, for example program code, may render a cd<br>
    unusable. for this reason, cd-rom defines a second level of error<br>
    detection and error correction (edc/ecc) for mode 1 data. the<br>
    information for the edc/ecc occupies most of the auxiliary data field.<br>
    <br>
    the error detection code is a cyclic redundancy check (crc) on the<br>
    sync, header, and user data. it occupies the first four bytes of the<br>
    auxiliary data field and provides a very high probability that<br>
    uncorrected errors will be detected. the error correction code is<br>
    essentially the same as the first level error correction in that<br>
    interleaving and reed-solomon coding are used. it occupies the final<br>
    276 bytes of the auxiliary data field.<br>
    <br>
    editorial: this extra level of error correction for cd-rom blocks is<br>
    one of the many reasons that cd-rom drives are much more expensive<br>
    than consumer audio players. to perform this error correction quickly<br>
    requires substantial extra computing power (sometimes a dedicated<br>
    microprocessor) in the drive.<br>
    <br>
    this is also one reason that consumer players like the magnavoxes<br>
    which claim to be cd-rom compatible (with their digital output jack on<br>
    the back) are useless for that purpose. they have no way of dealing<br>
    with the cd-rom error correction. they also have no way for a<br>
    computer to tell them where to seek.<br>
    <br>
    another reason that cd-rom drives are more expensive is that they are<br>
    built to be a computer peripheral rather than a consumer device, i.e.<br>
    like a combination race car/truck rather than a family sedan. one<br>
    story, probably apocryphal but not far from the truth, has it that a<br>
    major japanese manufacturer tested some consumer audio players to<br>
    simulate computer use: they made them seek (move the optical head)<br>
    from the inside of the cd to the outside and back again. these are<br>
    called maximum seeks. the story says they managed to do this for<br>
    about 24 hours before they broke down. a cd-rom drive needs to be<br>
    several orders of magnitude more robust. fast and strong don't come<br>
    cheap.<br>
    <br>
    <br>
    the high sierra file system standard<br>
    <br>
    built on top of the addressable 2k blocks that the cd-rom<br>
    specification defines, the next higher level of data encoding is a<br>
    file system that permits logical organization of the data on the cd.<br>
    this can be a native file system like the macintosh hierarchical file<br>
    system (hfs). another alternative is the high sierra (also known as<br>
    the iso 9660) file standard, recently approved by the national<br>
    information standards organization (niso) and the international<br>
    standards organization (iso), which defines a file system carefully<br>
    tuned to cd characteristics. in particular:<br>
    <br>
    1. cds have modest seek time and high capacity. as a result, the<br>
    high sierra standard makes tradeoffs that reduce the number of seeks<br>
    needed to read a file at the expense of space efficiency.<br>
    <br>
    2. cds are read-only. thus, concerns like space allocation, file<br>
    deletion, and the like are not addressed in the specification.<br>
    <br>
    for high sierra file systems, each individual cd is a volume. several<br>
    cds may be grouped together in a volume set and there is a mechanism<br>
    for subsequent volumes in a set to update preceding ones. volumes can<br>
    contain standard file structures, coded character set file structures<br>
    for character encoding other than ascii, or boot records. boot<br>
    records can contain either data or program code that may be needed by<br>
    systems or applications.<br>
    <br>
    <br>
    high sierra directories and files<br>
    <br>
    the file system is a hierarchical one in which directories may contain<br>
    files or other directories. each volume has a root directory which<br>
    serves as an ancestor to all other directories or files in the volume.<br>
    this dictates an overall tree structure for the volume.<br>
    <br>
    a typical disadvantage in hierarchical systems is that to read a file<br>
    (which must be a leaf of the hierarchy tree) given its full path name,<br>
    it is necessary to begin at the root directory and search through each<br>
    of its ancestral directories until the entry for the file is found.<br>
    for example, given the path name<br>
    <br>
    wine regions:america:california:mendocino<br>
    <br>
    three directories (the first three components of the path name) would<br>
    need to be searched. typically, a separate seek would be required for<br>
    each directory. this would result in relatively poor performance.<br>
    <br>
    to avoid this, high sierra specifies that each volume contain a path<br>
    table in addition to its directories and files. the path table<br>
    describes the directory hierarchy in a compact form that may be cached<br>
    in computer memory for optimum performance. the path table contains<br>
    entries for the volume's directories in a breadth-first order;<br>
    directories with a common parent are listed in lexicographic order.<br>
    each entry contains only the location of the directory it describes,<br>
    its name, and the location in the path table of its parent. this<br>
    mechanism allows any directory to be accessed with only a single cd<br>
    seek.<br>
    <br>
    directories contain more detailed information than the path table.<br>
    each directory entry contains:<br>
    <br>
    directory or file location.<br>
    file length.<br>
    date and time of creation.<br>
    name of the file.<br>
    flags:<br>
    whether the entry is for a file or a directory.<br>
    whether or not it is an associated file.<br>
    whether or not it has records.<br>
    whether or not it has read protection.<br>
    whether or not it has subsequent extents.<br>
    interleave structure of the file.<br>
    <br>
    interleaving may be used, for example, to meet realtime requirements<br>
    for multiple files whose contents must be presented simultaneously.<br>
    this would happen if a file containing graphic images were interleaved<br>
    with a file containing compressed sound that describes the images.<br>
    <br>
    files themselves are recorded in contiguous (or interleaved) blocks on<br>
    the disc. the read-only nature of cd permits this contiguous<br>
    recording in a straightforward manner. a file may also be recorded in<br>
    a series of noncontiguous extents with a directory entry for each<br>
    extent.<br>
    <br>
    the specification does not favor any particular computer architecture.<br>
    in particular all significant, multibyte numbers are recorded twice,<br>
    once with the most significant byte first and once with the least<br>
    significant byte first.<br>
    <br>
    <br>
    multimedia information<br>
    <br>
    using the file system are applications that create and portray<br>
    multimedia information. while it is true that a cd can store anything<br>
    that a magnetic disk can store (and usually much more of it), cds will<br>
    be used more for storing information than for storing programs. it is<br>
    the very large storage capacity of cds coupled with their low cost<br>
    that opens up the possibilities for interactive, multimedia<br>
    information to be used in a multitude of ways.<br>
    <br>
    programs like hypercard, with it's ease of authoring and broad<br>
    extensibility, are very useful for this purpose. hypercard stacks,<br>
    with related information such as color images and sound, can be easily<br>
    and inexpensively stored on cds despite their possibly very large<br>
    size.<br>
    <br>
    editorial: the high sierra file system gets its name from the location<br>
    of the first meeting on it: the high sierra hotel at lake tahoe. it<br>
    is much more commonly referred to as iso 9660, though the two<br>
    specifications are slightly different.<br>
    <br>
    it has gotten very easy and inexpensive to make a cd-rom disc (or<br>
    audio cd). for example, you can now take a macintosh hard disk and<br>
    send it with $1500 to one of several cd pressers. they will send you<br>
    back your hard disk and 100 cds with exactly the same content as<br>
    what's on your disk. this is the easy way to make cds with capacity<br>
    up to the size of your hard disk (apple's go up to 160 megabytes).<br>
    true, this is not a full cd but cds don't need to be full. if you<br>
    have just 10 megabytes and need 100 copies, cds may be the best way to<br>
    go.<br>
    <br>
    if you are buying a cd-rom drive, there are several factors you might<br>
    consider in making your choice. two factors not to consider are<br>
    capacity and data rate. the capacity of all cd-rom drives is<br>
    determined solely by the cd they are reading. though you will see a<br>
    range of numbers in manufacturers' specs (e.g. 540, 550, 600, and 650<br>
    mbytes), any drive can read any disc and so they are all fundamentally<br>
    the same. all cd-rom drives read data at a net 150 kbytes/sec for<br>
    cd-rom data. other data rates you may see may include error<br>
    correction data (not included in the net rate) or may be a mode 2 data<br>
    rate (faster than mode 1). all drives will be the same in all of<br>
    these specs.<br>
    <br>
    <br>
    end of article.</td>
  </tr>
</table>
</center></div>

<p align="center"><a href="../index.htm">返回</a></p>
</body>
</html>