The Read Error Page

[JERisBRISK]

The help text of https://www.makemkv.com/errors/read/ is mostly correct, but can be misleading.



Below, I've quoted the relevant text from the Read Error page that MakeMKV links to when a Read Error occurs. I'll go over it section by section, making editorial commentary along the way, and finally I will introduce some suggested amendments:

The ONLY reason for this error is inability of the drive to read the data from the disc.

The above statement is accurate but overly simplistic.

This is caused by a damaged disc, failing drive, or both. The error comes from the drive before MakeMKV has an opportunity to look at the data.

The statements above statements are only partially correct. There is a third option.

Nothing else can cause this error - no protection, no software issue - only physical disc or drive damage.

This statement is false. The third option is a software issue, just not the software you're thinking of when I say 'software.' (Please, stow the torches and pitchforks and let me explain...)

Long version:

Modern Operating Systems like Windows do not (in general) talk directly to hardware. They use one or more layers of software abstraction (Windows' is aptly named the Hardware Abstraction Layer, or 'HAL'), device-specific hardware drivers, and on or more API layers on top of those to make hardware easier and more reliable to deal with for modern application software and systems software developers.

Code: Select all

+---------------------------+
| Windows Software          |
| Application               |
+---------------------------+
            |
            | (API Calls)
            v
+---------------------------+
| Win32 Subsystem /         |
| NT User / NT GDI          |
+---------------------------+
            |
            | (System Calls)
            v
+---------------------------+
| Kernel Mode Executive     |
| (I/O Manager, etc.)       |
+---------------------------+
            |
            | (IRP - I/O Request Packets)
            v
+---------------------------+
| Device Drivers            |
| (e.g., Optical Disc       |
|  Driver - CDROM.SYS)      |
+---------------------------+
            |
            | (Hardware Access)
            v
+---------------------------+
| Hardware Abstraction      |
| Layer (HAL.DLL)           |
+---------------------------+
            |
            | (Bus/Port I/O, Interrupts)
            v
+---------------------------+
| Actual Hardware           |
| (e.g., Optical Disc Drive)|
+---------------------------+

Many drivers operate like finite state machines. The software in the driver tells the hardware to do something and then makes a note of the expected (and sometimes verified) state. This could be things like 'open the tray' or 'start reading the disc'. When the OS asks the drive what it's doing, the driver will return the current state of affairs, acting as a proxy for the drive itself.

Transitions between states require the driver's internal 'state machine' to accurately reflect the actual state of the hardware, and there are rules that govern valid and invalid state transitions for every possible operation the drive can perform. (E.g., if your software instructs the drive to 'eject' but the tray is already in the open state, it shouldn't try to eject again because it's pointless to do so; similarly, if you are burning a disc (an operation that shouldn't be interrupted lightly), the state machine might reject Eject requests because that's not a valid state transition).

When the state of the hardware and the internal state of driver software align, things "just work."

When they get out of sync, it's utter chaos and it can lead to the driver thinking the drive is reading one sector when in fact it's off somewhere else. This causes all kinds of oddities, weird sounds, and garbled results. Sometimes the drive panics. Sometimes the driver panics. Sometimes Windows panics. What ultimately results is a slew of errors that get progressively worse the more the drive is used.

When the driver's internal state is corrupted, power cycling the drive often doesn't help (it can, depending on how the driver handles removal and re-insertion of the device, but there are cases where it hasn't worked for me). Restarting MakeMKV doesn't help. Cleaning the disc (or swapping to a different one) doesn't help. Why? Because it's not the drive's fault, the disc's fault, or MakeMKV's fault. It's the driver's fault (or, far less commonly, the abstraction layer beneath the driver).

What fixes this corrupted state (assuming the driver itself isn't corrupted on the hard disk)?

Rebooting the computer!

Anecdotal Evidence
About once every 3-4 months, I run into a scenario where the driver gets in a bad state and refuses to read any disc. MakeMKV always directs me to https://www.makemkv.com/errors/read/, and in these specific cases, the page is wrong (though well-intentioned), and all I really need to do is reboot my computer. Once the system comes back up, the very same disc with the very same drive will copy perfectly because the driver's internal state corruption is cleared and the driver and the hardware are in sync once more.

To wit, I propose the following re-wording of the Read Error page's first paragraph:

This error occurs when the Operating System itself is unable to read the data from the disc. This can be caused by several reasons including driver errors, damaged discs, a failing drive, or a combination thereof. The read error is reported from the drive (via the Operating System) before MakeMKV has an opportunity to even look at the data. Nothing else can cause this error. It is not related to copy protection or higher-level concerns. It is not an error in MakeMKV. It caused by hardware driver errors, a damaged disc, or mechanical failure in the disc drive itself.

The simplest and easiest way to rule out a driver error is to reboot your computer and try the operation again. Many times this will correct the issue by forcing a driver with a corrupted internal state to unload and re-load from scratch. If the error persists, it is most likely a damaged disc or a mechanical failure in the drive itself. If a different disc works after a reboot, the first disc is in question. If a second disc also results in read errors, your drive is most likely failed or failing.

If you're convinced that your disc and drive are healthy, then you can try repairing your system files to ensure your drivers are not corrupted. If that fails, and a subsequent reboot fails to clear the issue, then the disc or the drive are the only viable candidates.

... or something to that effect.

Short (TL;DR) Version:

The third, equally viable cause of Read Errors (and perhaps the most frequent cause), is an internal state or other corruption error in the disc driver software. Such software errors (internal state corruptions) will cause the drive to behave erratically and will manifest most often as read errors or other hardware errors (SCSI errors, etc.) until the system is rebooted (most common) and/or the driver or failing system software component is repaired (less common).