The Read Disc Structure – Format Code FFh CDB (MMC / Mt. Fuji devices) allows software to retrieve the supported disc structures.  Each structure list entry is four bytes in length and looks like this:

 

 

The “Structure Length” is defined in Mt. Fuji 7 and MMC as:

 

The Structure Length field shall specify the length of the DISC STRUCTURE data that is identified by the Format Code.

 

Each disc structure is preceded by a four byte header.  For example, using the above “Physical Format Information,” a device could return:

 

 

Note that offset 0-1 shows 0802h as the “Data Structure Length”.  When you retrieve the length from the capability list (topmost example), the drive returns 0800h.  The 0802h adds two bytes for the two additional bytes in the header (typical length scheme used in all the t10 specifications).

 

Here is the problem.  In the capability list, what exactly is the “Structure Length?”  I have drives from various vendors that all handle this differently.  They use one of the following three methods.  Each can argue that they meet the requirement of The Structure Length field shall specify the length of the DISC STRUCTURE data that is identified by the Format Code:

 

1.       Method #1:  The drive returns the length of the structure not including any header bytes (as you see in the above example).  For fixed length structures, this value would be two bytes less than the value that is returned in the structure header.

2.       Method #2:  The drive returns the same value as in the structure header.  In other words, the “Structure Length” equals the “Data Structure Length”.  Technically, this value is two bytes larger than the actual disc structure (i.e. those two reserved bytes after the Data Structure Length).

3.       Method #3:  The drive returns the length of the structure INCLUDING the four byte header.  For fixed length structures, this value would be two bytes more than what is returned in the structure header.

 

While I find the specification not clear on this point, I do believe that Method #1 is the most technically accurate (i.e. not including the header bytes in the count).

 

This confusion comes from the specification leaving room for interpretation on how to handle this (both Mt. Fuji and MMC).  Katata-san, can you clarify what was intended with the specification and also have the next draft specification address this issue?  Thank you.

 

-------

Mike Berhan

busTRACE Technologies

9700 Village Center Drive

Suite 50-F

Granite Bay, CA  95746

916.773.4554 phone

916.218.6283 fax

http://www.bustrace.com