LASER MAGNETIC STORAGE MEMO INTERNATIONAL _______________________________________________________________________ Optical Storage Division 17 July 1989 To: SCSI Standards Committee X3T9.2 From: Paul Boulay (719) 593-4323 Subject: CD-ROM Read Sub-channel Command Revision Revision Note: Rev. 0 of this document was handed out at the Chicago working group meeting (July 10 and 11). Rev. 1 incorporates the results of that discussion. It additionally provides the definition of the new Scan for Sub-channel Data command. The alternative 1 changes to the Read Sub-channel command now reflect the existence of the Scan for Sub-channel Data command. Soon after the June meeting, representatives from Sony Corporation contacted me with a proposal for a change in the CD-ROM command set Read Sub-channel command. The problem that they discovered involves returning the Media Catalog Number / Universal Product Code (MCN/UPC) and International Standard recording Code (ISRC) fields. With the definition in the current SCSI-2 draft users will find retrieving this data most inconvenient, but not impossible. This document is the result of my re-review of the command and the implementation implications of its current definition (and lack thereof). It covers some of the same points that Sony raises but from perhaps a different viewpoint. I do not purport to speak for Sony corporation - or for N.V. Philips for that matter. I'm just a SCSI-2 section editor -- made a bit more humble by recognizing that this whole mess slipped by me in the first place. I see three options: 1) Add a few carefully worded changes to the definitions and implementors notes to support this requirement within the framework of the present command. The intent is to change the character of the command from one that returns information from the current sector to one which returns the current set of information. The result could be workable. There are some implementation considerations that I view as minor but which others might not. After all, this is an optional command. The changes required are consistent with that which is already in the command. 2) Add an option to the command so a user can turn this into an active command which scans a portion of the media to either find a specifically requested sub-channel data type or show that it is not present. The user must still follow certain procedures to get all the sub-channel data that is present. This option involves a technical change to the standard and the risk that we haven't thought of all the implications. (This is the approach taken in the Sony proposal.) 3) Create a new Scan for Sub-channel Data command. This would be an active command with a starting LBA and a transfer length denominated in logical blocks. This command would scan a portion of the media to either find sub-channel data or report that it is not present. This option also involves a technical change to the standard with the attendant risks. In spite of all that, the use of an active command is the cleanest way for a user to access the data in the MCN/UPC and ISRC fields. At Chicago, we concluded that all of these alternatives represent a substantive change. We also concluded that the most correct technical solution is to incorporate parts of alternative 1 plus alternative 3. The read sub-channel command could be limited to two cases (1) during an audio play operation and (2) after a scan for sub-channel data command. ---------------------------------------------------------------------- Sub-Channel Data As with most CD-ROM specific problems, this one has its roots in the CD Audio format. (CD Audio is the basis for the CD-ROM format.) The data that the Read Sub-channel command retrieves comes from one of 8 low rate time multiplexed data streams which share space with the higher rate data or audio data stream. One of these, the Q sub- channel, encodes the information that the Read Sub-channel command returns. One Q sub-channel frame is encoded per data sector (2048 bytes plus ECC, etc.) or audio frame (1/75th second at standard rate). For at least 9 out of any 10 frames the Q sub-channel encodes absolute and relative location information. The remaining 1 of any 10 frames may optionally contain MCN/UPC or ISRC data. If an optional data item is present, it must appear in at least 1 of any 100 frames. Neither, either or both may be present. Problem 1 - Definition of current sector is too loose. The presently defined Read Sub-channel command can usually operate in a passive way. It simply returns the data from the current sector. If there is an on-going (background) audio operation that is easy. If the current state of the CD-ROM drive is audio pause, there is usually little difficulty in implementing the command. However, there may be some implementation dependent ambiguity in exactly which is the current sector. If current sector is defined to mean -- the sector at which the paused audio operation will resume -- this command may take a full rotation to return data. The other possibility is to take a looser interpretation of current sector -- the sector now sliding under the read head -- and return the data for that one. This results in minimal delay. The current sector is simply not defined between operations, say between Read commands. The natural interpretations are the same two as during the pause state. The -- sector at which the operation will be resumed -- definition is a little sticky when, for instance, the logical block size is less than the sector size and the last Read command completed somewhere in the middle of a sector. It can also be problematical when, for instance, the previous command ended at the last sector of a track. The looser definition -- the sector now sliding under the read head -- is easier and quicker to implement because the operation is exactly the same as a Read Sub-channel during a background audio operation. However, this may lead to inconsistent results when the set of sectors being read in this hold position operation includes sectors from two different tracks. Problem 2 - MCN/ISRC and ISRC data can be hard to obtain. The Read Sub-channel command now returns data from the current sector. The ISRC and MCN/UPC data items can be very difficult to obtain because they may appear in as few as 1 per 100 sectors. While playing audio as a background process (immediate bit set) it is probably reasonable to issue a Read Sub-channel command during 100 successive blocks. (Rate of 13.3 mS or less per sample.) However, when the drive is in a pause state 20 or fewer sectors will pass under the read head. Depending on the definition of 'current' adopted by the implementation, one or any of these may be read. The problem is that during an audio pause, no ISRC or MCN/UPC information might be found even though they exist on the current track. Data tracks incur additional problems. There is no defined pause state and no immediate type operation that proceeds in the background. Strictly speaking, 'current' is undefined between data operations. A Read Sub-channel command issued after a read command might be expected to behave like one issued during an audio pause, but there is no language in the spec that guarantees this. ---------------------------------------------------------------------- Proposed solutions Option 1. Modify definitions and add implementors notes. Most of these difficulties arise from the operation of the word 'current' in the command definition. Certainly, while an audio play progresses, the location data should be up to date. These other sub- channel data items either do not change (MCN/UPC) or only change at a track boundary (ISRC). Therefore, returning MCN/UPC and ISRC sub- channel data needs to meet a much looser currency requirement. The data must be correct for the area of the media that contains the current sector, it need not actually be from the current sector. The proposed interpretation of Read Sub-channel as applied to these particular fields is to supply information from the last appropriate sector encountered. By appropriate, I mean from the last sector that had that type of data on the track reported in the location part of the data. (This needs to be done for the ISRC field, the track dependency does not apply to the MCN/UPC field.) The implementation implication is that the drive or controller that supports this feature needs to keep an updated copy of these sub-channel data items as they are encountered. (For the ISRC field it would also have to keep a track number tag to be able to tell if this copy still applies to the current track.) -- Immediately following Table 13-17, delete 'current' from the command definition. Add Implementors note. This rewording also gets rid of the implication that this command is only valid during a background audio play operation. "The READ SUB-CHANNEL command (Table 13-17) requests that the target return requested sub-channel data plus the state of audio play operations as appropriate. This command shall return the sub-channel data read during an on-going audio play operation or the data read by a previous SCAN FOR SUB-CHANNEL DATA command. "IMPLEMENTORS NOTE: Sub-channel data returned by this command may be from the last appropriate sector encountered by a Play Audio or Scan for Sub-channel Data command. The target is responsible that the data returned are consistent. For example, the International Standard Recording Code (ISRC) data reported must have been read from the same track as the reported current position data." --Replace the 3rd paragraph following Table 13-19 (counting the implementers note). Make a distinction between the location information and the other sub-channel stuff. Permit reporting MCN/UPC and ISRC data from a previous appropriate block. Define current for the several possible cases. "The sub-channel data block consists of control data (bytes 4-5), current position data (bytes 6 - 15) and identification data (bytes 16 - 47). The control data and current position data is obtained from the sub-channel Q information of the current block. Identification data may be reported that was obtained from a previous block. If identification data is reported, the data shall be valid for the sector addressed by the current position data. "(1) If an audio play operation is proceeding in the background or is paused, position data for the last sector played shall be reported. "(2) If the last drive operation was a Scan for Sub-channel Data command, position data for the last sector scanned shall be reported. "(3) In other cases, for instance after a read or a seek operation, the target may report position data for the last sector processed by the drive." Option 2. Change the command to be an active command upon request. -- Use byte 3 of the CDB to specify the type of data being requested. --- 0 requests the present passive type operation. --- 1 requests a scan for track, index, absolute address and relative address information. --- 2 requests a scan for a MCN/UPC field. --- 3 requests a scan for an ISRC field. --- Other values reserved. -- The scan would start where the last operation left off and continue as needed to find the requested field or show that it does not appear. Option 3. New Scan for Sub-channel Data command. SCAN FOR SUB-CHANNEL DATA Command Table 13-xx: SCAN FOR SUB-CHANNEL DATA Command ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code (46h) | -----|-----------------------------------------------------------------------| 1 | Logical Unit Number | Reserved | -----|-----------------------------------------------------------------------| 2 | (MSB) | -----|--- ---| 3 | | -----|--- Starting Logical Block Address ---| 4 | | -----|--- ---| 5 | (LSB)| -----|-----------------------------------------------------------------------| 6 | Sub-channel Data Types | -----|-----------------------------------------------------------------------| 7 | (MSB) | -----|--- Transfer Length ---| 8 | (LSB) | -----|-----------------------------------------------------------------------| 9 | Control | ============================================================================== The SCAN FOR SUB-CHANNEL DATA Command (Table 13-xx) requests that the target read sub-channel data. Sub-channel information read by this command may be transferred to the initiator with a Read Sub- channel command. The starting logical block address field specifies the logical block at which the sub-channel scan shall begin. The sub-channel data types field indicates the sub-channel data item(s) to be located by the scan operation. The scan shall be stopped as soon as all the requested information items have been read. If this field is zero, the scan shall continue until the Transfer Length request is satisfied. Table 13-yy: Sub Channel Data Types ====================================================================== Code Value Data types to be transferred ------------ -------------------------------------------------------- 0h No sub-channel data type specified 1h Sub-channel Q current position data requested. (i.e. track, index, absolute address, relative address.) 2h Sub-channel Q media catalog number requested. 3h Sub-channel Q current location data and media catalog number information requested. 4h Sub-channel Q ISRC requested. 5h Sub-channel Q current location data and ISRC requested. 6h Sub-channel Q media catalog number and ISRC requested. 7h Sub-channel Q current location data, media catalog number and ISRC requested. 8h - FFh Reserved ====================================================================== The transfer length field specifies the maximum number of logical blocks that shall be scanned. A transfer length field of zero indicates that no sub-channel scan shall occur. This condition shall not be considered as an error. If the logical block length is not equal to the sector size the target may adjust the starting logical block address and the transfer length. In such case, it is recommended that the target start the scan operation with the beginning of a sector whenever the starting logical address falls within that sector (MSF unit). If the requested transfer length causes the end of a sub-channel scan to fall within a sector, the target may continue the scan operation through the end of that sector.