[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Justin B Ruggles
Subject: [Libcdio-devel] Re: libcdio - mode detection - linux
Date: Wed, 01 Dec 2004 23:53:58 -0500
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]