Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transparent Differentiation of Compact Disk Types

IP.com Disclosure Number: IPCOM000106549D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 120K

Publishing Venue

IBM

Related People

Arrindell, CJ: AUTHOR [+2]

Abstract

Described is a software implementation that provides transparent access to compact disks (CDs) so as to differentiate between various types of CD formats. Four possible solutions are analyzed with a final workable and practical solution proposed in the determination of CD types.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

Transparent Differentiation of Compact Disk Types

      Described is a software implementation that provides
transparent access to compact disks (CDs) so as to differentiate
between various types of CD formats.  Four possible solutions are
analyzed with a final workable and practical solution proposed in the
determination of CD types.

      With the advent of the CD read only memory (ROM) extended
architecture (XA) data format for CDROM disks, mixed media CD
applications can be recorded in a mixture of CDROM-XA and CD digital
audio (DA) data format.  As a result, the CDROMs must be set to the
proper data mode, by means of software, before the data can be
accessed.  Four possible solutions for the determination of the CD
mode are analyzed followed by a workable and practical solution, as
follows:

1.  Add an interface to set the mode - This would be a call from the
    application software to the device driver to set the data mode
    appropriately before requesting the read of the data from the
    disk.  However, this approach could be unacceptable because it
    places too much of a burden on the application.  Either the
    application would need to know the full track layout in advance,
    or it would have to use a trail and error method to get the data.
    If an error is evident, the application would have to reset the
    mode and try again.

2.  Add an interface to query the mode - This would be in addition to
    item 1) above.  The application would query and then set the data
    mode, if necessary, before performing a read operation.  This
    would eliminate the trial and error part of the previous possible
    solution.  However, the overhead of the extra calls to the device
    driver would probably impact performance for most CDROM
    applications causing too much of a burden on the application.

3.  Device driver trial and error - Moving the trial and error method
    into the device driver would be an improvement because it makes
    the data mode setting transparent to the application.
    Unfortunately, this would be unacceptable because the device
    driver is unable to differentiate a CDROM from a CDROM-XA using
    error conditions alone.  Under certain circumstances, the driver
    will not generate an error if a CDROM track is read in a CDROM-XA
    data mode.  The result is garbled data.  In order for the trial
    and error method to work, the device driver would need to know
    the type of compact disk ahead of time.

4.  Device driver reads the header - Here the driver would need to
    issue a read-header command to the device prior to issuing the
    data read command.  If indicated, the data mode would be changed
    by the device driver and then the data read command would be
    issued.  This solution would be unacceptable because it
    significantly impacts the maximum achievable data rate for the
...