PRB: Cannot Read Red Book Audio Sectors in Windows 95, Windows 98, and Windows Me (180115)



The information in this article applies to:

  • Microsoft Win32 Application Programming Interface (API), when used with:
    • the operating system: Microsoft Windows 95
    • the operating system: Microsoft Windows 98
    • the operating system: Microsoft Windows Millennium Edition

This article was previously published under Q180115

SYMPTOMS

Some applications read raw sectors from compact discs by calling the MSCDEX/CDFS Send Driver Request function (Int 2Fh, function 1510h) to issue a Read Long command (command code 128) to the CD-ROM driver.

The Read Long command correctly reads sectors on ISO 9660 and High-Sierra formatted discs. However, the Read Long command does not read sectors from Red Book Audio discs or sectors from the audio session of a multisesson disc. On such discs, the Read Long command returns a status word of 8102h, which means that the command completed, but there was a "Device Not Ready" error.

CAUSE

The Microsoft Windows 95, Windows 98, and Windows Millennium Edition (Me) CD-ROM file system driver (CDFS) supports the Read Long command only for ISO 9660 and High-Sierra discs (data discs). The Windows 95 CDFS does not support the Read Long command for Red Book Audio discs or the audio session of multisession discs.

RESOLUTION

Although the Windows 95, Windows 98, and Windows Me CDFS does not support reading Red Book Audio sectors, the Windows IO Subsystem does. It is possible to bypass CDFS by calling the IO Subsystem directly from a virtual device driver (VxD) or by calling WinASPI32.

Although applications cannot call IO Subsystem functions directly, they can call VxDs that call IO Subsystem functions. Therefore, to read audio sectors, you can write a VxD for your application to call. [Win32 applications use the DeviceIoControl() API to call VxDs; 16-bit Windows applications use interrupts.] When called by your application, your VxD should submit IOR_READ commands using the IORF_AUDIO_DATA_READ flag.

With this approach, your application can use drive letters, and the VxD will correlate the drive letter to IOS DCB. The I/O subsystem can then handle building and translating appropriate READ commands for the specific CD-ROM drive.

Alternatively, if you do not want to write a VxD, your application can call WinASPI32 to build raw READ compact disc command descriptor blocks (CDBs) (for ATAPI drives) or READ_CDDA CDBs (for SCSI drives) to submit to the drive. The drawback with this approach is that ASPI cannot correlate the ASPI device with its drive letter; therefore, the application must determine which READ command is correct for the CD-ROM drive.

MORE INFORMATION

Windows CD-ROM Support

Windows CD-ROM support consists of the Compact Disc File System (Cdfs.vxd), and the IO Subsystem. CDFS is the protected-mode replacement for Mscdex.exe; it supports the MSCDEX Int 2Fh interface so that 16-bit Windows and MS-DOS-based applications that call Mscdex.exe functions will work unmodified in Windows 95.

The IO Subsystem is a layered set of virtual device drivers that forms the low-level support for CDFS and other file systems (VFAT). In response to Int 2Fh MSCDEX function calls, CDFS calls the IO Subsystem to access the physical drive.

The IO Subsystem also handles all file system related calls that are destined for the CD-ROM drive. For example, requests to open a file on a compact disc and read its contents goes from the application to the IO Subsystem, which talks to the drive to get the data from the disc.

Because CDFS calls the IO Subsystem, and the IO Subsystem is layered, Windows was designed such that the IO subsystem can use either the built-in virtual device drivers to support CD-ROM drives, or an OEM-supplied real-mode CD-ROM driver. Thus, if a given CD-ROM drive is not supported directly by the protected-mode IO Subsystem components, it still may be used by Windows through the OEM-supplied driver.

Send Driver Request Behavior

Similar to MSCDEX, CDFS supports a special function, Send Driver Request (Int 2Fh, function 1510h), which passes application requests to the IO Subsystem. The purpose of this function is to allow applications to issue commands that are not supported by other MSCDEX functions (Int 2Fh, functions 1500h-1509h, 150Bh-150Fh). These commands usually include optional behavior that is specific to the capabilities of the drive, such as the "close tray" command supported by tray-based drives.

CD-ROM driver software is not required to support every command that can be sent via Send Driver Request. Usually, a CD-ROM driver supports a particular command only if the specific device for which it was designed supports the feature. If a CD-ROM driver does not support a particular command, it generally returns with a status word of 8102h, which means "the command completed with a Device Not Ready error."

CDFS can also return a status word of 8102h to signal that it did not pass the request to the CD-ROM driver.

Read Long Command Behavior

Applications issue the Read Long command (command code 128) by calling the MSCDEX Send Driver Request function (Int 2Fh, function 1510h). The Read Long command is designed to read "raw" (2352-byte) or "cooked" (2048-byte) sectors in HSG or REDBOOK addressing modes. (When reading raw sectors, only one sector at a time can be read.)

Windows only supports the Read Long command for reading raw and cooked sectors from ISO 9660 and High-Sierra discs in the HSG addressing mode.

Modification Type:MinorLast Reviewed:9/27/2004
Keywords:kbAPI kbKernBase kbnofix kbprb KB180115