Hi Bret,
as you say, there are the UPC/EAN of the CD and ISRC of each track if audio, both optional, but UPC/EAN probably is widespread for audio. I wonder how widespread they are for mass-produced data CD/DVD discs? > The Q sub-channel contains sector information (on audio CDs this is the > Minute-Second-Fractional Second information), UPC code, and ISRC data. And actually Jack's driver already DOES support Q sub-channel time info, which is useful for CD players including my tiny CDROM2UI to know where (when) you are while playing audio. The specs say that the UPC/EAN and ISRC are at least in every 100th frame if they are present at all, so the challenge would probably be to understand enough of the Q channel request protocol used by the driver to "ask for a different Q" to fetch the probably also BCD encoded UPC/EAN values. There also seems to be a possibility to get info about the current CD as part of the command 0xEC drive identification data, which otherwise tells you about the drive, not the disk, but this might be something else, for maybe reporting the brand of writeable media? Either way, using the UPC for copy protection of games is pretty much pointless, because you can easily copy that as well, so I still FIRST want to know whether games REALLY rely on that for their copy protection scheme. As you can see in my original mail about OAKCDROM versus UDVD2, there are other, more exotic features which are supported in OAKCDROM, but not in UDVD2. While they seem unlikely to be related to game protections, only the proposed test by artificially breaking OAKCDROM's ability to report UPC will tell whether the UPC actually is used by games. If it is not, probably very few other apps would care about UPC. I mean who has a networked DOS audio CD player which would use the UPC to download a track listing? Which, by the way, could also be read from the CD itself when it contains CD TEXT in yet ANOTHER sub-channel encoding. That is what modern stand-alone CD players are doing, without requiring an internet connection. Not sure how one would read CD TEXT via DOS driver calls, though: You would have to read sub-channels R, S, T, U, V and W for CD TEXT. The general idea with Q sub-channel data is that it comes with a type code (0 empty, 1 timestamp, 2 UPC/EAN/MCN, 3 ISRC etc.) so you can probably either query or filter by that type. Depends on how ATAPI / SCSI / ... defines and drivers implement things. https://en.wikipedia.org/wiki/Compact_Disc_subcode Regards, Eric _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
