From: muta...@gmail.com   
      
   On Wednesday, October 27, 2021 at 8:04:59 PM UTC+11, JJ wrote:   
      
   > > My concern is about the nature of CDROMs which I believe   
   > > have variable-length tracks, if not sectors, so I'm not sure   
   > > that a scheme can be invented, at the BIOS level, to seek a   
   > > fixed number of bytes as opposed to seeing a track number.   
      
   > There should be no problem. From software point of view, CD-ROMs don't have   
   > multiple tracks like in harddisks and floppies. In CD-ROMs, track is just an   
   > index which is part of a CD-ROM's table of contents. When addressing a   
   > sector, track number is not involved at all.   
   >   
   > The lowest level of CD-ROM sector addressing is by time: hh:mm:ss.ff. Where   
   > `hh:mm:ss` is hours, minutes, and seconds; and `ff` is frames. There are 75   
   > frames per second. Each (raw) frame is 2352 bytes, which is equal to 176,400   
   > Bytes. The same audio CD data rate for 44.1KHz 16-bit stereo PCM audio data.   
   >   
   > LBA addressing is just an additional sector address translation which is   
   > implemented at disk controller firmware level. Both LBA and time based   
   > addressing are flat addressing. When we need to address a sector at   
   > beginning of a specific track number, we'll have to refer to the CD-ROM's   
   > TOC to get the absolute time/LBA address of a specific track, then we have   
   > to use that address (instead of track number) to access the needed sector.   
      
   Ok, thanks for the info. But:   
      
   1. Is the TOC also comprised of 2352-byte sectors?   
      
   2. I don't want to do LBA addressing, I want to do byte addressing,   
   so if the CDROM (including TOC) consists of a long sequence of   
   2352-byte sectors, that will work. But if there is metadata between   
   any of those sectors, it will need to be accounted for when doing   
   a fseek(). The fopen("cdrom", "r+b") would need to analyze the   
   CDROM looking for where the metadata is, and what its size is, and   
   then present that table as part of the first fake sector of the file,   
   which the caller will need to fread() and understand so that it can   
   provide accurate fseek() arguments.   
      
   I had to do a similar then when reading RECFM=V datasets on the   
   mainframe in binary mode. I forced a 4-byte RDW to come through   
   in the data stream (and needs to be constructed by the program   
   when writing). Most people instead use extensions to read and   
   write by record instead. There may be a similar consideration   
   needed for CDROMs and CKD disks.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)