3.9.4 (2026-10-13)
CD extraction writes cooked sectors again (#11)
- Extracted BINs are Redump-identical again. The built-in reader called CHDSharp with
cooked:false, writing full 2448-byte raw frames (data plus 96-byte subcode) instead of chdman's cookedDataSizebytes per frame. A single-track MODE2_RAW disc extracted as 546,178,176 bytes (SHA1072ea00f...) instead of 524,759,424 bytes (SHA19b4c1b51...) while the CUE looked identical. Extraction now passescooked:true, matchingchdman extractcdbyte-for-byte (subcode omitted, audio byte-swapped). Reproduced against Armored Core (USA) (Rerelease). - Verify passing for the bad rebuild is by design. A CHD built from the oversized BIN is internally consistent (232,218 frames instead of 223,112; 267,908,519 bytes), so both
chdman verifyand CHDStudio Verify report success. Verify checks the header hashes, not Redump: the header SHA1 (6dc714d9...) and the file SHA1 (3e1b20c5...) differ from 7-Zip's file hash by design. Delete BINs/CHDs produced by the broken extraction and re-extract.
Housekeeping
- Package updates: Meziantou.Analyzer 3.0.299 → 3.0.303, Microsoft.NET.Test.Sdk 18.10.1 → 18.11.0, VideoGameFileSystemParser 1.3.0 → 1.4.0.
- Test suite: new
ExtractCd_CookedMatchesOriginalBin_RawAddsSubcoderegression test; 1105 unit tests pass (Category!=Integration).