HDDSuperClone vs ddrescue

GNU ddrescue and HDDSuperClone are the two most-recommended open-source tools for imaging a failing hard drive. Both create a sector-by-sector binary clone of a source disk. Both can pause, resume, and work around bad sectors. The difference is architectural: ddrescue reads through the Linux kernel's block device layer, while HDDSuperClone sends raw ATA commands directly to the drive controller via pass-through. That distinction determines which tool can handle a specific failure mode and which one will make it worse.
This guide covers when ddrescue is the right choice, when HDDSuperClone's ATA pass-through is required, and when both tools are inadequate and the drive needs professional hardware like the PC-3000 or DeepSpar Disk Imager.
Disk Imaging Is Not Data Recovery
A common error in DIY recovery attempts is running file-recovery software (Recuva, EaseUS, Disk Drill) directly on a failing drive. These programs issue random, non-sequential read requests across the entire disk surface. On a drive with unstable heads or degrading media, that access pattern accelerates mechanical failure.
Disk imaging is the first phase of any recovery: reading sectors sequentially from LBA 0 to the last sector and writing them to a healthy destination. File-system parsing happens on the cloned image, not on the original drive. ddrescue and HDDSuperClone are imaging tools. They output a raw binary image or a cloned disk. They do not output readable files.
GNU ddrescue: Kernel Block Device Imaging
GNU ddrescue is a GNU Project tool that reads from the standard Linux block device interface (/dev/sdX). It issues POSIX read() calls, and the kernel handles the actual SCSI/ATA command translation via the host bus adapter driver.
ddrescue's strength is its multi-pass algorithm. As of version 1.30 (January 2026), five phases handle progressively harder sectors:
- Copying: Reads large contiguous blocks. On error, skips a large region and continues forward, extracting all the easy-to-read data first.
- Trimming: Revisits skipped regions and narrows down the exact boundaries of each bad sector cluster by reading inward from both edges.
- Sweeping: A forward pass with skipping disabled to delimit large error areas and produce good starting points for the scraping phase.
- Scraping: Reads the remaining unresolved sectors one at a time.
- Retrying: Multiple passes over confirmed bad sectors, relying on the probability that the head aligns correctly on a retry to recover marginal sectors.
The mapfile (formerly logfile) records the state of every sector range as non-tried, finished, non-trimmed, non-scraped, or bad-sector. If the process is interrupted by a crash or a drive dropping offline, ddrescue resumes from the mapfile without re-reading finished sectors.
Where ddrescue works well
Drives with stable, functioning read/write heads but scattered bad sectors from media degradation. The heads can still read the majority of the platter surface; the bad sectors are localized defects in the magnetic coating. ddrescue extracts the good data first, then methodically narrows down the bad regions.
Where ddrescue fails
When a physical read/write head is weak or intermittently failing, ddrescue has no mechanism to detect which head is responsible. The Linux kernel treats the drive as a single block device. If a bad head hangs the drive controller, the kernel waits for its I/O timeout (30+ seconds by default) before returning an error. During that wait, the failing head is forced to keep attempting reads, accelerating its degradation. ddrescue cannot issue a hardware reset or skip the failing head's sectors because it does not know physical heads exist.
HDDSuperClone: ATA Pass-Through Imaging
HDDSuperClone, originally developed by Scott Dwyer, uses SCSI/ATA pass-through to bypass the Linux kernel's block device layer and send raw ATA commands (such as READ SECTORS EXT) directly to the drive controller. This gives the software access to the drive's hardware error registers rather than the generic “read failed” response the kernel returns.
Head-skipping algorithm
A hard drive maps logical block addresses (LBAs) to physical platters and heads. HDDSuperClone tracks which LBA ranges correspond to which physical head. When a head produces repeated read errors, the algorithm calculates the LBA offset of that head's zone and skips the entire zone. It clones all data from the healthy heads first, then returns to the failing head for a careful, throttled extraction. This approach is similar to how professional hardware like the PC-3000 handles head instability at the firmware level.
DMA vs PIO mode selection
Standard data transfer uses DMA (Direct Memory Access), where the drive controller writes data directly to system memory at full interface speed. On a degrading drive, DMA timeouts can crash the controller, requiring a full power cycle. HDDSuperClone allows switching to PIO (Programmed Input/Output) mode, where the host CPU polls the drive for each data word. PIO is slower but eliminates DMA timeout crashes, reducing stress on a mechanically unstable drive.
Virtual disk mode
HDDSuperClone can present the imaging session as a virtual block device to the host operating system. File-recovery software (DMDE, R-Studio) can then target specific structures like the Master File Table. If the requested sectors have already been cloned, HDDSuperClone serves them from the image file. If not, it reads them from the source drive and caches them. This prevents any sector from being read twice, allowing targeted file recovery without completing a full-disk clone.
OpenSuperClone: the actively maintained fork
HDDSuperClone's original developer (Scott Dwyer) released the source code and stopped active development. The project continues as OpenSuperClone, maintained under the ISpillMyDrink GitHub organization. The core ATA pass-through imaging engine is functionally identical. OpenSuperClone adds OSCDriver with DKMS support for Linux kernels through 6.11.x, a modernized live ISO (OSC-Live, built on Xubuntu with UEFI Secure Boot support), and integrated USB relay control for automated hardware power cycling.
Western Digital ROYL firmware: the slow-responding drive problem
Western Digital drives using the ROYL firmware architecture maintain a background defect reallocation list in Module 32 of the Service Area. When widespread media degradation triggers continuous reallocation, the drive's microcontroller overloads and transfer speeds drop to single-digit KB/s. ddrescue has no mechanism to address this; it reads through the kernel and receives the same throttled data rate.
OpenSuperClone (via its integrated HDDSuperTool) issues Vendor Specific Commands (VSCs) to patch Module 32 in RAM, disabling the reallocation loop and restoring full interface speed. This is the same firmware manipulation that a PC-3000 performs with a single click. If the Service Area corruption is severe enough that RAM patching fails, the drive needs professional hard drive data recovery with firmware-level repair using PC-3000 DE (Data Extractor).
Automated power cycling with USB relay hardware
Severe read instability can lock a drive controller so completely that ATA soft resets and bus resets both fail. The only way to reestablish communication is cutting 5V/12V electrical supply. OpenSuperClone integrates with the YEPKIT YKUSH 3 switchable USB hub: when the software detects a total SATA bridge lockup, it commands the relay to cut power, waits for spin-down, and restores power automatically. This makes multi-day imaging sessions on severely degraded drives possible without manual intervention.
Side-by-Side Comparison
| Feature | GNU ddrescue | HDDSuperClone | PC-3000 Data Extractor |
|---|---|---|---|
| Interface layer | Linux kernel block device (/dev/sdX) | ATA/SCSI pass-through (bypasses kernel) | Vendor diagnostic terminal; direct firmware access |
| Head awareness | None; sees only logical blocks | Maps LBAs to physical heads; skips failing heads | Firmware-level head disable (MR-Head Shift) before spin-up |
| Timeout control | Depends on kernel I/O timeout (~30s default) | Custom hardware timeouts; can issue soft/hard resets | Hardware-controlled; sub-millisecond precision via PCI adapter |
| DMA/PIO switching | Not available | User-selectable; PIO for degraded drives | Both supported with additional UDMA mode control |
| Progress tracking | Mapfile (text-based, sector status log) | Domain log with head-zone mapping | Per-head sector map with real-time S.M.A.R.T. and thermal monitoring |
| Media compatibility | Any block device (HDD, USB, CD, floppy) | Hard drives only (ATA command set) | HDD, SSD, and flash via vendor-specific modules |
| Virtual disk mode | Not available | Yes; presents imaging session as virtual block device | Yes; with integrated file system parser |
| Firmware repair | Not available | Limited (WD Module 32 RAM patch via HDDSuperTool) | Full Service Area read/write; translator regeneration; module editing |
| Power cycling | Manual only | USB relay (YKUSH 3) automated cycling | Hardware relay built into PCI adapter; configurable spin-up sequences |
| Cost | Free (GNU GPL) | Free (open source) | Professional hardware (lab equipment) |
| Best use case | Stable heads, scattered bad sectors | Weak/failing heads, DMA timeout issues | Firmware locks, head crashes, encrypted drives, thermal asperity |
Why Windows Is the Wrong Operating System for Disk Imaging
Windows aggressively attempts to mount, index, and parse every connected storage device. When a failing hard drive is connected via USB or SATA, Windows will issue random read requests across the disk surface for file-system indexing, thumbnail generation, and drive health checks. These non-sequential reads stress the failing heads in the same way file-recovery software does.
Both ddrescue and HDDSuperClone run on Linux, which can be configured to avoid auto-mounting. For drive imaging, the source drive should never be mounted. Linux distributions booted from a USB stick (such as Ubuntu or SystemRescue) provide a controlled environment where the imaging tool is the only process accessing the drive.
When Both Tools Fail: The Physical Failure Boundary
Stop and power the drive off if you observe any of the following symptoms.
Running ddrescue, HDDSuperClone, or any imaging software on a physically failing drive will cause permanent, unrecoverable data loss.
- Clicking or clacking: The heads cannot find the servo tracks on the platter surface. They swing outward, fail to lock onto a track, and retract to the crash stop. Each cycle risks contact between the head slider and the platter.
- Beeping: Hard drives contain no speakers. Beeping is the acoustic resonance of the spindle motor stalling because the heads are stuck to the platter surface (stiction) or the motor bearing has seized.
- Head crash debris: If a head has contacted the platter, microscopic debris contaminates the airflow channel. Software imaging drives the surviving heads through this debris field, causing cascading head failures.
- Firmware corruption: If the drive's Service Area is damaged, the drive may report 0 bytes capacity, show a factory alias (e.g., “WDC ROM MODEL-HAWK”), or fail to spin up entirely. Software imaging tools cannot access or repair the Service Area.
What professional tools do differently
When a drive crosses this physical failure boundary, recovery requires opening the drive in a 0.02µm ULPA-filtered clean bench for head swaps with a firmware-revision-matched donor, or connecting via the PC-3000's diagnostic terminal for firmware repair. The PC-3000 can disable a crashed head at the firmware level before the drive motor spins, then image the surviving platters using the Data Extractor utility. That firmware-level head control is the capability that separates professional hardware from any software imaging tool.
If your drive exhibits any of the symptoms listed above, mail-in recovery is the next step. We charge no fee if the data is unrecoverable.
Choosing the Right Approach
If the drive spins up, is recognized by the BIOS, and produces no abnormal sounds, start with GNU ddrescue. It is simpler to configure, media-agnostic, and handles scattered bad sectors efficiently. Use a Linux live USB, connect the source drive via SATA (not USB, which adds a bridge controller that masks ATA errors), and image to a destination drive at least as large as the source.
If ddrescue stalls repeatedly on the same regions, or the drive intermittently drops offline, the likely cause is a weak read/write head. Switch to HDDSuperClone and enable its head-skipping algorithm. If the drive is connected via direct SATA and still hangs during DMA transfers, enable PIO mode.
If the drive clicks, beeps, grinds, shows 0 bytes in BIOS, or fails to spin, stop. No software will help. The drive needs physical intervention in a professional lab.
Where Does DeepSpar Disk Imager Sit Between OpenSuperClone and PC-3000?
DeepSpar Disk Imager (DDI) is a dedicated imaging appliance rather than a general-purpose software tool. It sits between OpenSuperClone and the PC-3000 on the capability axis: more hardware-level control than any software imager, less firmware-editing depth than the PC-3000 Data Extractor.
DDI connects the source drive through a dedicated PCI-e card or USB 3.0 adapter that exposes hardware-controlled timeouts and a power-relay line to the drive's SATA power. Unlike a host-bus adapter feeding the Linux kernel, the DDI adapter surfaces ATA command status in real time and can issue COMRESET or cut 12V/5V independently from host OS state. That isolation means a drive lockup cannot freeze the imaging session; the appliance recovers the link without rebooting the host.
DDI retrieves the drive's actual physical head map from the firmware, providing deterministic identification of which physical head services which platter surface. When the appliance detects that one head is producing sustained errors, it allows the operator to selectively disable reads on that physical head for the current pass and configure distinct reading algorithms per head. OpenSuperClone's head-skipping algorithm deduces head boundaries from LBA error clustering because Linux software cannot read firmware geometry tables; DDI works from the drive's real per-head map and gates commands at the hardware layer, which keeps a degrading head off the platter surface more reliably when the drive is close to total mechanical failure. Neither appliance performs firmware surgery: a drive that needs translator rebuild, SA module patching, or MR-Head Shift still goes to PC-3000.
How Do SMART Attributes Inform Imaging Strategy?
Before starting any imaging session, read the drive's SMART attributes with smartctl -A. Four attributes change the imaging strategy directly:
- Reallocated Sector Count (ID 5): sectors the drive has already swapped out to the defect list. A high raw value on a drive that is still mostly readable means media degradation is advanced but the heads are tracking. ddrescue with a small cluster size works here.
- Current Pending Sector Count (ID 197): sectors the drive has flagged for reallocation but has not yet rewritten. Every read attempt on a pending sector triggers an internal ECC retry loop that can stall the controller for tens of seconds. On a drive with a high pending count, reduce the ddrescue
--min-read-ratethreshold or lower OpenSuperClone's skip timeout so the imager jumps past pending sectors on the first pass and returns to them only after the healthy regions are safely cloned. - UDMA CRC Error Count (ID 199): cable or bridge errors, not platter errors. A rising UDMA CRC count during imaging means the SATA cable, backplane, or USB bridge is corrupting data in transit. Stop, replace the cable, and re-seat the drive. Imaging through a degrading cable silently corrupts the destination image.
- Spin Retry Count (ID 10): rising values indicate spindle bearing wear or head-platter stiction. At this point software imaging is unsafe; the drive needs a controlled power sequence through a hardware imager like DDI or PC-3000 that can monitor thermal and current draw during spin-up.
The operator should read these attributes before starting a session, not during it. Professional hardware like DDI disables the SMART subsystem entirely once imaging starts to prevent the drive from executing background SMART logging or defect scans that compete with host reads for actuator time. ddrescue does not read SMART because it operates at the kernel block device level; the operator has to poll it manually in a parallel shell between passes. OpenSuperClone exposes SMART logging in its GUI but treats SMART as advisory, not as a trigger for automatic session abort.
Imaging Parameter Tuning for Failing Drives
Both ddrescue and OpenSuperClone accept parameters that control how aggressively they pursue unreadable sectors. Default settings assume a mostly healthy drive. A failing drive with weak heads or degrading media requires parameter tuning matched to the specific failure mode, or the imaging process itself accelerates the damage.
ddrescue parameter strategy
The --min-read-rate flag sets a floor transfer speed (in bytes per second). If the read rate drops below this threshold, ddrescue skips ahead to the next untried region. Setting --min-read-rate=10M prevents the tool from grinding on sectors where the drive's internal ECC correction loops are stalling the controller. Without this flag, ddrescue waits for the kernel I/O timeout on every bad sector, holding the heads in the degraded zone for 30+ seconds per read attempt.
The --reverse (or -R) flag reads the drive from the last LBA backward toward LBA 0. This is effective when damage concentrates near the outer platter edge, which corresponds to the lowest LBA addresses on most drives. Reverse mode also disables the drive's read-ahead cache, which can reduce controller overload on drives that stall during sequential forward reads.
The -c flag controls cluster size (the number of sectors read per I/O request). Reducing cluster size from the default 128 sectors down to 64 or 32 prevents buffer overflow on drives with fragmented bad sector domains. For a first pass on a degraded drive, combining -n (no-scrape) with a reduced cluster size extracts the maximum safe data before any aggressive retry behavior begins.
OpenSuperClone parameter strategy
OpenSuperClone's skip threshold controls how long (in milliseconds) the tool waits for a sector read before marking it as slow and skipping ahead. The default is 1000ms. For drives that respond slowly due to media degradation but are not mechanically failing, increasing this to 60000ms allows the controller time to complete its internal ECC retry cycle. For drives with intermittent head failures that lock the controller on bad sectors, reducing the threshold below 1000ms forces faster skipping and limits head exposure to damaged zones.
In Direct AHCI mode (bypassing the kernel entirely via OSCDriver), soft and hard reset timeouts are independently tunable. The default soft reset timeout is approximately 800ms; the hard reset timeout is approximately 8 seconds. For drives that hang frequently, reducing the soft reset to 250ms triggers faster recovery from controller stalls. The hard reset timeout controls how long OpenSuperClone waits before issuing a full COMRESET to the SATA port. If the drive requires a full power cycle to recover, the integrated USB relay (YKUSH 3) triggers automatically when both soft and hard resets fail.
Head Instability Detection and Adaptive Imaging
Head instability is the most dangerous failure mode for software imaging. A weak read/write head can still return data on some sectors while destroying the platter surface on others. Detecting which head is failing before it causes irreversible damage separates a successful imaging session from a catastrophic one.
HDDSuperClone's self-learning algorithm identifies a failing head by tracking where read errors cluster within the LBA address space. Hard drives map sequential LBA blocks to specific physical heads in a round-robin pattern across platter surfaces. When one head degrades, errors concentrate within that head's LBA zones while adjacent zones (mapped to healthy heads) read normally. After a configurable number of consecutive bad reads within a single zone, the algorithm calculates the zone boundaries and flags that head as damaged. It then skips the entire zone, images all data accessible from healthy heads, and returns to the damaged head's zone only after the safe data is secured.
ddrescue cannot perform this analysis. The Linux kernel block device abstraction presents the drive as a flat sequence of logical blocks with no physical geometry information. When ddrescue encounters bad sectors, it retries them without distinguishing whether the errors come from media defects (safe to retry) or a failing head (dangerous to retry). A weak head forced through its zone can score the platter, creating concentric scratch rings that destroy data stored on all heads sharing that platter surface.
PC-3000's MR-Head Shift technology operates at a level neither software tool can reach: it modifies the ROM and RAM adaptive parameters to disable a destroyed head before the spindle motor spins up. This prevents electrical shorts from a damaged head element that can kill surviving heads on the same head stack assembly. No software imaging tool can disable a head at the firmware level because the drive must be running for software to communicate with it.
Combining ddrescue Mapfile Semantics and HDDSuperClone Per-Head Triage on Degrading PMR/CMR Drives
On a Perpendicular Magnetic Recording (PMR) or Conventional Magnetic Recording (CMR) drive with one weak head and otherwise healthy platters, the choice between ddrescue and HDDSuperClone is not exclusive. The two tools track imaging state through fundamentally different data structures, and a lab workflow uses each one where it is safe.
ddrescue mapfile state machine
The ddrescue mapfile (renamed from logfile in version 1.20) is a plain-text record of every byte range on the source drive and its current status. The state machine uses five single-character status codes:
?non-tried: ddrescue has not yet attempted these blocks; the copying phase targets them first.+finished: blocks already read successfully and copied to the destination; never re-read from the source on resume./failed block non-scraped: blocks that survived the trimming phase and await sector-by-sector scraping.*failed block non-trimmed: blocks that failed the initial copying phase and have not yet had their edges trimmed inward sector by sector.-failed block bad-sector: blocks that failed the scraping phase. These are the targets of the retry passes (-r3requests three retry passes); in fill mode they can be overwritten with a marker string to identify which files lost data.
The mapfile also stores a status line with the current byte offset, current operation character, and current pass number, so a session interrupted by a crash, a kernel panic, or a drive dropping offline resumes at the exact pass and direction it was running. The mapfile is sequential and head-blind: every status entry refers to a contiguous byte range with no awareness of which physical head services that range.
HDDSuperClone domain log and adaptive command timeout
HDDSuperClone (and its actively maintained fork OpenSuperClone) records imaging state in a domain log that pairs LBA ranges with deduced head zones. When the self-learning algorithm accumulates a configurable number of consecutive bad reads inside a localized LBA cluster (typically around seven errors), it calculates the offset from earlier clusters and flags the entire zone as belonging to a failing head. The domain log entry then steers later passes around that zone until the healthy heads are fully cloned. ddrescue's mapfile has no equivalent field; it cannot record “this range belongs to head 2 and head 2 is failing.”
The second architectural difference is timeout granularity. When ddrescue issues a kernel read, the request is governed by the Linux SCSI error handler. The default block-device I/O timeout is 30 seconds. If the timeout fires, the SCSI error handler can spend an additional 10 to 12 seconds attempting an HBA port reset before the read returns to user space. While ddrescue waits, the drive is internally retrying the sector: the voice coil motor sweeps the head across the platter to reacquire the servo signal, the read channel re-runs ECC correction loops, and on a drive with a weak head, each of those retries adds mechanical wear. ddrescue cannot interrupt that wait through the kernel.
HDDSuperClone, running in Direct AHCI mode through OSCDriver, sets its own skip timeout, soft reset timeout, and hard reset timeout independently of the kernel. The default skip timeout of 1000 milliseconds can be reduced below that ceiling on a drive with intermittent head failure to limit how long the failing head dwells on damaged media on each attempt. The default soft reset timeout of approximately 800 milliseconds can be reduced to roughly 250 milliseconds on a drive that hangs frequently, so the imager triggers an ATA soft reset and resumes faster than the kernel error handler would. If the soft reset fails, the hard reset (COMRESET) timeout (default approximately 8 seconds) controls when HDDSuperClone escalates to a full SATA bus reset. If both resets fail to revive the drive, integration with a switchable power relay (a YEPKIT YKUSH 3 controls USB VBUS for 5V-only 2.5" drives; for 3.5" drives the YKUSH 3 is paired with an external 12V relay board so both rails drop together) lets the imager cut power, wait for spin-down, and restore power without operator intervention. None of these escape paths exist for a tool reading through the kernel block layer.
Why this matters on a degrading PMR or CMR drive
PMR and CMR drives map LBAs across heads in a serpentine zone pattern, so a weak head's damage concentrates inside its zones while neighboring zones, served by healthy heads, read at full interface speed. ddrescue treats the LBA space as flat and a long sequential pass will drag the failing head through its entire zone before reaching the healthier neighbors. Each 30-second wait on a failed sector inside that zone is a 30-second mechanical stress event for the weakest head on the head stack. HDDSuperClone isolates the failing head's zone, images the healthy heads first, and only returns to the weak zone once the safe data is secured.
How a lab actually sequences the two tools
The PC-3000 Portable III and DeepSpar Disk Imager sit upstream of either software imager. Before any sustained imaging begins, a firmware-aware pre-imaging stage handles work neither ddrescue nor HDDSuperClone can: disabling SMART self-tests during imaging so the drive does not spend actuator time on internal housekeeping, suppressing background defect reallocation, retrieving the drive's real per-head map from firmware geometry tables, and on PC-3000 specifically, executing MR-Head Shift to remove a destroyed head from the spin-up sequence before the spindle motor receives power. That hardware stage stabilizes the drive enough that any subsequent software imaging is operating on a known head map rather than a deduced one.
With the drive stabilized, HDDSuperClone runs the per-head triage pass through ATA pass-through, accumulating a domain log that flags the weak head's zone and produces a partial image of every healthy head. The output is a binary clone on a destination drive, plus a domain log that records exactly which LBA ranges remain unread and why.
ddrescue then runs final scrape passes against the produced image, not the patient drive. OpenSuperClone can export a ddrescue-compatible mapfile from its domain log, which means ddrescue can resume on the stable image with full knowledge of what is finished and what is still bad. The patient drive is powered down. ddrescue's strengths, -r3 retry passes, --reverse direction changes, and the trim/scrape state machine, run against a clone that cannot wear further on each retry.
A drive that needs this sequenced workflow has crossed past simple media degradation into partial head failure. Pricing for hard drive data recovery at the head-swap tier starts at $1,200–$1,500; donor drive cost is additional (Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.). +$100 rush fee to move to the front of the queue is available when timing matters.
How Does PRML Read Channel Tuning Recover Marginal Sectors?
When a bad-sector-dense drive with head weakness refuses to return data, the question is not whether the imaging tool will retry; it is whether the drive's analog read channel can be persuaded to decode the signal on a different set of rules. This is the layer ddrescue cannot reach and the reason mechanical hard drive data recovery paired with PC-3000 Data Extractor pulls data that open-source imagers abandon.
The read channel pipeline
Every modern HDD runs incoming flux through a fixed signal chain: the MR/TMR head preamplifier raises the microvolt-level signal, an Automatic Gain Control loop and Variable Gain Amplifier normalize amplitude, a Continuous Time Filter (CTF) performs anti-aliasing and pulse-slimming, an ADC samples into the digital domain, an equalizing Finite Impulse Response (FIR) filter shapes the sampled waveform to match a target polynomial (PR4, EPR4, EEPR4), and a Viterbi maximum-likelihood sequence detector walks a trellis of branch metrics to pick the most probable bit sequence. An LDPC or Reed-Solomon decoder handles whatever residual errors remain. This is the Partial Response Maximum Likelihood (PRML) architecture; modern drives use extended variants (EPRML, EEPRML) to handle the inter-symbol interference that comes with high areal density.
Why ddrescue retries fail on head-weakness damage
ddrescue's retry loop reissues the same block-layer read through the kernel. Each attempt hits the drive with identical electrical conditions: same AGC gain, same FIR tap weights, same Viterbi thresholds. If the drive's internal decoder could not resolve the sector on the first attempt, the analog noise profile on the second attempt is not meaningfully different, and the Viterbi detector fails to establish a valid path again. The heads keep sweeping the damaged zone on each retry; each sweep adds mechanical wear without changing the decoding math.
How multi-pass imaging changes the physical read margin
HDDSuperClone and OpenSuperClone do not alter the read channel directly, but the head-skip and reverse-direction options change the approach velocity and track-seek direction before each read attempt. Allowing the drive to complete its Zero Acceleration Path (ZAP) and servo re-adaptation between passes produces a slightly different analog waveform on the next retry; on a marginal sector that is close to the decoder threshold, that small change sometimes flips the Viterbi branch metric enough to resolve the bits. DeepSpar DDI pushes this further by gating commands at the hardware layer and idling the drive between passes for controlled thermal recovery, so a thermally drifting preamp returns to a lower-noise state before the next attempt.
Per-head FIR and Viterbi tuning on PC-3000
PC-3000 Data Extractor reaches the adaptive parameters the drive normally keeps private. On Western Digital ROYL drives, Module 47 holds per-head microjogs, preamp bias values, and read-channel tuning constants; on Seagate F3 drives, the diagnostic terminal's Level 7 command set and the Read Adaptive Parameters system file (SysFile 06) expose adaptive slots to the operator. The technician can shift FIR tap weights away from the factory target polynomial, raise the VGA gain on a weak head, or alter the read channel's adaptive tracking parameters so the internal ECC engine resolves sectors it would otherwise reject. Disabling the drive's internal Reed-Solomon/LDPC acceptance and letting the extractor reassemble sectors from raw samples lets a head that is producing marginal but still-informative flux return usable data. That per-head analog adaptation is why a drive ddrescue writes off as uncorrectable still images cleanly on a PC-3000-paired workflow.
Drive-Family-Specific Imaging Strategies
Different HDD families have unique firmware behaviors that determine which imaging tool is appropriate. A parameter configuration that works on one drive family can cause permanent data loss on another. The following pathologies are common enough that anyone imaging drives regularly will encounter them.
Seagate F3 translator damage
Seagate drives using the F3 firmware architecture store their LBA-to-physical translator in System File 0x1C of the Service Area. When this system file corrupts, the drive reports 0 GB capacity to the BIOS. Neither ddrescue nor OpenSuperClone can image a drive with no valid LBA mapping because there are no addressable sectors to read.
PC-3000 connects to the Seagate diagnostic terminal (a serial interface on the drive's PCB) and regenerates the translator using vendor-specific commands. If the drive's defect list contains conflicting entries, the translator regeneration fails and the defect list requires manual editing before the translator can rebuild. This is firmware surgery that no software imaging tool can perform.
Seagate Rosewood SMR complications
The Seagate Rosewood family (including the ST2000LM007) uses Shingled Magnetic Recording with a Media Cache Management Table (MCMT) stored in System File 348. When a shingled band migration is interrupted by power loss or firmware crash, the MCMT corrupts and the drive enters a degraded state where reads stall intermittently.
The critical danger with Rosewood drives is that the standard F3 translator regeneration command (m0,6,3,,,,,22) is fatal. On non-SMR Seagate drives, this command safely rebuilds the translator. On Rosewood, it wipes the MCMT, destroying the mapping between the media cache and the final data bands. PC-3000 handles Rosewood by patching System File 93 (the SMP flags) to disable background auto-repair before imaging begins. This prevents the drive from attempting to complete the interrupted band migration during the imaging session.
Western Digital encrypted external drives
Western Digital external drives in the Spyglass family (e.g., WD40NMZW, WD50NMZW) integrate the USB 3.0 interface and a Self-Encrypting Drive (SED) AES engine directly into the drive's main Marvell microcontroller unit. There is no separate bridge chip; the native USB PCB has no SATA connector, and the cryptographic key is tied to the unique MCU on the original PCB. A simple board swap fails because the key does not move with the platters.
ddrescue and OpenSuperClone can image the drive over USB, but they see the encrypted data stream produced by the native SED engine. Recovery requires PC-3000's Western Digital module to access the drive through vendor-specific firmware modes (typically via a micro-soldered SATA bypass to the native PCB) and apply the SED key during imaging to produce a decrypted image.
When PC-3000 Data Extractor Is Required
When software imaging tools reach their architectural limits, professional hardware provides firmware-level access that no software can replicate. The following failure modes require PC-3000 intervention because the drive's own firmware blocks access to the data at a level below the operating system.
- SED/OPAL firmware locks
- Drives with Self-Encrypting Drive (SED) or TCG Opal firmware encryption reject all read commands with ATA abort errors or return ciphertext to any standard imaging tool. PC-3000 accesses the drive's firmware through the diagnostic terminal and modifies the security configuration to remove the SED lock without erasing the encryption key, allowing the Data Extractor to image the decrypted data directly.
- Thermal asperity and degraded read heads
- A thermal asperity event occurs when a read head's magnetoresistive element makes intermittent contact with the platter surface, generating heat spikes that distort the read signal. PC-3000 adjusts the Initial Bias Current and MR preamplifier gain to compensate for the weakened signal, reading data that is invisible to ddrescue and OpenSuperClone. PC-3000 can also disable the drive's internal ECC engine and perform raw reads with custom LDPC (Low-Density Parity-Check) correction applied externally, recovering sectors the drive's own error correction rejects.
- Diagnostic port locks (Seagate Rosewood)
- Seagate Rosewood drives can enter a state where the Microcode Overlay fails to load, indicated by diagnostic LED code 0x000000BB. In this state the drive ignores terminal interrupts and refuses both ATA commands and serial console access. PC-3000 reads the ROM chip directly, patches the Diagnostic Port Lock flag, and rewrites the ROM to restore terminal access before any imaging begins.
- Firmware-level head disable before spin-up
- When a head element is electrically shorted or physically destroyed, spinning the drive sends current through the damaged element on the head stack assembly, which can burn out the preamplifier and kill all remaining heads. PC-3000's MR-Head Shift modifies the ROM/RAM adaptive parameters to remove the damaged head from the spin-up initialization sequence. The motor spins, the healthy heads load onto the platters, and the destroyed head remains parked. This is the only way to safely power a drive with a dead head element.
If your drive exhibits any of these firmware-level failures, professional hard drive recovery with PC-3000 hardware is the only viable path. Attempting software imaging on a drive with an active SED lock, diagnostic port lock, or shorted head element produces no data and risks making the failure permanent.
Frequently Asked Questions
Can I use HDDSuperClone on a failing SSD?
No. HDDSuperClone sends ATA commands designed for spinning hard drives with physical read/write heads. SSDs use NAND flash memory with no moving parts and a completely different command set. For SSD failures, the recovery path depends on the controller and encryption architecture, not disk imaging software.
My hard drive is clicking. Should I run ddrescue or HDDSuperClone?
Neither. Clicking means the read/write heads cannot locate the servo tracks and are slamming against the crash stop on each attempt. Running any imaging software on a clicking drive forces those damaged heads across the platters, scraping off the magnetic coating that holds the data. Power the drive off immediately. Recovery requires opening the drive in a particle-controlled environment, swapping the heads with matched donors, and imaging with a PC-3000 or DeepSpar Disk Imager.
What is the difference between DMA and PIO mode in HDDSuperClone?
DMA (Direct Memory Access) lets the drive controller transfer data directly to system memory at full speed. If the controller hangs on a bad sector, the DMA engine can lock up, requiring a power cycle. PIO (Programmed Input/Output) makes the host CPU poll the drive for each data word. PIO is slower but eliminates DMA timeout crashes, making it a safer mode for drives with intermittent controller hangs.
Does ddrescue or HDDSuperClone recover my files?
No. Both tools are disk imagers. They create a raw, sector-by-sector binary copy of the physical drive onto a healthy destination. The output is a .img file or a cloned disk containing the raw data. To see files, you run file system recovery software (DMDE, R-Studio, UFS Explorer) against the cloned image. Imaging and file recovery are two separate steps.
What is OpenSuperClone and how does it relate to HDDSuperClone?
HDDSuperClone was abandoned by its original developer (Scott Dwyer), but the source code was released. OpenSuperClone is the actively maintained fork, which includes OSCDriver with DKMS support for modern Linux kernels through 6.11.x. The core ATA pass-through imaging engine is functionally identical; OpenSuperClone adds updated driver compatibility, a modernized live ISO (OSC-Live, built on Xubuntu with UEFI Secure Boot), and integrated USB relay support for automated hardware power cycling during long imaging sessions.
Why does my Western Digital drive image at kilobytes per second in ddrescue?
Western Digital drives using the ROYL firmware architecture have a background defect reallocation process that writes to Module 32 in the Service Area. When the drive encounters widespread media degradation, this process runs continuously, overloading the drive's microcontroller and dropping transfer rates to single-digit KB/s. ddrescue can't fix this because it reads through the Linux kernel and has no access to vendor-specific firmware commands. OpenSuperClone (via its integrated HDDSuperTool) can issue Vendor Specific Commands to patch Module 32 in RAM, disabling the reallocation loop and restoring full interface speed. If the Service Area itself is corrupted beyond a RAM patch, the drive needs a PC-3000 for firmware-level repair.
Why can't ddrescue or HDDSuperClone recover data from an SSD showing SATAFIRM S11?
When a Phison-controlled SATA SSD (such as the PS3111-S11) suffers Flash Translation Layer corruption from NAND cell degradation, the controller's ARM core halts and drops into a fail-safe ROM mode. The drive identifies as 'SATAFIRM S11' with 0 bytes or 1 GB reported capacity. The entire LBA mapping is gone; there are no sectors to read. Neither ddrescue nor OpenSuperClone can access data that has no logical address. Recovery requires a PC-3000 SSD to inject volatile loader microcode directly into the controller's RAM (Technological Mode) and rebuild the translator from raw NAND blocks.
What ddrescue settings should I use on a failing hard drive?
Run a first pass with the -n flag (no-scrape) to grab all easily readable data without retrying bad sectors. Set --min-read-rate=10M so ddrescue skips ahead whenever transfer speed drops below 10 MB/s, which prevents the tool from grinding on sectors where internal ECC correction loops are stalling the controller. After the first pass completes, run a second pass with -r 3 --reverse to retry failed sectors up to three times reading back-to-front. The reverse pass is effective when damage concentrates near the outer platter edge (LBA 0) because it approaches bad regions from the opposite direction. Always image to a separate destination drive, never to a partition on the source.
How does HDDSuperClone detect which head is failing?
HDDSuperClone's self-learning algorithm tracks where read errors cluster by LBA range. Hard drives map sequential LBA blocks to specific physical heads, so errors that repeat within the same LBA zone indicate a failing head on that platter surface. After a configurable number of consecutive bad reads within a zone, the algorithm identifies the head boundary, calculates the LBA offset for that head's entire zone, and skips it. The tool images all data from healthy heads first, then returns to the damaged head's zone for a slow, controlled extraction. ddrescue cannot do this because the Linux kernel block device abstraction hides the physical head-to-LBA mapping entirely.
What does DeepSpar Disk Imager do that OpenSuperClone does not?
DeepSpar Disk Imager (DDI) is a hardware appliance. It uses a dedicated PCI-e or USB 3.0 adapter that surfaces ATA command status in real time and controls SATA power through an on-board relay. When a drive locks up during imaging, DDI can cut power, wait for spin-down, and restore power without touching the host OS; OpenSuperClone relies on a separate YKUSH USB relay to approximate this behavior. DDI explicitly disables the drive's SMART subsystem and background auto-relocation processes during imaging to eliminate firmware overhead and prevent the drive from spending actuator time on internal housekeeping. OpenSuperClone exposes SMART in its GUI but treats it as advisory; polling SMART on a failing drive can trigger background tasks that accelerate mechanical failure. Neither tool performs firmware surgery; a drive that needs translator rebuild or SA module patching still requires PC-3000.
Which SMART attributes matter most when choosing imaging parameters?
Four attributes change the strategy. Reallocated Sector Count (ID 5) shows historical bad-sector remapping and indicates media degradation. Current Pending Sector Count (ID 197) shows sectors the drive will retry with internal ECC, which can stall the controller for tens of seconds; a high value means lower --min-read-rate or tighter OpenSuperClone skip timeouts. UDMA CRC Error Count (ID 199) rising during imaging means the SATA cable or USB bridge is corrupting data, not the platters; replace the cable before continuing. Spin Retry Count (ID 10) rising indicates spindle bearing or stiction problems; at that point stop and send the drive to a lab.
When should I stop using ddrescue and send the drive to a lab?
Stop immediately if the drive clicks, beeps, grinds, or produces any repetitive mechanical noise. These sounds indicate head stack assembly failure, spindle seizure, or platter contact, and continued imaging will destroy data. Also stop if the drive drops offline repeatedly during imaging and requires power cycling to resume, or if imaging speed stays below 1 MB/s with no improvement after adjusting ddrescue parameters (--min-read-rate, --reverse, cluster size reduction). At that point the failure has progressed beyond what software can safely handle, and the drive needs a head swap or firmware repair using PC-3000 hardware in a particle-controlled environment.
If your drive has crossed the boundary where software imaging tools fail, professional hard drive data recovery or SSD data recovery starts with a free diagnostic. Drives exhibiting the SATAFIRM S11 firmware failure or WD slow-responding symptoms that resist OpenSuperClone's RAM patches require PC-3000 hardware intervention. We charge no fee if recovery isn't possible; HDD head swap recovery starts at $1,200–$1,500.
If you are experiencing this issue, learn about our hard drive recovery service.