CD-i Fan shares more knowledge about CD-i Ready and how it is handled inside CD-i Emulator. CD-i Fan: "CD-i Emulator supports multiple sector size images: 2048, 2056, 2332, 2336, 2340, 2352, 2448. Some of these seem to be unused in practice but in the interests of generality I support everything that seems "workable". However, the emulator proper wants 2352 byte RAW image. So in some cases conversion is needed, which is where the Copy function comes in. As a bonus, it also handles scrambling which has come in quite handy. The system basically handles every raw sector image format out there. The only known issue is that it requires the first sector sync to by at byte zero."
That looks like that a cuesheet or image can specify one format, while the underlying data in the .bin file is not in fact in that format, CD-i member TheMogMiner observes. "That is a quirk of CD-i Ready, really. The TOC and thus any CUE/CCD file generated from it mischaracterizes most of the pregap of track 1, which is really data and not audio even though everything in sight says so.
That's why the only way to differentiate between CD-Audio and CD-i Ready is to check the size of the track 1 pregap and just attempt to read sector 00:02:16 as data. CD-i Ready is a compatibility "hack" and this is why it seems to be such a problem for everyone not getting the full underlying details (which includes many drive manufacturers). And it was actually purposefully designed this way... Basically, CD-i Ready leaves the "lead-in TOC and in-track subcode specify everything" idea and for the pregap of track 1 replaces it with "just look at the sector, if it's parsable as data then it is data".
Or, really, "just always treat it as CD-i data unless specifically directed otherwise (i.e., the SS_CDDA call to play red book audio sectors)". Somebody somewhere made the call to dump discs in "usable" format, which for data sectors means after descrambling. But that requires accurate determination of the sector type and that is exactly where CD-i Ready discs make things hard. CD-i Emulator currently expects the entire disc image to be either scrambled or not, but that has bitten me before for some weird images and I'm probably going to change it when I implement CUE/CCD support.
Understanding [how this works] is actually made harder by the fact that the first 30 seconds or so of CD-i discs are required to be "Message" sectors which are those weird things that look like a mode 2 data sector (they have sync, header, subheader) but are actually mostly audio data. On "old" audio CD players these will actually play back as an audio warning message with a weird high-frequency disturbance caused by the sync/header/subheader bits. Saying something like "Warning! This is a data disc that may damage your audio equipment if you continue playing it. Stop or mute your playback."
A CD-i application almost never read those sectors, they are not in the file system. But, technically, they probably could be read using the raw disc device. And they would be read as mode 2 sectors in that case because according to the Green Book it's what they are. That they are audio in disguise is, again, just for compatibility with old audio cd players. Note that the entire "Message" sector concept holds for regular CD-i discs as well as CD-i Ready discs. Never tried playing message sectors as cd audio on a CD-i player, it might even work... For anybody wanting more information, I greatly recommend just reading chapter II CD-I Disc Format of the Green Book. It is very comprehensive, and if you ignore the technical details about scrambling polynomials, error correction, error detection and galois fields even very readable, at least to me. And I first read this in 1993 when I had no prior experience at all with the nitty gritty details of CD formats. And, for CD-i Ready, of course also the "APPLICATION NOTE CD-I READY". It's only five pages."
[Thanks, CD-i Fan]