protocol analysis "track get title"

Hi,

no analysis as in my previous mail, just a few notes.

Get Track Title
===============

00 18  06 02 20 18  02  00 TT  30 00  0a 00  ff 00 00 00 00 00

* Most that is true for disc get title is also true for track get title.
  In particular, the significance of most bytes.  Exceptions follow, but I
  did not do extensive testings.

* Byte 7 is now "02" instead "01".  If it is "03", wchar support is
  activated.

* Byte 8 is now significant, and possibly used to extend byte 9 to full word
  size, for minidiscs with more than 255 tracks.  Although I am not sure
  if this is really supported on todays hardware.  The Sony MZ-N707 can only
  create mini discs with up to 254 tracks, then I get TR FULL.

* Byte 9 is significant, and indicates the track number, possibly in
  conjunction with byte 8.
  Note: Track number 0xff is special: It is the _disc title_.  This is
  probably a consequence of the format of a minidisc (the disc title is just
  the title of the special track that holds the free frames list, or so)
  Because of this, I wonder if really more than 255 tracks are supported and
  if byte 8 is truly a straight forward range extension.

If byte 8 is non-00, or byte 9 has a number higher than the last track
number (count of tracks minus 1), but not 0xff, then an 0a error is
returned.  Because this is true for byte 8 as well as byte 9, this supports
the notion that 8 is also used to number tracks.

So we have contradicting interpretations here.  Possibly byte 8 is meant as
an extension, but not today, and the parser doesn't handle it all too well.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/