- `<name>.redump.json` - JSON metadata describing the layout, hashes, drive
profile, PFI/DMI filenames, and lead-in capture status.
-For the GDR-8050L redump path, the 32-sector game lead-in follows the original
-dumper's option-1 behavior and is written as zero-fill before copying unlocked
-XDVDFS data from source LBA `32`. For non-8050L Xbox strategies, FriiDump still
-attempts to read lead-in sectors when the active drive/profile can expose them,
-and zero-fills only unreadable lead-in sectors.
+For the GDR-8050L redump path, the 32-sector game lead-in is captured from
+unlocked source LBA `0..31` before copying XDVDFS data from source LBA `32`.
+FriiDump 0.5.3.13 proved this placement with cache-aligned raw-sector IDs. The
+native libfriidump path retains per-sector zero-fill only for a genuinely
+unreadable lead-in sector and records the read/zero-fill counts; the reference
+Xbox path treats failure to capture the proven lead-in as a dump failure.
FriiDump also records a `discimagecreator_reference` section in the JSON. The
redump-style constants are checked against DiscImageCreator's Original
`--xiso` is a separate output mode and cannot be combined with `-i`, `-r`, or
`-a` in one run.
+## Read-only XGD1 logical-boundary probe
+
+FriiDump 0.5.3.11 adds a Windows-only diagnostic that does not create or alter
+an ISO:
+
+```powershell
+friidump -d f: --xgd1-layout-probe "docs\debug\xgd1-layout-probe.json"
+```
+
+The mode is currently restricted to the GDR-8050L challenge-handshake profile.
+It performs the following evidence sequence:
+
+1. Record the entry READ CAPACITY(10) state.
+2. Cycle the tray and verify the exact 6,992-sector locked/video capacity.
+3. Probe selected boundary LBAs with one-sector READ(10) and READ(12).
+4. Apply the established full Xbox handshake and verify the unlocked/game
+ capacity.
+5. Probe the corresponding unlocked-source and capacity-edge LBAs.
+6. Restore the locked/video entry state when the run began locked.
+7. Atomically publish the JSON report and issue STOP UNIT.
+
+Each command record includes the Win32 result, SCSI status, sense
+key/ASC/ASCQ, all-zero/nonzero classification, SHA-1, and full 2048-byte sector
+data when the read succeeds. Expected out-of-range failures are evidence and
+do not by themselves invalidate the report.
+
+This is a logical-read probe, not a physical-sector dumper. It does not assert
+that inaccessible filler is zero, does not replace the current synthetic
+ranges, and does not promote the reconstructed XGD1 image to Redump identity.
+
## GDR-8050L handshake sequence
The GDR-8050L path performs this sequence when switching from visible DVD-video view
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 unresolved zero-filled pregame and postgame 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.
+
+## XGD1 cache-aligned raw-ID geometry correction (0.5.3.13)
+
+The first 0.5.3.12 hardware report contained a mixture of valid physical IDs
+and stale/block-start cache entries. The corrected probe now performs the same
+zero-transfer READ(12) flush and 16-sector block alignment used by the proven
+modified-GDR-8050L Method 8 path. It dumps only the raw 12-byte header and
+four-byte EDC for the selected slot, decodes the layer bit, normalizes layer-1
+PSNs by 24-bit complement, and compares each sample with its mapped full-output
+LBA.
+
+The live 0.5.3.13 run matched all 13 selected samples and set
+`physical_geometry_resolved` true. The result proves the physical placement of
+the visible video ranges, the full unlocked game range, and the omitted
+pregame/postgame spans. It does not establish the byte content of the omitted
+filler spans.
+
+## Drive-captured XGD1 game lead-in (0.5.3.14)
+
+The successful 0.5.3.13 geometry report established these adjacent mappings:
+
+- unlocked source LBA `0..31` -> output LBA `198144..198175`, raw PSN
+ `0x060600..0x06061F`;
+- unlocked source LBA `32` -> output LBA `198176`, raw PSN `0x060620`, where
+ the `MICROSOFT*XBOX*MEDIA` XDVDFS descriptor begins.
+
+FriiDump 0.5.3.14 therefore replaces the historical synthetic 32-sector
+game-lead-in write with drive capture from source LBA `0..31`. This changes the
+full XGD1 output bytes and requires a new live full-disc dump plus Redump DAT
+comparison. The 191,312-sector pregame and postgame spans retain zero-filled
+placeholder content: their physical geometry is proven, but their inaccessible
+byte content is not.
+
## Logging
The original Xbox reference logger is now the shared FriiDump run logger. Every
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.
+
+## XGD1 raw-sector ID geometry probe (0.5.3.12)
+
+Live 0.5.3.11 evidence closed the ordinary logical-read branch: all 17
+successful READ(10)/READ(12) pairs were identical, the locked view stopped at
+6991, and the unlocked view stopped at 3431263. Output-space LBAs outside
+those capacities returned ILLEGAL REQUEST / LBA OUT OF RANGE (05/21/00).
+This means neither READ opcode exposes a hidden logical source for the
+synthetic pregame or postgame ranges.
+
+`--xgd1-raw-id-probe <file>` is the next read-only geometry probe. On the
+modified GDR-8050L profile it fills the drive cache with a controlled 16-sector
+READ(12), dumps the selected 2064-byte raw sector through `E7 48 49 54 01`, and
+decodes bytes 1..3 of the raw DVD ID as the physical-sector number. Adjacent
+locked and unlocked boundary samples can establish whether the active logical
+views map linearly or jump across omitted physical regions.
+
+Raw physical IDs do not reveal the contents of inaccessible filler sectors.
+No zero-filled range may be promoted to exact merely because its geometry is
+confirmed.
+
+
+## 0.5.3.15 live closure
+
+The required 0.5.3.14 hardware run completed on the modified GDR-8050L
+revision `0012`.
+
+The drive-captured source LBA `0..31` lead-in was independently verified at
+output LBA `198144..198175`, and source LBA `32` remained the XDVDFS boundary at
+output LBA `198176`.
+
+Final output:
+
+- sectors: `3,820,880`;
+- bytes: `7,825,162,240`;
+- SHA-256:
+ `5995f823c6d67b9e3e3b3e1c2b54e1e036793188bec6b5be4220f559305f53b9`.
+
+The Microsoft Xbox DAT scan returned `NO EXACT MATCH`. Pregame and postgame
+geometry is proven, but their inaccessible content remains zero-filled and
+unresolved.
+
+Without `--redump-dat-dir`, DAT discovery checks the executable-relative
+`redump_dat` directory before the current working directory. This prevents
+runner working directories from hiding the packaged DAT set.
Return to the FriiDump site / friidump.git / blobdiff