Hi, > If in some > cases a sbc routine does the same thing as a spc routine that's okay and can > easily be handled.
The standards are coordinated. For our purposes SBC covers only 1Bh START/STOP UNIT SPC is used in libburn in form of 12h INQUIRY 5Ah MODE SENSE 55h MODE SELECT 03h REQUEST SENSE 00h TEST UNIT READY A special case is 1Eh PREVENT/ALLOW MEDIA REMOVAL where MMC-5 says: "[SPC-3] describes a PREVENT ALLOW MEDIUM REMOVAL command; however, the [SPC-3] description does not apply to MM devices. " So we should only obey the MMC prescriptions and ignore SPC here. No double functions to expect. > I think you will have to help doing the > READ DISC STRUCTURE part. Sure. Give me the framework. The problem is that you have to pull logics from the OS drivers into the generic part. > In many respects, I am just moderating here as I > really don't have any specific need for any of this. ;-) There is some need in libcdio for catching up with those media. TOC is flatly wrong. > I don't feel comfortable > violating an existing standard such as say the Philips Red book This standard simply does not apply to DVD and BD. The newer standards would apply to CD, but in that aspect i vote for keeping old CD functionality unchanged. The newer media are near enough to CD to be covered by libcdio. You just have to open it a bit for their new concepts. Vice versa a libdvdio would have a huge intersection of features with libcdio. > Both users and application writers need to be aware and transparent about > the fact that an extension on a standard format is getting used. They would be aware by the fact that the new TOC call has to be used by the application on the first hand. Old call = old result. The performance of cd-info with DVD TOCs is awful enough so that any user will be happy with breaking its habits on DVD. The media recognizer would only be confusing by telling new yet unkown media types. Any caller should have a default case for such unknown replies. Have a nice day :) Thomas
