The Mt.Fuji standard is basically the subset of SCSI commands relevant to optical media. It’s a manual for how to talk to a generic CD/DVD/BD logical unit, not how to bypass it. Most of the things you’re looking for would require hardware/firmware modification or knowledge of vendor-specific protocols.
*Can MtFuji read all 7203 bytes from sectors? (the layers above 3234b and 2352b)
No, the most you can get is 2774 bytes (2352 + subchannels (96) + C2 error data (296)) from the READ CD command. For anything deeper than that you’d need custom firmware or a special drive, and to see the raw EFM bits (the ‘7203 bytes’) you’d have to be directly measuring the laser signal.
*Can MtFuji manually read (directly from rotation engine) and set rotation speeds? (maybe overclocking slimdrive to 32×CAV for CD).
No, you can set rotation speeds, but only through the logical unit - not directly.
*Can MtFuji enable reading discs DURING acceleration instead of waiting?
No, this behavior is controlled by the logical unit.
*Can MT Fuji enable MtRainer?
This depends on whether the device supports packet writing.
*Can MtFuji instruct the disc drive not to hold the disc but let it spin off, if inactive for too long?
Yes, most drives support the “Power Condition” mode page, which allows to set spindown timing, with the MODE SELECT command.
Can MtFuji bypass *05/21/00 LOGiCAL BLOCK ADDRESS OUT OF RANGE? (e.g. recover quick formatted CD-RW with missing TOC)?
No, this behavior is controlled by the logical unit - it determines valid LBA ranges when the disc is first inserted. Custom firmware or vendor-specific commands can bypass this, but you can also try the disc swap trick I wrote about earlier to fool the logical unit into believing your wanted LBA range is valid.
*Can MtFuji enable DPM (data position measurement)?
No idea, that’s beyond the scope of this standard.
*How can Mount Fuji be implemented by custom firmware?
I think it’s the other way around - if you’re writing custom firmware it’s up to you to adhere (or not) to this or any standard.
*What software are you developing?
I’m working on CD/DVD recovery/archival software. There’s 2 separate parts. The archival program runs on Windows and it’s main purpose is to separate file data from the metadata (filesystem, sector modes, subchannel, etc) of a CD image. This allows me to de-dupe and store the actual files in various proper locations, and later be able to reassemble the original disc image bit-for-bit as it once was. The program can determine data sectors’ corruption state based on ECC data and merge multiple separate images, keeping the best sectors from each image.
The recovery program is a later addition that runs on Linux (since device control is much easier there). It uses the methods I wrote in my previous post to read discs, and basically feeds data into the archival program.
I’ll eventually publish these as freeware, once they’re stable.