> 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.
Things have certainly changed over the years. UPC/EAN has always existed for CD's (which started in 1982). ISRC didn't even exist until 1989, so the first several years CDs were produced they couldn't have ISRC. ISRC seems to be a really big deal now since that's how musicians get their royalties. > I wonder how widespread they are for mass-produced data CD/DVD > discs? I have no idea, but suspect they are more interested in the UPC/EAN bar code on the packaging than the electronic UPC/EAN. > 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. Exactly -- which is why it shouldn't be a big deal for him to add UPC. It's just Jack being Jack. > 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. You would only need to worry about that if you downloaded the raw sub-channel data and were trying to decode it. With the specific SCSI request, the hardware does all of the work to find it and decode it for you. Since the UPC/EAN is for the entire disk, you don't even need to know where you are on the disk like you do with the time/sector and ISRC info. There is also the IOCTL request (and associated SCSI request) to download a large section of sub-channel data. That may be how the copy protection scheme is implemented. I suspect Jack's driver doesn't support that IOCTL function either but the OAK driver probably does? > 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? Not sure. I know when I was last working on this (which was a while ago) there were lots of different places I had to look for information to differentiate between CD/DVD/BD, R/R+/R-/RAM/RW/..., different sizes of disks (3.5 & 5.25), single vs. multi-layer, etc. It's a confusing mess to sort through it all. You're also correct that some things apply to the player and others to the media, and sometimes it's kind of hard to tell the difference. > 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. Like you, I really doubt that's how they do it. But I suspect it does have something to do with the sub-channel data. My problem with Jack in this case is that he has only provided half a driver -- it doesn't even support all the standard IOCTL functions it's supposed to. If Jack would just provide a complete IOCTL command set it would probably work just fine however they implemented the copy protections scheme. > 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? Unlikely, but really beside the point since it is a standard function that Jack's driver should provide. > Which, by the way, could also be read from the CD itself when it > contains CD TEXT in yet ANOTHER sub-channel encoding. The problem is that even though there is a "standard", the research I've seen shows all kinds of weird data being in the CD TEXT. This is another case where even though there are standards they are many times treated as recommendations rather than standards. > 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. I don't remember running across any SCSI commands that refer specifically to CD TEXT, but maybe I just haven't been looking in the right place. The SCSI command set is really complicated. > 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. I think it depends more on which SCSI commands the CD player actually responds to. ATAPI, USB, etc. simply provide a bus-specific "wrapper" around SCSI commands. > https://en.wikipedia.org/wiki/Compact_Disc_subcode Interesting, but not very complete. Needs further research. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
