home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,913 of 4,255   
   JJ to muta...@gmail.com   
   Re: ISO CD image   
   28 Oct 21 17:52:10   
   
   From: jj4public@gmail.com   
      
   On Wed, 27 Oct 2021 02:43:05 -0700 (PDT), muta...@gmail.com wrote:   
   >   
   > Ok, thanks for the info. But:   
   >   
   > 1. Is the TOC also comprised of 2352-byte sectors?   
      
   CD-ROM TOC uses the same sectors, the they're not part of normal user data   
   sectors. There are special area for TOC only. Same goes to the CD-ROM ID   
   sector which contains the media capacity, manufacturer, and dye type. The   
   ATAPI command for accessing the TOC and ID are all different than the one   
   used to access user data sectors.   
      
   So, when we read the user data sectors from the first up to the last ones,   
   none of them contains the TOC. The TOC area is limited and can be full. It's   
   why sometimes when we add a new session to a multi-session CD-ROM, the media   
   can become full even though there's still enough user data space left.   
      
   > 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.   
      
   That is your job for implementing your own data addressing translation.   
   Because whether you want it or not, there must be additional code which   
   translate sector to byte addresses and vice versa, because sector is the   
   hardware level data addressing.   
      
   The 2352 sector size is the raw size. It doesn't include sector   
   synchromization, time address, sector mode, and error correction code. Only   
   2048 bytes is used for user data. Kind of like raw floppy sectors which   
   include index, ID, and various types of gap; aside from user data.   
      
   Depending on the sector mode is used to read a sector, byte offset   
   compensation will not be needed if the sector is read using non raw mode,   
   because the received data will not include data other than the user data as   
   previously mentioned. Though, for DVD and Blu-Ray, raw sector mode is no   
   longer exist.   
      
   The start of a track sector is just a normal sector. There's no metadata or   
   additional data is the sector which indicates that it's a start of a track.   
   However, there may be gap sectors before the track start. The gap for the   
   first track is mandatory. The gap between tracks is optional but is normally   
   used. The gap sectors themselves are not marker for a track. As long as the   
   TOC doesn't define additional track(s), the CD-ROM drive will only see one   
   track - even if there are multiple gap sectors in the media.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca