On Windows, GDR-8050L `-i` and `-X` are dispatched to a copied-in reference implementation from jtryba's original Xbox dumper (`main.c`, `utils.c`, `unlock.c`, and helpers). This preserves the original state-machine order instead of approximating it in FriiDump's generic read loop. It also preserves the reference timing sleeps: tray-cycle 3000 ms, readiness settle 1500 ms after success or 10000 ms fallback, RefreshVolume's 1000 ms wait, and the explicit post-refresh 2000 ms settle.
-For GDR-8050L, bare `-i` derives `Title[MediaID].iso` from the XBE title and DMI media ID, and bare `-X` derives `Title[MediaID].xiso`. Supplying `-i <file>` or `-X <file>` is an explicit filename override. The first unlock/metadata pass exists for that size/title/media-ID discovery before the actual dump mode runs.
+For GDR-8050L, bare `-i` derives `Title[MediaID].iso` from the XBE title and DMI media ID, and bare `-X` derives `Title[MediaID].xiso`. Supplying `-i <file>` or `-X <file>` is an explicit filename override. FriiDump prepares the game view for that title/media-ID discovery with state-aware READ CAPACITY classification: it reuses an already-unlocked view, otherwise it attempts one direct full handshake without a media transition. A tray-cycle-and-retry path exists only as recovery when direct verification fails.
+
+FriiDump 0.5.3.8 returns the reference dumper's actual finalized ISO filename,
+byte count, CRC32, MD5, SHA-1, and SHA-256 to the common Redump verifier after a
+successful option-1/full-disc dump. This supports both explicit `-i <file>` and
+bare `-i` with XBE/DMI-derived names without hashing the 7.29 GiB file twice.
+Use `--redump-report <file>` to publish the same atomic schema-2 evidence record
+used by GameCube/Wii paths.
+
+The current XGD1 image map contains documented synthetic zero-filled ranges.
+Accordingly, `NO EXACT MATCH` is a valid evidence result even when all readable
+sectors were acquired successfully. The verifier reports acquisition evidence
+and archive identity as separate claims. `-X` remains outside DAT verification
+because XISO is not a full Redump disc image.
GDR-3120L remains on the separate `FF 08 01` vendor lock/unlock path. Forced Xbox mode on non-supported Xbox unlock profiles is rejected rather than routed through FriiDump GC/Wii fallback methods.
the run and logged. If all candidates fail, seed retrieval stops and the log
records each failed probe. Unsupported/non-HLDS drives now keep zeroed HLDS
profile fields so stale cache-base/window values are not printed.
+## FriiDump 0.5.3.9 live-summary closure
+
+The embedded GDR-8050L reference path returns finalized hashes, output size and
+sector count, title, media ID, and elapsed evidence to FriiDump. The final HLDS
+summary therefore describes the reconstructed output rather than the locked
+6,992-sector view. GC/Wii seed terminology is marked not applicable for this
+Xbox authentication path. DumpXboxGameDisc no longer spins the drive down
+internally; FriiDump performs one final STOP UNIT after Redump verification.
+
+## FriiDump 0.5.3.10 state-aware metadata-entry handshake
+
+The copied GDR-8050L bridge no longer performs the unconditional sequence
+`unlock -> tray cycle -> unlock` before title/XDVDFS probing.
+
+Normal entry paths are now:
+
+- already-unlocked entry: verify readiness, reuse the game view, and read title,
+ XDVDFS, media ID, and physical metadata;
+- locked/video entry: issue one full handshake directly, refresh/read capacity,
+ and continue only after the game view is observed;
+- recovery only: when direct verification fails, cycle the tray once, retry the
+ full handshake once, and fail cleanly if the game view is still absent.
+
+The dump itself still performs one intentional media transition to restore the
+locked/video view before VIDEO-L0 and VIDEO-L1 capture, followed by one full
+handshake for game/XDVDFS sectors. Therefore the expected normal cold-state
+sequence is `unlock -> metadata -> tray cycle -> video -> unlock -> game`, and
+an already-unlocked entry omits the first unlock.
+
+XDVD sidecar authentication evidence now distinguishes two separate facts:
+
+- `unlock_requires_media_transition: false`
+- `locked_video_view_restore_requires_media_transition: true`
+
+The compatibility field `requires_media_transition` is also `false`; it refers
+to authentication/unlock acceptance, not to restoring the locked video view.
Return to the FriiDump site / friidump.git / blobdiff