[Libcdio-devel] Re: libcdio - mode detection - linux

[Justin B Ruggles]

R. Bernstein wrote:
>  And given that there is a libcdio way to issue SCSI MMC commands,
>  that may be a more reliable way to determine the mode of a track by
>  issing a SCSI MMC command rather than reading the raw mode and
>  examining the header. But I really don't know. Experience and testing
>  is probably needed.

That sounds like a good idea to me, too.  I haven't done much in the way 
of research on SCSI MMC commands.  That's next on my list though.  I've 
only really been studying basic cd-rom stuff for about a week, so I'm 
definitely no expert.  Since cdrdao uses SCSI MMC and seems to always 
get the information right with all my test CD's it might be worth  it to 
study that a bit.


>  My guess, but it's just a guess, is that if one knew this was very
>  reliable and couldn't be fooled by some specific data (such as an
>  audio track with a pattern that looks like a mode2 track), it would
>  just become part of the routine.

After more testing, I think I've found a couple places that are a little 
suspect (at least in Linux).  The first one is in 
get_track_format_linux(...).  The code that is copied from the kernel 
cdrom.c doesn't seem to work at all (at least in ioctl mode).  Honestly, 
I don't know why it reads from cdte_format when that field is used for 
something completely different on the input side.  The ioctl call 
doesn't seem to even touch this value.

The second place, while probably technically correct, doesn't work with 
some of the CD's I've tested.  In get_track_green_linux(...), doing a 
(cdte_ctrl & 2) works for most of my test CD's, but some of them have 4 
instead of 6  for cdte_ctrl even though they are XA tracks.  (cdte_ctrl 
& CDROM_DATA_TRACK) seems to be very reliable though for detecting data 
vs. audio.

My suggestion at this point (not being very SCSI-literate yet) would be 
to use a combination of reading the TOC to determine if the track is 
data or audio and if it is data, using the raw mode header to determine 
the mode.  That would prevent misjudging audio tracks that just happen 
to start with the same bits as the header sync bits as being data.  The 
header should be very reliable in determining the mode since it is part 
of the ECMA-130 specification.  The only hard part would be to determine 
if the mode2 data is form1, form2, or formless.  This seems like it 
could easily be fooled by formless data that happens to be valid for the 
XA subheader fields.  Since I think all zeros is valid, this could occur 
fairly often.  Comparing the 2 subheaders in each sector would help a 
little, but not much.  I'm not sure what the valid values are for the 
file#, channel#, and coding fields, but if these are known, that would 
help detection a bit.  On the plus side, all the resources I've seen say 
that mode2 formless (plain yellow-book) is quite rare.

Any thoughts, comments?

-Justin