Measure: this file was written before any tool was pointed at RES2 LEON.bin
or RES2 CLAIRE.bin. The only things I had seen were the four file names, their
sizes, the two .cue files, and the briefing. It is not edited afterwards.
Section §A repeats what the briefing measured for me and is worth no points —
the last eight briefings in this branch contained five, four, eleven, nine,
seven, nine, eleven and nine errors, so §A is a set of claims to be checked, not
a set of facts to be inherited. Section §B states inferences drawn from §A
before measuring — reasoning, not bets, named so the scoring chapter can tell
them apart. The clauses are C01..C70, each marked method (how a
measurement will behave) or content (what the objects will turn out to
contain).
This is the first object in thirty that is two. Every clause below that carries a number names which disc it is about, or says "both", or says which of the five denominators it uses. A clause that does not is a defective clause and should be scored as a miss on those grounds alone.
Scoring lives in 19 — The scoring and is produced by
python tools/checkscore.py docs/19-scoring.md, not by adding up here.
| the objects | RES2 LEON.bin 758,583,504 bytes and RES2 CLAIRE.bin 722,626,128 bytes, plus a 72- and a 74-byte .cue. Sum 1,481,209,632 |
| the cues | one track each, MODE2/2352, INDEX 01 00:00:00, no audio track |
| geometry | 322,527 and 307,239 sectors of 2,352, remainder zero on both. Sum 629,766 |
| hashes | Leon sha1 0f27e8f50bf5bfc8702950d025b0b960154afb68, md5 24c61858810833fe6a8de54effa0fd9a; Claire sha1 5deeb74d6440bc15355cf6e7e152a4d9ff90ea3a, md5 5cc0402f324fdc4bf432cd5d35b7f46a |
| mtime | 2026-09-01 19:36:00 on all four files — the day they arrived here, and nothing else |
| the frame | Leon: 322,527 good sync, 322,527 MSF = LBA+150, mode 2 on 100 %, Form 1 on 100 %, Form 2 zero, 0 subheader copies disagreeing, 322,527 EDC verified of 322,527, 1,712 all-zero user areas = the same 1,712 with an empty ECC field. Claire the same with 307,239 and 1,718 |
| frame cost | 322,527 × 304 = 98,048,208 and 307,239 × 304 = 93,400,656 — 12.9252 % on both |
| XA | no CD-XA001 at offset 1024 of either descriptor on either disc; 0 records of 2,230 carry the 14-byte XA System Use area; subheader 00 00 00 00 on 100 % of sectors — file 0, channel 0, submode 0 |
| descriptors | 3 on each: primary 16, supplementary (Joliet) 17, terminator 18 |
| volume ids | RES2_LEON / RES2 LEON; RES2_CLAIRE / RES2 CLAIRE |
| data preparer | CeQuadrat 32bit ISO-9660 Formatter Copyright (c) 1995 by CeQuadrat GmbH (primary), CeQuadrat Joliet Formatter … (Joliet) |
| empty fields | system id, publisher, application, copyright, abstract, bibliographic — all blank on both |
| volume timestamps | Leon created 1999-03-21 15:37:02.99, modified 15:39:16.57; Claire created 1999-03-21 14:35:11.95, modified 14:38:02.17. Expiration and effective not set (16 zero bytes) |
| volume space | Leon 322,225 sectors, image has 302 more; Claire 306,937, image has 302 more |
| path tables | 494 bytes at sectors 20/21 (primary), 696 at 22/23 (Joliet) |
| the trees | 35 directories plus root on each. Leon 2,194 files, 657,241,774 bytes; Claire 2,224 files, 625,887,450 bytes |
| namespaces | --compare says 2,230 entries per side, 0 extents present in only one, delta 0 bytes, 20 extents of 2,194 spelled differently, all in /DRIVERS, all for more than case |
| unclaimed | 304 sectors in 2 runs on each disc, both runs NON-ZERO. Sector 19 ×1 CeQuadrat Joliet directory link table; sector 322,224 ×303 CeQuadrat ISO 9660 formatter information block. 112 non-null bytes in the first, 56 in the second, 168 across both discs |
| slack | Leon 2,294,098 bytes, 100.0000 % zero, 0 dirty files of 2,194. Claire unmeasured |
| entropy | Leon cooked 7.5724 bits, 10,079 blocks of 64 KiB, mean 7.0874, median 7.8338, max 7.9973, 5,721 blocks (56.76 %) above 7.5, 3,850 above 7.9. Claire 7.5364, 9,602 blocks, mean 7.0448, max 7.9973, 5,286 (55.05 %) above 7.5 |
| the seven layers, Leon | PL0 778 / 317,290,974 (48.2761 %) · COMMON 1,005 / 251,181,574 (38.2175 %) · ZMOVIE 6 / 37,917,670 (5.7692 %) · REGIST 270 / 30,128,806 (4.5841 %) · GALLERY 114 / 13,402,494 (2.0392 %) · DRIVERS 17 / 5,194,391 (0.7903 %) · root 4 / 2,125,865 (0.3235 %) |
| the seven layers, Claire | PL1 809 / 290,639,408 (46.4364 %) · COMMON 1,005 / 251,181,574 (40.1321 %) · ZMOVIE 6 / 37,917,670 (6.0582 %) · REGIST 269 / 25,426,046 (4.0624 %) · GALLERY 114 / 13,402,494 (2.1414 %) · DRIVERS 17 / 5,194,391 (0.8299 %) · root 4 / 2,125,867 (0.3397 %) |
| the overlap | 1,696 shared hashes, 357,785,576 bytes = 54.4374 % of Leon and 57.1645 % of Claire. By directory: COMMON 956 / 248,797,580 · PL0↔PL1 341 / 27,740,750 · REGIST 260 / 23,608,870 · GALLERY 114 / 13,402,494 · ZMOVIE 6 / 37,917,670 · DRIVERS 17 / 5,194,391 · root 2 / 1,123,821 |
| extensions, both discs | 4,418 files, 1,283,129,224 bytes. .BIN 254 / 715,671,936 (55.7755 %) of which 32 are AVI · .SAP 1,495 / 326,895,178 (25.4764 %) · .RDT 500 / 65,162,536 · .EXE 29 / 38,850,490 · .BGM 232 / 30,783,344 · .DAT 242 / 26,850,660 · .DLL 154 / 14,923,136 · .TIM 177 / 12,183,608 · .EMD 116 / 11,407,828 · .DRV 114 / 7,010,488 · .DO2 110 / 6,949,584 · .PLD 40 / 5,676,852 · .PLW 181 / 4,856,968 · .ADT 224 / 3,801,736, plus .EDH .CPT .INF .HLP .INI .DIE .UC .TXT .ACV .CSP .TGA .ESP .TM2 .TS .COM .VXD .BMP .AVI .SBK .CPL .DDB .NEC .X86 .MPD .SYS .REG .CNT |
| the dates | Leon 1,446 distinct timestamps over 159 days; Claire 1,478 over 153. Span 1996-10-20 .. 1999-02-01, 835 days, on both. Zero records at 00:00:00. Even seconds on 2,194 of 2,194 and 2,224 of 2,224, 30 distinct second values = the thirty even ones. The 36 directory records are even 36 of 36 on both discs. Timezone byte GMT+00:00 on every record |
| densest days | Leon 1998-11-03 343 files / 111,100,426 (16.9040 %) · 1998-04-08 185 / 8,711,999 · 1998-11-04 172 / 6,905,436 · 1998-12-25 163 / 19,999,414. Claire 1998-11-05 228 / 13,956,070 · 1998-11-04 187 / 7,061,350 · 1998-04-08 185 / 8,711,999 · 1998-11-03 146 / 101,777,884 |
| the nine hours | REGIST/LEONP.EXE −32,406 s · REGIST/RES2_INST.EXE −32,401 · REGIST/DXINST.BIN −32,399 · REGIST/RES2_UNINST.EXE −32,399. 72 PE with usable COFF stamps on Leon, 13 within twelve hours of a plausible zone. Five Rendition DLLs give +32,400 |
| the film | 32 files, all named .BIN, in ZMOVIE and PLn/ZMOVIE. 555,978,176 bytes, 52,780 frames, 2,532.5312 s = 42.21 min. Codec IV50 (Indeo Video 5), 320×160 on all 32, 15.000 fps on 15 and 30.000 on 17, PCM tag 1 22,050 Hz 16-bit, stereo on 28 and mono on 4. Video chunks are 00iv, so avicheck.py reports 0 frames on 32 of 32. Six of Leon's sixteen (those in /ZMOVIE) are shared byte-for-byte, 37,917,670 bytes, so distinct film is 518,060,506. Plus SAMPLE.AVI in root, 1,120,860 bytes, 94 frames, 6.27 s, same codec and size |
| the speech | 731 .SAP on Leon / 162,714,010 bytes; 1,495 / 326,895,178 over both. Each begins with eight bytes then RIFF….WAVE. First dword takes 128 distinct values — 1 on 421 files, 7 on 54, 3 on 32; second dword usually zero. 431 of 731 close exactly (declared + 8 + 8 = file size); the other 300 hold more than one WAV. WEAPON01.SAP is 15,246 bytes and its first RIFF declares 3,158. First-WAV formats: tag 2 (Microsoft ADPCM) 1ch 22,050 Hz 4-bit on 614; tag 2 2ch on 100; tag 1 PCM 1ch 8-bit on 1. At least 7,267.847 s on Leon counting one WAV per file |
| the PlayStation blocks | psblocks.py on Leon: 129,790 raw ids, 1,455 validated (TIM 1,445, TMD 10), 39,331,783 bytes = 5.9844 % of file bytes; the raw grep would have counted 89.2× as many. Coverage: .DAT 121 files / 13,425,330 / 114 blocks / 99.83 % · .TIM 89 / 6,125,100 / 110 / 99.96 % · .RDT 250 / 32,748,932 / 1,039 / 45.82 % · .PLD 20 / 2,817,664 / 20 / 69.71 % · .DO2 55 / 3,474,792 / 55 / 52.73 % · .DIE 7 / 602,024 / 7 / 57.78 % · .PLW 91 / 2,445,220 / 91 / 8.69 % · .EMD 58 / 5,698,240 / 2 / 0.17 %. .EMD head is e4 25 02 00 08 00 00 00, 51 distinct heads over 58 files. timtmd.py --chain consumes 201 of 218 whole; 17 leave residue |
.ADT |
224 files over both discs, 3,801,736 bytes, entropy 7.79–7.95, names RC2000_.ADT style. pakdec.py fails on all 40 tried, with ValueError |
ROOMCUT.BIN |
COMMON/BIN/ROOMCUT.BIN, 71,948,686 bytes, ~11 % of Leon, opens with an ascending dword table — 14336, 92419, 199654, 297769, … — all inside the file; first entry at 0x3800 |
| the two game executables | RESIDENTEVIL2.EXE 1,001,984 bytes on each disc, 809,643 bytes differ (80.8040 %), 55,023 runs, first at offset 184, last at 1,001,982. Linker 5.10. No VS_VERSIONINFO. Other own binaries: REGIST/LEONP.EXE 1,359,872 · RES2_INST.EXE 156,672 · RES2_UNINST.EXE 180,224. Game COFF stamp 1999-02-16 01:43:15, volume 1999-03-21 — 33 days. 3 of the 13 stamped PE carry an Authenticode certificate table (0 of 11 yesterday) |
README.TXT |
Minimum Win95/98, Pentium 166, 4X CD ROM, 24 MB RAM, 2 MB DirectX 6 card, 1 MB free disk for game data plus 100 MB swap. Recommended Pentium 200, 8X, 32 MB, 4 MB 3D accelerator, 450 MB plus 100 MB swap. "This game can be played without installation but loading between rooms may cause a slight delay". Three prerequisites: DirectX 6, DirectXMedia 6, Indeo Video 5.06. Fourteen chipsets named, drivers shipped for three (Matrox Mystique, ATI Rage Pro, Rendition V1000) = 17 files / 5,194,391 bytes. Copyright line CAPCOM CO.,LTD. 1998,1999 ALL RIGHTS RESERVED. |
| absolute paths | buildpaths.py on Leon in primary: 252 hits (153 DOS, 99 Mac), 155 distinct, in 67 files. Most frequent e:\cmay\joystick\cht\help\dijoy_cs.rtf ×47 in a Microsoft help file; c:\dev\ddk\inc\VMM.Inca and d:\proj\dev\ddk\inc\vmm.inc identical to yesterday's, in the same DirectX VXDs; ~20 c:\PCINST6\w82440en\Temp\… inside the ATI self-extractor; c:\Program Files\CAPCOM ×2 in RES2_INST.EXE; j:\7I555[tt\tt4mzUi0. in two .TIM; the 99 "Mac" are zero paths |
| personal data | no identifier of this machine on either disc. contacts.py puts 1 string in the "person" bucket per disc and both are noise — domain KUO.JGGG inside GALLERY/ROUGH58.DAT, which is a TIM. The only real address is CPS-requests@verisign.com, 3 occurrences on Leon and 2 on Claire, inside Microsoft installers. 45 raw strings looked at on Leon, 43 on Claire |
| URLs | Leon holds 6 distinct in 16 occurrences, one of which — http://www.virgin.com — is inside the game executable |
| the crossing with yesterday | Resident Evil 1 ↔ each disc: 12 distinct files, 352,267 bytes, all under REGIST/DIRECTX/DRIVERS/ENG/ plus REGIST/DIRECTX/LICENSE.TXT. Eleven Microsoft drivers and one Microsoft licence. Ten of the twelve are the same ten that crossed with Final Fantasy VIII yesterday |
Inherited questions the briefing names as touchable: the collection's Q1 (the
volume descriptor, eighteenth answer, and the first where the writer itself
wrote into space its own descriptor does not describe), CLIC 11's Q1 (the
trailing sectors — fourth and fifth sample, both 302, the value CLIC 02/97
got from a different program), CLIC 02/97's Q5 (dirty slack, fourth sample),
yesterday's question about the nine hours, yesterday's question about
RESIDENTEVIL.EXE being the one binary that did not sit at nine hours, and
yesterday's twenty-eight sheared backgrounds (method transferable, question not).
They are not restated as clauses; the clauses bet on the answers.
B1 — "what does this disc pay to be Mode 2" has an arithmetic answer and it is
zero, and that is the finding. Mode 1 lays a sector out as 12 sync, 4 header,
2,048 user, 4 EDC, 8 bytes of specified zero, 276 ECC. Mode 2 Form 1 lays it
out as 12 sync, 4 header, 8 bytes of subheader, 2,048 user, 4 EDC, 276 ECC.
The two forms spend the same 304 non-payload bytes; they disagree only about
what the eight bytes between the header and the payload mean, and about where
the user area starts — offset 16 in Mode 1, offset 24 in Mode 2 Form 1. If §A is
right that the subheader is 00 00 00 00 00 00 00 00 on every sector of both
discs, then this disc writes, into the eight bytes Mode 2 reserves for meaning,
exactly the eight bytes Mode 1 reserves for nothing. The byte cost of the
choice is zero and the information gained is zero. What it does cost is
correctness: submode 0 does not have the data bit set, so by the letter of
CD-ROM XA every sector on these discs declares itself to be neither data nor
audio nor video nor an end of record. That is the sentence worth writing, and
C07–C09 bet on it.
B2 — the even-seconds proof of yesterday is dead here, but §A already contains
its replacement and the briefing did not notice. Yesterday's demonstration was
a contrast: file records even 2,638 of 2,638 (FAT, two-second units), directory
records even 25 of 47 (chance, because the mastering program wrote them). Here
the directories are even 36 of 36 and the contrast is gone. But §A also gives
four volume-descriptor timestamps at hundredth-of-a-second precision, and one of
them — Claire's creation, 14:35:11.95 — has an odd seconds field.
CeQuadrat's own clock therefore emits odd seconds. So if all 36 directory
records on both discs are even, they were not taken from CeQuadrat's clock at
burn time; they were inherited from the source volume like the files were. The
test that distinguishes the two hypotheses is not the parity of the directory
seconds — it is whether the directory dates are the burn day or older. If they
are older than 1999-03-21, they are inherited and the FAT argument survives
intact, with a new proof. C22–C24 bet on this.
B3 — the .SAP first dword is a count of WAVs, and §A contains the evidence
without drawing it. 431 of 731 files close exactly with one embedded RIFF; 421
files carry 1 in the first dword. Those two numbers are ten apart, which is the
signature of a count that is right and a closure test that is slightly stricter
than the count — ten files declaring one WAV but carrying trailing pad. Values
7 on 54 files and 3 on 32 fit a bank of sounds; 128 distinct values fits a
maximum of 128 entries. And no offset table is needed, because concatenated RIFF
chunks are self-delimiting: each declares its own size, so a reader that knows
the count can walk them. The prediction is therefore precise and falsifiable:
8 + Σᵢ(8 + sizeᵢ) = file size, with the number of terms equal to the first
dword, on all 1,495 files. C40–C43.
B4 — the film needs 1.43× and the box says 4×, and yesterday it needed 1.33× and the box said 2×. 555,978,176 ÷ 2,532.5312 = about 219,530 bytes per second. A single-speed drive delivers 75 × 2,048 = 153,600 bytes of Mode 1 or Mode 2 Form 1 payload per second. The ratio is about 1.429. So between 1997 and 1999 the same publisher's movie bitrate rose by seven percent and its stated minimum drive speed doubled, and its stated recommended speed quadrupled. The headroom went from about 1.5× to about 2.8×. That is not a fact about video; it is a fact about what a 1999 buyer was assumed to own, and it is measurable on both sides for the first time because this readme states a number and yesterday's did not. C36–C38.
B5 — .BIN is not one thing and the count of things is three or four, not
two. §A says 254 .BIN files and 715,671,936 bytes; 32 of them are AVI at
555,978,176 bytes, which leaves 222 files and 159,693,760 bytes in the
remainder. Of that remainder one file — ROOMCUT.BIN — is 71,948,686, which is
45 % of it, and it is an archive with a dword index in the head. DXINST.BIN is
a PE with a COFF stamp, so it is a third genus: an executable wearing .BIN.
And the briefing's "hundred documents of COMMON/FILE" is a fourth. So the
honest statement is that the largest extension on the object names at least four
unrelated formats and the classifier must be by signature, not by name. C44–C47.
B6 — the twelve crossing files are the wrong measurement and the right one is
sitting next to them. If Resident Evil 1 and Resident Evil 2 share 352,267
bytes and ten of the twelve files are the same ten that Resident Evil 1 shares
with Final Fantasy VIII, then byte-identity between two discs measures the
runtime environment a 1990s Windows game had to carry, and nothing else. It is
a real measurement of a real thing; it is simply not a measurement of kinship.
Kinship on this pair is visible in other places and every one of them is
countable with a tool already in the box: the same PlayStation TIM identifier,
the same .RDT extension for a room and .EMD for a character and .ESP for an
effect, the same RC####_ naming scheme for a background, the same absence of a
version resource on the studio's own binaries, and the same nine-hour offset
between a Japanese linker and a European mastering clock. C62–C65 bet on the
resolution.
B7 — 302 is not 150 and both are opinions, but two programs agreeing is a datum. Yesterday's disc, written by GEAR, had exactly 150 sectors past volume space, which is a lead-out's worth. CLIC 02/97, written by Toast, had 302. These two, written by CeQuadrat, have 302 and 302. Two vendors on two platforms four years apart producing the same number is either a coincidence at 1-in-many or a shared constant. 302 = 150 + 150 + 2 is the reading I would bet on: two run-out/link areas plus the two sectors a writer needs to close a track. The question yesterday declared unclosable becomes, today, closable in one direction only — I can say the value is not random, and I cannot say what it is for without a specification neither disc contains. C15–C17.
B8 — the sum of two discs is not a denominator, it is four denominators, and
the thesis number moves depending which is used. Leon 657,241,774; Claire
625,887,450; the sum 1,283,129,224; the sum less the 357,785,576 duplicated =
925,343,648; and the two raw images 1,481,209,632. Film plus speech is
882,873,354 on the naive sum for 68.8072 %, which is close enough to yesterday's
68.5388 % to be suspicious. On the deduplicated denominator the numerator also
deduplicates — 518,060,506 of film plus whatever .SAP survives deduplication —
and the two shrink at different rates, because ZMOVIE is shared entirely while
PLn is not. The number that goes in the collection's thesis table must be the
deduplicated one, because the duplicated one counts 357 MB of the object twice
and therefore reports a property of the packaging, not of the work. C66–C68.
| # | kind | clause |
|---|---|---|
| C01 | method | rawcensus.py, written for Mode 2 Form 1 and set aside yesterday, runs unmodified on both discs and validates its 64-sector self-check 64 of 64 on the first attempt. mode1.py, written yesterday, is inapplicable and is not adapted. Both facts go in the tools chapter and neither takes more than a paragraph. |
| C02 | method | Censused whole, not sampled: 322,527 + 307,239 = 629,766 sectors, each checked for sync, MSF = LBA + 150, mode byte, form, subheader self-agreement and EDC. Zero mismatches of any kind on either disc, exactly as §A says, and the EDC figure re-derives to 322,527 of 322,527 and 307,239 of 307,239. |
| C03 | content | Mode byte 2 on 100 % of both discs and Form 2 on zero sectors of either — i.e. there is not one 2,324-byte sector anywhere in 1.48 GB. |
| C04 | content | The all-zero-user-area count and the empty-ECC count coincide exactly, 1,712 on Leon and 1,718 on Claire, and those sectors are not distributed at random: more than 80 % of them fall either before sector 16 or inside the 303-sector tail run, i.e. they are the pre-descriptor pad and the post-volume pad, not holes in the data. |
| C05 | content | Frame cost re-derives to 98,048,208 and 93,400,656 bytes, 12.9252 % on both, and I do not re-prove that 304 ÷ 2,352 is a constant — it was proved yesterday and is cited. The ratio that is re-derived because its denominators are new is parity against file bytes: 276 × 322,527 ÷ 657,241,774 and 276 × 307,239 ÷ 625,887,450, and the two land within 0.7 percentage points of each other and above 13.4 %. |
| C06 | content | Payload capacity minus files leaves a real remainder on each disc, and it decomposes into exactly four terms — directory extents, path tables, the 304 unclaimed sectors, and per-file slack — which sum to the difference with residue 0 bytes on both discs. |
| C07 | content | xa.py finds no CD-XA001 on either descriptor of either disc and 0 records of 2,230 with a 14-byte System Use area, and the subheader is 00 00 00 00 00 00 00 00 on 629,766 of 629,766 sectors — not merely on a sample. |
| C08 | content | The submode byte is 0x00 everywhere, which means the data bit (0x08) is clear on every sector of both discs, and by the letter of CD-ROM XA that makes every sector on this object a sector of unspecified kind. I will state this as a defect of declaration, not of data: the EDC still verifies, so nothing is unreadable. |
| C09 | content | The answer to "is this a Mode 2 disc or a Mode 1 disc in a Mode 2 wrapper" is the second, and the argument is B1's: the object spends 2,580,216 bytes on Leon and 2,457,912 on Claire — 5,038,128 across both — writing the same eight zero bytes Mode 1 would have reserved anyway. Byte cost of the choice: zero. The only real consequence is that the user area begins at offset 24 rather than 16, and that is what killed recdates.py. |
| # | kind | clause |
|---|---|---|
| C10 | content | Three descriptors on each disc, and the supplementary one at sector 17 carries escape sequence %/E (UCS-2 level 3) — not %/@ or %/C — on both discs. |
| C11 | content | The 20 divergent names re-derive to 20 on Leon, and Claire has its own count which is also 20 and for the same files, because /DRIVERS is byte-identical between the discs. So the Joliet namespace differs from the primary one on 0.91 % of Leon's names and on a set that contains no Capcom file at all: every long name on this object belongs to a third party. |
| C12 | method | The cost of the second namespace is measured in sectors and is not zero: Joliet path table 696 bytes against the primary's 494, plus a full second set of directory extents. The total comes to more than 40 and fewer than 120 sectors per disc, i.e. under 250 KB, and I publish the figure with the command. |
| C13 | content | Every extent number is identical between the two namespaces on all 2,194 and 2,224 entries — that is, Joliet on this disc is a second set of names over one set of data, and there is not a single file that exists in one namespace only. The --compare delta of 0 bytes re-derives. |
| C14 | content | The 112 non-null bytes at sector 19 read as 28 little-endian dwords, and more than 20 of them are extent numbers that appear in the directory tree — specifically, they are the extents of the directory records themselves, so the "Joliet directory link table" is a map from primary directory extents to Joliet ones. I will say how many of the 28 I could account for and how many I could not. |
| C15 | content | The 303-sector run begins exactly at the last sector of the volume space, so the sectors strictly past the volume space number 302 on both discs, and the string plus two dwords occupy the first sector of the run while 302 sectors are zero. |
| C16 | content | The two dwords after CeQuadrat ISO 9660 formatter information block are not arbitrary: at least one of them equals a quantity already known from the descriptor — the volume space size, the sector count, or the number of directory records — and I will identify which, or say I could not. |
| C17 | content | CLIC 11's Q1 gets its fourth and fifth samples and stays open, but less open: yesterday's ruling was that the trailing count is an opinion of a program, and two programs from different vendors and different decades agreeing on 302 is evidence against pure arbitrariness. I will publish the four-sample table (150 GEAR, 302 Toast, 302 CeQuadrat, 302 CeQuadrat) and decline to name the mechanism. |
| C18 | content | The collection's Q1 gets its eighteenth answer and this is the first disc where the answer is worse than incomplete: the primary descriptor declares 322,225 sectors and CeQuadrat itself wrote a signed block at sector 322,224 and 322,225 onwards. A descriptor that omits data its own author wrote is not merely silent about the tail — it is silent about itself. |
| # | kind | clause |
|---|---|---|
| C19 | content | The date span re-derives to 1996-10-20 .. 1999-02-01 on both discs, 835 days, and the earliest file is the same file on both — a third-party driver or runtime, not a Capcom file. |
| C20 | content | Zero records at 00:00:00 on both discs re-derives, and it is a difference from yesterday worth one sentence and no more: yesterday's 767 midnight records were a single day's bulk copy, and this object has no such day. |
| C21 | content | Even seconds on 2,194 of 2,194 and 2,224 of 2,224 re-derives, with exactly 30 distinct values, all even, and no record anywhere on either disc carries an odd second — files or directories. |
| C22 | content | §B2's test resolves it. At least one of the four volume-descriptor timestamps carries an odd seconds field (Claire's creation, …11.95), which proves CeQuadrat's clock is not restricted to even seconds. Therefore the 36 all-even directory records are inherited, not written. |
| C23 | content | Confirming the same thing from the other side: the 36 directory records on each disc are not dated 1999-03-21. Their dates fall inside the file range, and at least 30 of the 36 are older than the newest file in their own directory — i.e. they are the source directories' FAT timestamps carried across, exactly as the files' are. |
| C24 | content | The four Capcom binaries at −32,4xx seconds re-derive to within a second of §A's figures, and widening the sample to all 72 stamped PE on Leon leaves the same shape: a small Capcom cluster near −32,400, a large third-party population scattered across months, and the five Rendition DLLs at +32,400. The Capcom cluster contains between 4 and 8 members and RESIDENTEVIL2.EXE is not one of them. |
| C25 | content | RESIDENTEVIL2.EXE is 33 days older than its own volume and roughly 24 days older than the other Capcom binaries, and this is the second consecutive object in which the main executable is the one binary that does not sit where the others do. Two samples is not a pattern and I will say so, but I will publish both side by side. |
| C26 | content | The +32,400 s Rendition group is the same phenomenon as yesterday's +32,400 s NEC group and has the same cause, which is not a Japanese build clock: it is a file whose ISO record was written before its own COFF stamp in local terms, i.e. the mastering machine's zone applied in the opposite direction. I will either demonstrate this or leave the question open for the third session running. |
| # | kind | clause |
|---|---|---|
| C27 | method | A disc comparator written for this session reports, per directory, four counts: identical by hash, same name with different bytes, present only on Leon, present only on Claire. Summed over all directories the identical count re-derives to 1,696 and 357,785,576 bytes, and the four counts partition both trees with residue 0 files. |
| C28 | content | The 49 COMMON files that share a name and differ in bytes are not scattered: more than 35 of them live in two or three subdirectories, and their aggregate size is under 3 MB — i.e. the divergence inside COMMON is small tables, not content. COMMON is 1,005 files and 251,181,574 bytes on both discs, so the 49 differ without changing the total by one byte, which means they are same-size records with different values. |
| C29 | content | The five denominators re-derive as: Leon 657,241,774 · Claire 625,887,450 · sum 1,283,129,224 · sum less duplicates 925,343,648 · raw images 1,481,209,632. The overlap is 54.4374 % of Leon, 57.1645 % of Claire, and 27.8837 % of the naive sum, and every table in this repository names which of the five it uses. |
| C30 | content | PL0 and PL1 share 341 files and 27,740,750 bytes, which is 8.7431 % of PL0 — so the scenario directories, the thing that actually differs between the two discs, are more than 91 % distinct. The duplication is almost entirely in COMMON, ZMOVIE, GALLERY and DRIVERS, and those four are 100 % duplicated. |
| C31 | content | The verdict on whether 357,785,576 duplicated bytes are waste: they are not, and the argument is a disc-change count. The shared set includes all 6 root movies and all of COMMON, which is the engine and the common rooms; if it were on one disc only, a two-disc game would require swapping mid-scenario. I will put a number on it — the count of COMMON files a single scenario actually references — or declare that the reference graph was not derivable and argue from the directory names alone. |
| # | kind | clause |
|---|---|---|
| C32 | method | avicheck.py is extended to count every chunk in movi and classify by fourcc rather than to look for 00dc/00db. On these 32 files it finds 00iv and 01wb and reports 52,780 video chunks, matching dwTotalFrames on 32 of 32. The extension is declared in the tools chapter, and the old tool's silent DISAGREE is written down as the failure mode it is. |
| C33 | content | All 32 are IV50, 320×160, on both discs, and the 15/30 fps split is 15 files at 15.000 and 17 at 30.000 — but the split is not random across directories: the shared /ZMOVIE six and the scenario PLn/ZMOVIE ten fall into different rate groups, or the rate correlates with the audio channel count. I will publish the cross-tabulation. |
| C34 | content | 320×160 is not a video mode, it is 320×240 with the top and bottom cropped to a 2:1 letterbox, and this is a deliberate saving: 160 lines against 240 is exactly one third fewer pixels. Yesterday's film was 320×240 full frame. I will compute what the 42 minutes would have cost at 240 lines and publish the difference. |
| C35 | content | Total duration re-derives per file and summed to 2,532.5312 s ± 0.01, and it is not a round number; the "42.21 minutes" is that figure divided by 60 and nothing more. Six of Leon's sixteen are byte-identical to six of Claire's, so distinct film is 518,060,506 bytes and distinct duration is less than 2,532.5312 s — I publish both, with the shared duration subtracted once. |
| C36 | content | Mean film bitrate is between 215,000 and 224,000 bytes per second, i.e. between 1.40× and 1.46× the 153,600 B/s of a single-speed drive, and the worst single file stays under 2.0×. |
| C37 | content | Therefore the readme's 4X minimum is not a video constraint. The gap between the requirement and the demand is more than 2.5×, and yesterday's disc — 1.33× demanded, 2× stated — had a gap of about 1.5×. I will publish the two-row table and argue that what doubled between 1997 and 1999 was the assumed machine, not the film. |
| C38 | content | SAMPLE.AVI in the root is byte-identical between the two discs (it is one of the 2 shared root files), and it is a sample of this disc's own content — its 94 frames come from one of the 32 movies, and I will test that claim by comparing the two files' frame sizes rather than by decoding. |
| C39 | content | Indeo 5 is not decoded and the chapter says so in its own words: the frames are counted from the container, the durations from the headers, and the pixels are never touched. The number of decoded video frames written to _work/ is zero, and the number committed is zero. |
| # | kind | clause |
|---|---|---|
| C40 | content | §B3's hypothesis holds: the first dword of the 8-byte .SAP header is the count of embedded RIFF/WAVE streams, and 8 + Σ(8 + declared size) equals the file size on more than 1,450 of the 1,495 files across both discs. Where it fails it fails by trailing pad, not by a wrong count. |
| C41 | content | The second dword is zero on more than 1,400 of 1,495 and where it is non-zero it is small — under 65,536 — so it is a flag or a bank id, not a size. I will report the distribution and not over-read it. |
| C42 | method | A Microsoft ADPCM decoder written against the public IMA/MS-ADPCM definition, validated on one file whose PCM length is independently derivable, then run over the population, closes the declared duration against the decoded sample count with a maximum discrepancy of 0.000000000 s on every file that is not truncated — the Lands of Lore standard, met for the fourth time. |
| C43 | content | The true total speech duration, counting every WAV in every container and not one per file, exceeds 9,000 seconds across both discs and exceeds 10,000 counting duplicates; deduplicated it lands between 7,000 and 11,000 s. Against yesterday's 5,027.658866213 s of uncompressed PCM, this object carries roughly twice the recorded speech in fewer bytes per second, and the ratio of the two — 4-bit ADPCM against 16-bit PCM — is exactly 4:1 per sample, which I will demonstrate rather than assert. |
| # | kind | clause |
|---|---|---|
| C44 | method | A signature classifier over all 254 .BIN files partitions them into at least four genera: RIFF/AVI (32), an indexed archive with a leading dword table (ROOMCUT.BIN and at least one other), a PE executable (DXINST.BIN), and a residue of small documents. No genus is assigned by extension and the partition covers 254 of 254. |
| C45 | content | ROOMCUT.BIN's leading table is 0x3800 = 14,336 bytes = 3,584 dword slots, of which the used prefix is far fewer — under 1,200 — and the tail is padding. The entries are strictly ascending file offsets, the last plus its length equals 71,948,686 with residue 0, and the payload at each offset is not a raw TIM: it begins with the same signature as the .ADT files, i.e. ROOMCUT.BIN is a container of compressed backgrounds and .ADT is a single compressed background. |
| C46 | content | .ADT is entropy-coded and not LZ77, like yesterday's .PAK, and it is not the same algorithm: the first bits do not decode to a TIM identifier under yesterday's reader, which is why pakdec.py raises. I will apply yesterday's five-indicator method — entropy, absence of 4-byte repeats, non-aligned sizes, tail periodicity, first nine bits — and publish all five readings whether or not they close. |
| C47 | content | I will get .ADT open. At least 200 of the 224 files decompress to a payload that begins with a PlayStation TIM identifier 10 00 00 00, with residue 0 on the decompressed length. If I do not get it open, the chapter says exactly which of the five indicators pointed where and what the failed decoder did, in the manner of yesterday's .PIX. |
| C48 | content | psblocks.py re-derives 1,455 validated blocks on Leon — 1,445 TIM and 10 TMD — and the TMD collapse from yesterday's 828 to 10 is real and not a tool artefact, verified by pointing the same tool at yesterday's tree and getting yesterday's number back in the same run. |
| C49 | content | .DAT, .DIE and .TS are TIM under other names, at 99.83 %, 57.78 % and near-total coverage, and together with .TIM they account for more than 19 MB of paletted PlayStation texture on Leon alone. The GALLERY directory's 114 files are among them: GALLERY is 114 TIM illustrations and its ROUGH58.DAT is the file contacts.py false-positived on. |
| C50 | content | .RDT at 45.82 % TIM coverage means the room record is a container whose other half is not pictures, and it opens with a table of 32-bit offsets into itself, monotonically non-decreasing and all less than the file size, on more than 450 of the 500. This is the same shape as yesterday's .RDT and a different header, and I will publish the two headers side by side. |
| # | kind | clause |
|---|---|---|
| C51 | content | The TMD count of 10 is not the model count: the models are in .EMD, .PLD and .PLW, and .EMD's new head e4 25 02 00 08 00 00 00 is not a magic number — the first dword, 0x000225e4 = 141,284, is a length or an offset, and 51 distinct heads over 58 files is exactly what a length field looks like. I will identify which of the two it is by testing it against the file sizes. |
| C52 | content | Inside .EMD there is a geometry format that is not TMD — the bytes 41 00 00 00 do not appear at a validating offset in more than 5 of the 58 — and it is Capcom's own, introduced between 1996 and 1998. Its structure is derivable at least as far as a vertex table with a count, and I will derive that much or declare the rest underived. |
| C53 | content | Counting all six PlayStation-native families — TIM in five extensions, the .EMD/.PLD/.PLW model family, .DO2 doors, .RDT rooms, .ESP effects and .BGM sequences — the object carries more than 90,000,000 bytes across both discs in formats no Win32 API of 1999 could read, and the line yesterday found holds again: every recording of the world is in a PC container and every description of it is in the PlayStation's. Zero bytes of AVI or WAVE sit in a PlayStation container. |
| # | kind | clause |
|---|---|---|
| C54 | content | The seven layers re-derive to §A's figures with residue 0 on both discs, and the third-party fraction — REGIST plus DRIVERS — is 5.3744 % of Leon's file bytes and 4.8923 % of Claire's, against yesterday's 3.6814 %. The price of the PC went up, not down, between 1997 and 1999, on this measure. |
| C55 | content | Yesterday's coinage survives the three-case test: DirectX 6 and DirectXMedia 6 are prerequisites and the 17 driver files are a leftover, on the same reading in opposite directions. Indeo Video 5.06 is the new case and it resolves as a prerequisite, on the ground that 555,978,176 bytes of the object are unreadable without it — a decoder the object's own data requires is not a leftover, it is part of the object shipped in separable form. |
| C56 | content | The readme does not call the drivers development versions, unlike yesterday's, so yesterday's written justification does not transfer, and the ruling has to be re-made on the numbers: 3 chipsets shipped of 14 named, and the readme's own sentence "check with your card manufacturer" is the evidence that the disc is not trying to be complete. Leftover, with a different argument. |
| C57 | content | Total leftovers land between 6,000,000 and 14,000,000 bytes, i.e. between 0.6 % and 1.3 % of the deduplicated denominator — lower than yesterday's 1.8169 % and lower than Il Mio Computer's 1.2117 %, and this despite the third-party fraction being higher, because most of REGIST is ruled prerequisite. The 357,785,576 duplicated bytes are argued at length and are not counted in the total; they get their own line. |
| # | kind | clause |
|---|---|---|
| C58 | method | buildpaths.py runs intact on the Joliet-extracted tree — not the primary one — and prints 252 hits, 155 distinct, in 67 files on Leon, matching §A. I state which tree it was run on in the same line as the number, because on this object that matters and did not yesterday. |
| C59 | content | The number that goes in the collection's absolute-path table is 2, not 252: the two c:\Program Files\CAPCOM occurrences in RES2_INST.EXE, which are a default and not a build machine. The count of paths belonging to a Capcom or Virgin build machine is zero across 1.48 GB, against yesterday's one in 736 MB, and I will have looked in all four own binaries and in the debug directories before saying it. |
| C60 | content | The 3 Authenticode-signed PE are Microsoft's and Intel's — the DirectX and Indeo installers — and not Capcom's. At least one certificate chain terminates at a VeriSign root, which is where CPS-requests@verisign.com comes from, and the subject common names are corporate, not personal. |
| C61 | content | P.2 re-derives as clean: KUO.JGGG inside GALLERY/ROUGH58.DAT is at an offset that falls inside a TIM pixel block, which I demonstrate by locating it against the block boundaries psblocks.py already computes. A pattern different from contacts.py's, run over the 555,978,176 bytes of Indeo — where yesterday's address was hiding — finds zero personal addresses. leakcheck.py is run and its refusal to say CLEAN with no address to track is reported as correct behaviour for a tool and the wrong output for this object, and I say which. |
| # | kind | clause |
|---|---|---|
| C62 | method | The twelve-file crossing with pc-residentevil-doc re-derives exactly — 12 distinct files, 352,267 bytes, identical set on both discs — and is confirmed by byte comparison and not by hash alone on at least the largest of the twelve. The ten-of-twelve overlap with Final Fantasy VIII re-derives from ..\pc-finalfantasy8-doc\notes\, taken from the file and not from memory. |
| C63 | content | Run against every hash list in the collection, the crossing count for these discs exceeds 12 — there will be further matches beyond Resident Evil 1 — and every one of them is a third-party runtime, driver or licence file. Zero are game data. The crossing measurement, in this branch, measures Microsoft. |
| C64 | content | The Saga cell is filled, for both this row and Resident Evil 1's, and the rule is restated rather than stretched: a Saga cell names the series a title belongs to and is filled once a second member of that series has been measured. The byte-identity criterion is kept for what it is good at — the crossings column — and is retired from this column, because on the only pair the collection has it would have measured twelve Microsoft drivers and called it kinship. The reasoning is written in the index and in this repository, not silently applied. |
| C65 | content | Backing the decision with a measurement rather than a naming convention: the two objects share five countable structural traits — the TIM identifier byte-for-byte, the .RDT / .EMD / .ESP extensions, the RC####_ background naming scheme, the absence of a version resource on every studio binary across both, and the nine-hour Tokyo offset — and Final Fantasy VIII, which shares ten of the same twelve Microsoft files, shares at most one of the five. That asymmetry is the measurement the byte count could not make. |
| # | kind | clause |
|---|---|---|
| C66 | content | The thesis figure is published on all five denominators and the headline is the deduplicated one: film plus speech over 925,343,648 bytes. It lands between 66 % and 73 %, i.e. it does not escape yesterday's neighbourhood, and the coincidence with yesterday's 68.5388 % survives at least one of the five denominators to within half a point. |
| C67 | content | Film and speech are published as two columns and not one, continuing yesterday's split, and here the split matters more because the two are compressed at different ratios: 42 minutes of film in 555,978,176 bytes against more than 120 minutes of speech in 326,895,178. Per second of runtime, this object spends about ten times more on a second of film than on a second of speech. |
| C68 | content | Answering "is the 1999 PC bill made of the same items as the 1997 one": no, and the shape of the change is that the runtime half grew and the driver half shrank. DirectX and friends go from 2.5632 % to more than 4 % of file bytes; card drivers go from 1.1182 % to 0.7903 % while the number of supported chipsets goes from 6 to 14. I publish both bills side by side with the same layer names. |
| C69 | method | ..\tidying\pc-gamelist-doc is updated on branch main with the counts re-derived by the three commands and not incremented, and they come out 45 titles / 46 rows / 45 write-ups. Two rows are touched, not one: this object's new row and Resident Evil 1's Saga cell. The What it is cell is at most two lines; the elaboration goes in the write-up. The Year cell says 1999 and names which of the six dates it is and why. |
| C70 | method | This repository ships 20 documents, docs/00 through docs/19 — the seventh exact twenty in a row, on an object that is double and therefore tempting to split. git ls-files filtered by the branch's regex is empty; git check-ignore passes in both directions on _work/leon.iso and on README.md; no decoded asset, no film frame and no GALLERY illustration is committed; the GitHub repository is created with topics as well as a description under 350 characters. And the scoring comes out 41 hit, 17 half, 12 miss of 70, for 49.5 of 70 = 70.7 %. I predict between 5 and 11 errors in this briefing, with 8 the single most likely value. |
Seventy clauses. Counted, not eyeballed:
grep -c "^| C[0-9][0-9] |" docs/00-predictions.md