I have a set of OC-800 WORM disks (768MB) which contain vintage TV graphics from the '90s, written by an Ampex Electronic Still-Store (ESS). I'd like to retrieve the data from them if I can.

These disks appear to be exclusive to the Maxtor RXT-800 family of drives (which I believe is a rebadged Ricoh R620).

I've obtained an RXT-800S and connected it using an Adaptec AHA-2940U/UW. The drive appears functional -- Linux identifies the drive and mounts it as /dev/sr0 and if I invoke ddrescue it spins up the disk, seeks, and reports nothing but bad blocks found. I know that "unwritten" sectors can report as bad but I've let it run for as long as an hour with no good blocks found.

Now, I've been told these have an archival life of only 10 years so maybe the data is simply lost to the mists of time, but I'm equally convinced that I just don't have the right settings to get anything out of this fairly obscure format.

With that in mind I have two questions:

  1. Given that the WORM format doesn't have the same failure modes as a HDD, what makes ddrescue good for hard disks may not provide any advantages here. Is there a different tool that would be better suited to this task?

  2. Assuming there is in fact readable data on the disks, what would be a methodical plan to attack this problem? I've been thinking I could write a perl script that would loop through a list of likely block sizes and invoke ddrescue programmatically to see if any of them find anything, but that feels like a rather brute-force approach and I wonder whether I'm overlooking a simpler and/or more elegant approach.


Below is the output from some of the sg3utils utilities.

I guess the sginfo -6 -f and sginfo -6 -g provide decoding for the base sginfo `6 outupt?

localhost:~ # sg_modes -a /dev/sr0

MAXTOR    RXT-800S          K      peripheral_type: write once optical disk [0x4]
>>>>>> try again with a '-6' switch for a 6 byte MODE SENSE command
Illegal request, Invalid opcode

localhost:~ # sg_modes -6 /dev/sr0

MAXTOR    RXT-800S          K      peripheral_type: write once optical disk [0x4]
Mode parameter header from MODE SENSE(6):
Mode data length=63, medium type=0x00, specific param=0x00, longlba=0
Block descriptor length=8
> General mode parameter block descriptors:
 Density code=0x0
 00     00 00 00 00 00 00 08 00

>> Read-Write error recovery, page_control: current
 00     01 02 80 03
>> Format (obsolete), page_control: current
 00     03 16 00 01 00 02 00 00  00 31 00 40 08 00 00 01
 10     00 00 00 00 68 00 00 00
>> Rigid disk geometry (obsolete), page_control: current
 00     04 12 00 0c 18 01 00 00  00 00 00 00 00 00 00 00
 10     00 00 00 00
>> page_code: 0x29, page_control: current
 00     29 01 00

localhost:~ # sg_ident -r -v /dev/sr0

Report identifying information cdb: a3 05 00 00 00 00 00 00 00 04 00 00 
Report identifying information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
Report identifying information: Illegal request, Invalid opcode, sense key + asc,ascq

localhost:~ # sginfo -6 -f /dev/sr0

Format Device mode page (0x3)
Tracks per Zone                    1
Alternate sectors per zone         2
Alternate tracks per zone          0
Alternate tracks per lu            49
Sectors per track                  64
Data bytes per physical sector     2048
Interleave                         1
Track skew factor                  0
Cylinder skew factor               0
Supports Soft Sectoring            0
Supports Hard Sectoring            1
Removable Medium                   1
Surface                            0

localhost:~ # sginfo -6 -g /dev/sr0

Rigid Disk Geometry mode page (0x4)
Number of cylinders                3096
Number of heads                    1
Starting cyl. write precomp        0
Starting cyl. reduced current      0
Device step rate                   0
Landing Zone Cylinder              0
RPL                                0
Rotational Offset                  0
Rotational Rate                    19232


I picked up a third drive, this one the half-height RXT-800HS variant.

localhost:~ # sg_inq /dev/sr1

standard INQUIRY:
PQual=0  PDT=4  RMB=1  LU_CONG=0  hot_pluggable=0  version=0x01  [SCSI-1]
[AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=1
SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  [BQue=0]
EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
[RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=0
length=36 (0x24)   Peripheral device type: write once optical disk
Vendor identification: MAXTOR  
Product identification: RXT-800S        
Product revision level: A9A4

localhost:~ # sg_read bs=2048 cdbsz=6 blk_sgio=1 count=1 verbose=2 if=/dev/sr1

Opened /dev/sr0 for SG_IO with flags=0x0
READ cdb: [08 00 00 00 01 00]
  duration=26200 ms
reading: SCSI status: Check Condition 
Fixed format, current; Sense key: Medium Error
Additional sense: Logical unit communication failure
Raw sense data (in hex), sb_len=21, calculated_len=21
    70 00 03 00 00 00 00 0d  00 00 00 00 08 00 00 00
    00 00 00 00 d7
sg_read: SCSI READ medium/hardware error
Some error occurred,  remaining block count=1
0+0 records in

localhost:~ # ddrescue -b 2048 -r 0 -n -v /dev/sr1 worm1.img

GNU ddrescue 1.23
About to copy 393117 kBytes from '/dev/sr1' to 'worm1.img'
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size:  32 sectors       Initial skip size: 32 sectors
Sector size: 2048 Bytes

Press Ctrl-C to interrupt
     ipos:        0 B, non-trimmed:        0 B,  current rate:       0 B/s
     opos:        0 B, non-scraped:        0 B,  average rate:       0 B/s
non-tried:  393117 kB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:        0 B,   bad areas:        0,        run time:          0s
pct rescued:    0.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (forwards)

I do find it interesting that it sees the size as exactly half of the 786MB capacity, so ddrescue knows how big the platter is supposed to be.

  • 1
    Googling says the RXT-800S is SCSI, so the first thing I'd do in your place is to read the MMC SCSI spec from end-to-end, install sg3utils and see if you can read some mode pages, the TOC etc. Potentially you'll have to fiddle with SCSI commands to get it working with WORM, and at that time it probably wasn't standardized, but you can try the usual ones. A datasheet for the commands for the RXT-800S would really really help. ddrescue just uses plain SCSI READ commands, which may not work at all.
    – dirkt
    Commented Apr 19, 2022 at 8:55
  • @dirkt Thanks, I've gotten some information from the drive but I'm still working out how to use what it's reporting. Commented Apr 25, 2022 at 20:21
  • 1
    A 10-year lifespan on a WORM drive sounds short. It's burned holes in plastic -- more like a musical record than a magnetic disk. IIRC, Sony WORM platters had an expected data retention of at least 100 years. Another factor would be the software which wrote the information. Do you know it to be standard Unix/Linux ? It could have been written by a DEC system and/or using a totally proprietary , dedicated-application disk format.
    – RichF
    Commented Apr 25, 2022 at 20:38
  • 1
    invidious.namazso.eu/embed/m_s1iw8eW7o you could also attempt to dump the entire magnetic data and parse it in software Commented Apr 26, 2022 at 12:47
  • 1
    www-msdos-jatman-uk.translate.goog/worm/… <-- maybe you can find such DOS software and the SCSI adapter. Commented Jul 18, 2023 at 15:18

2 Answers 2


Assuming there is in fact readable data on the disks, what would be a methodical plan to attack this problem?

@RichF It was written by a proprietary Ampex video system from the mid-80s.

There may be a non-technical solution. I see Ampex has a website. My starting point would be to contact Ampex and hope you could get hold of someone who remembers the product. You might be very lucky and find they offer a data recovery service for their old media. Even if not, they might know of a customer who still works with their old media. If so, they might be willing to see if they can have someone from that company contact you.

  • Unfortunately Ampex is one of those companies that has had its divisions broken up and sold over time so I'm not sure whether today's Ampex has history for the old broadcast video division. That being said, I sent emails to their public addresses and have not received a response from them. Commented Jul 28, 2023 at 22:18

Partial answer:

If the RXT-800S responds to mode page requests, chances are good that it follows the rest of the specs at least to some degree. You can find the SCSI specs on the T10 working drafts page. I am not sure if they are still publicly available, but at least you get the name of the documents.

I couldn't find anything specific to the Maxtor WORM format, so I do not know how similar this to the CD format, and the commands that are needed for CDs (you can find those in the MMC section).

For SCSI commands, there are often multiple versions that were added over time with different amount of bits for the blocks etc., that's why you need the -6, because the drive only understand the old 6-byte page requests, not the newer 10-byte ones.

The next thing to try is an sg_read. We now know the blocksize bs=2048. Please play with cdbsz until you find one that is supported (same mechanism as -6, for differently sized requests). Please have a close look at the "sense" (result code) returned, this should tell you if it's the wrong command for a WORM disk in the first place, if the block is bad, or if something else happened.

Please also provide some information on how the drive is connected (via ATA? via USB? via a special card?), and include output of an sg_inq /dev/sr0. If the device is behind some bridge chip, the bridge may or may not translate some commands.

If sg_read fails, the next step would be to try a READ CD (BEh) command or a READ VTOC (43h) command. If you cannot locate a copy of the SCSI MMC spec that describe those commands, I can provide some details.

In case WORM is too different from CD drives and those don't work, the last straw is to try all SCSI commands to at least figure out which are understood by the drive, and then do some guesswork on which command might be needed to read data.

I am a bit confused about the third drive, did you mention a second drive somewhere?

I also only see an sg_read attempt for the third drive, what does it do on the two other drives?

sg_read: SCSI READ medium/hardware error

is bad news, because it means the command itself is supported (otherwise there would be an "Illegal Request" error), and trying different commands probably isn't going to help.

On the other hand,

Additional sense: Logical unit communication failure

is a bit confusing, I would have expected some other error if the disk could not be read. This sounds more like "controller tried to communicate with the disk, and ran into trouble".

I'd really like to see what happens with other drives/other controllers, if you already have them.

Also, try the skip parameter for sg_read to try to read other sectors. In particular, try to read sectors from all over the disk (you have the geometry info already).

  • I'm using an Adaptec AHA-2940U/UW PCI card so no additional USB layers or anything like that. I'll try your suggestions and then update. Commented Apr 26, 2022 at 14:19
  • I've added output from sg_inq and sg_read. I've found some documentation on the specs but I'm not familiar with how I'd go about trying to invoke the raw SCSI commands. Commented Jul 17, 2023 at 22:07
  • 1
    @WildcatMatt linux.die.net/man/8/sg_raw Commented Jul 20, 2023 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .