Matthew Jackson
94a876664b
All six describe code that does something different from what they say, which is the class of defect that gets a maintainer to write a bug on purpose. docs/clpi.md presented the CLPI stream-PID entry as byte-aligned 2/2/2/4/4-byte fields with a 32-bit fine-entry count. It is one 80-bit packed block — reserved(10) + EP_stream_type(4) + num_EP_coarse(16) + num_EP_fine(18) + EP_map_start_address(32) — and num_EP_fine is 18 bits. Anyone parsing to the doc's offsets would read garbage. Replaced with the real bit layout. docs/udf.md said read_directory()'s recursion cap is 3; MAX_DIR_DEPTH is 8. TROUBLESHOOTING.md called Pass 1 `recovery::copy`. The engine's `sweep` is documented as "Pass 1 of a multipass rip"; `copy` is the dispatch verb that chooses between sweep and patch. This inconsistency was mine, introduced in the 1.6.0 doc rewrite. docs/drive-access.md already said `sweep` and was right — a round-2 finding claimed the opposite on the grounds that `recovery::sweep` appears nowhere else in this crate, which it cannot, being in another crate. io/pipeline.rs cited `disc::patch` as WRITE_THROUGH_DEPTH's caller; that moved to freemkv-engine in 1.6.0 and no `patch` exists here. truehd.rs's doc on mlp_major_sync_crc_ok said the trailer is compared big-endian while the body compares u16::from_le_bytes — and a big-endian compare was the bug the function was fixed for, so the comment described the defect rather than the code. sector/decrypting.rs claimed the decorator owns "the only mutable state (its call-count cap and spent flag)". DecryptingSectorSource has no such fields and no KeyFetch field at all in this revision.
libfreemkv Documentation
Technical documentation for libfreemkv, the open source optical drive library.
Start Here
Disc to Rip: End-to-End Flow — How the library goes from a disc in the drive to decrypted content. Read this first.
Reference
| Document | What it covers |
|---|---|
| Architecture | Module map, design principles, error codes, platform support |
| Drive Access | Drive, SCSI transport, profiles, unlock, why raw mode is needed |
| Rip Recovery | What this crate owns of the recovery model: single-shot Drive::read, SenseFamily, DiscStream batch halving (the strategy itself moved to freemkv-engine in 1.6.0) |
| AACS Encryption | Key resolution (4 paths), content decryption, bus encryption, SCSI handshake |
| UDF Filesystem | UDF 2.50 with metadata partitions, pointer chain, how files are read from disc |
| MPLS Playlists | Playlist format, play items, STN stream table, coding types |
| CLPI Clip Info | EP map (coarse + fine entries), timestamp-to-sector mapping, extent calculation |
| API Design | Stream API design, PES pipeline, input/output resolution |
Reading Order
If you want to understand the whole library:
- Disc to Rip — the big picture
- Architecture — how modules fit together
- Drive Access — how we talk to hardware
- UDF → MPLS → CLPI — how disc content is structured
- AACS — how encryption works and how we break it
API Documentation
Generated API docs are on docs.rs/libfreemkv.