The Four Channel Layers of a Virtual-Texture Page — Block 0 and Block 1

Background: docs/virtualtextures.md cracked the container; tools/vtdecode.py decoded the single-channel layers — Block 2 as 8×8 macroblocks (128×128 px) across 599/599 pages of c12p1, and Block 3 as 2×2 macroblocks (32×32 px) across 299/299. Block 0 (INTERNAL_CLR_FMT = YUV_444, 3 channels) and Block 1 (NCOMPONENT, 2 channels) remained undecoded, with the note: "no macroblock raster retrieves either on any side."

This document corrects that note partially and leaves the other half standing.

Tool: tools/vtplanes.py (read-only, standard library only; for cross-checks it invokes the Windows-native JPEG-XR codec via powershell).

python tools/vtplanes.py census   c12p1.pages
python tools/vtplanes.py fit      c12p1.pages --max 1200
python tools/vtplanes.py reinterp c12p1.pages
python tools/vtplanes.py refgen   --out REFDIR      # Windows writes reference streams
python tools/vtplanes.py refcheck REFDIR            # including negative control
python tools/vtplanes.py seam     c01p4.pages --out SEAMDIR
python tools/vtplanes.py selftest             # each assertion as Pass/Fail count
python tools/vtplanes.py selftest --sabotage  # must yield FAIL (return value 1)

Addendum, §9: Block 1 now yields pixels, and the seam is measured for Channel 0. The tool for this is tools/vtpixel.py. What §8 suggested as "the next sensible step" — building jxrlib itself — was unnecessary: a pre-translated JxrDecApp.exe already exists on this machine.

Addendum, §10 and §11: Block 0 now yields — 823 of 4256 layers instead of 1, bit-exact, over the same corpus. The cause was a single bit state in the Chroma CBP prediction, and it has an inconvenient flip side: the corrected rule breaks 92 of the 108 YUV_444 reference streams that Windows wrote. The two encoders are incompatible with macroblock 0 — and thus jxrlib is for Block 0 not an oracle (§10.6). Block 1, Channel 1 remains open; §11 states what else died in the process.

1. The Result in One Paragraph

Block 1 carries 64 macroblocks — the area of exactly one 128×128 page — as NCOMPONENT with 2 channels, precisely what its own layer header states. Over six .pages files, 765 of 4256 Block-1 layers on Mip 0 pass completely through all 64 macroblocks and terminate in the own last byte, bit-exact. Every other macroblock count and every other color format read remains buried in noise. Which pages emerge is not random: they are the sparsely populated ones. As soon as a page truly carries content, the decoder eventually goes off track.

The form 8×8 is thus not filled, only the area — see §3.2. This is where one most easily deceives oneself, which is why it appears early in this document and not in fine print. It is also not filled with pixels in hand, and §9.5 states with numbers why not.

Block 1 now yields pixels, and Channel 0 seams seamlessly to its neighbor pages (§9). Channel 1 does not, although it produces an equally smooth image. Thus the remaining open part is confined to the second channel.

Block 0 is not solved. Over the same 4256 pages it yields 1× — that is exactly the noise limit. No raster, no color format, no bit depth, no tiling, and no alpha read changes anything.

Status after §10: This paragraph is obsolete, in a way that does not refute it: no read of the stream changes anything because the error was not a read but a state within the decoder. With the corrected Chroma CBP prediction, Block 0 yields 823× of 4256 (19.3%, §10.3), in the same order of magnitude as Block 1 and for the same reason. It remains open on pixels, and §10.6 states with numbers why this time it is not at the head.

The macroblock counter in vtdecode.py is not the suspect. It has been verified across 324 of 324 streams written by Windows' own JPEG-XR encoder — including YUV_444 with 3 channels and CMYK with 4 channels, precisely the N-channel code path used by NCOMPONENT. All 324 match exactly.

2. What is actually in the blocks (confirmed)

vtplanes.py census c12p1.pages --max 400, 399 pages, all four blocks:

Exactly one header variant per block across all 399 pages. The IMAGE_PLANE_HEADER resides within the block; only the preceding 16 bytes must be invented (WMPHOTO\0 + IMAGE_HEADER).

This table is not an area of interpretation, but a calculation: the bit sequence of the plane header is unambiguous, and it ends in all four cases byte-for-byte immediately before ff 00 00 01 00 (VLW_ESC-Escape, Start code, Tile type 0). These 40 bits are the test. If the header is read differently — different bit depth, different chroma centering, per-tile instead of uniform quantization — the end shifts and the test fails.

3. Block 1 = 64 macroblocks, 2 channels (confirmed) — form subject to caveat

vtplanes.py fit/selftest, Mip 0, first 1200 datasets per file:

"Exactly" here means strictly: the run is conducted strictly (reading past the block end throws an error, rather than padding with zeros), it must successfully traverse all 64 macroblocks, and it must stop at the last byte of the block — remainder slip 0 to 7 bits. With a typical payload of 1000 to 30000 bits, the random hit rate per raster attempt is under 1 %.

3.1 Cross-check: competing macroblock counts

selftest runs alongside 8×8 plus twelve additional grids (4×4, 16×16, 8×4, 4×8, 6×6, 9×9, 8×7, 7×8, 2×2, 10×10, 7×9, 9×7) over a uniformly distributed sample of the same pages. The result is unambiguous:

Across all six files combined: 8×8 lands roughly 200 times, each individual other grid at most once.

The only grids that even participate are 7×9 and 9×7 — both 63 macroblocks, meaning the same stream one macroblock short of the end. That they are not a second, competing image format is measured: of 22 such landings in c12p1, 20 are on pages that also land on 8×8, in c03p1 50 of 50, in c02p0 120 of 120. At these raster widths, the context reset ((mbx & 0xf) == 0 and at line end) differs, and a sparsely populated final macroblock costs so little that the shortened run also lands on the last byte.

That this test can fail is demonstrable: vtplanes.py selftest --sabotage claims Block 1 is 4×4 macroblocks, and outputs FAIL with return value 1 ("lands 0 times on 4x4 against 25 for the best true rival").

3.2 Where the cross-check fails: the form

The raster format is determined solely by the context resets into the bit count ((mbx & 0xf) == 0 and at line ends). For a sparsely populated plane, this amounts to almost nothing — and sparsely populated are precisely the planes that appear at all. Therefore, one must measure whether 8×8 wins among the rasters with the same macroblock count. All six following rasters have 64 macroblocks; 525 Mip-0 pages from c12p1:

The right column is the scale: for a plane that is fully decoded, this test separates clearly — 100 % against 18–31 %. For Block 1, 8×8 comes first, but only with 26 % against 17–23 %. This is not proof of form.

And even the right column does not hold everywhere: on c02p0.pages, Block 2 lands 506/506 on 8×8, but also 81 out of 127 sample pages on another form. For a file with flatter Specular planes, this test therefore barely separates for the proven plane either. The raster form is fundamentally weakly determined by this method; only the macroblock count is not. selftest therefore says nothing about the form, it prints the numbers and makes no claim.

What Block 1 has thus established: 64 macroblocks, 2 channels, NCOMPONENT. That these 64 macroblocks are arranged as 8×8 rests on two indications outside this measurement — Block 2 of the same page is 8×8, and the engine constant PAGE_WIDTH = 128 leaves nothing else open. This is plausible, but it is analogy, not measurement. As soon as the dense pages decode, the same test also separates sharply here; until then the reservation stands.

Status after §9 (Pixels): The reservation remains, but it is now justified instead of merely granted. On pixels, the form test does indeed separate sharply — for Block 2 the ratio of Seam/Control is 0.05 on 8×8 and at 0.98 to 1.18 on every other 64-macroblock form, on the same pages (§9.4). For Block 1 it is nevertheless not applicable: every Block-1 plane that decodes cleanly at all is nearly flat (median spread ≤ 0.5; of 1225 clean planes, 28 have a spread ≥ 4 and none ≥ 16), and a flat page fits any neighbor in any arrangement. The form is thus not measured — not because the test would be weak, but because there is no content-bearing page for Block 1 on which it could grip.

3.3 Cross-check: other color format read methods

The macroblock count is one thing, the channel count is the other. reinterp runs nine color format read methods × each raster up to 12×12 over 60 Mip-0 pages from c12p1:

Everything except the header read method generates single hits on randomly scattered rasters — this is the noise limit. Only NCOMPONENT 2 ch concentrates on a raster at all. The channel count of 2 is thus independently confirmed by the header.

Why only 18 % and not 100 %

The separation is clean and it is Density:

and over the Mip stages of the same file (400 datasets):

Larger Mips pack more image content into the same page, making them denser. A branch count exceeding 150 pages shows the same pattern from within: on landing pages, the highpass path is almost never entered (6,3 coded HP blocks per page out of 2048 possible, with 121,6 out of 128 CBP fields being zero), whereas on failing pages it occurs constantly (76,8 HP blocks).

A single run identifies the location. Landing page (95,96) versus failing page (94,96), both Block 1, both Mip 0, adjacent:

landend  MB 0 154 bit DC=[0,0]   MB 5  41 bit DC=[1,1]    MB 20  64 bit DC=[-1,-1] ... End, Gap 7
scheitert MB 0 154 bit DC=[0,0]  MB 11 55 bit DC=[0,0]    MB 12  54 bit DC=[-5,1]
                                                          MB 14  65 bit DC=[0,19]
                                                          MB 20  24 bit DC=[0,24]
                                                          MB 23 156 bit DC=[-26,1]   MB 25 runs past block end

Up to MB 11, both pages are unremarkable (DC residuals within ±3, both channels equal — for a normal map this is plausible, X and Y are the same in flat areas). Starting at MB 12, values on the failing page explode. This is a desync, not a cut stream: a cut stream provides correct values up to the cut point.

4. Block 0 is not solved

Status after §10: All measurements in this section are correct and remain valid; they measure the old Chroma CBP rule. The finding "the run reads approximately 16 to 21 bits too many in MB 0" was the lead — it is exactly 21 bits, and §10.1 shows which block that is. The seam test at the end of this section (ratio 0.92) does not measure the reconstructed header, but a decoder that loses the stream itself (§10.6).

The same measurements, the same result in every direction: nothing.

• Raster: One exact landing on 4256 pages at 8×8. In a full raster sweep (every raster up to 12×12, 120 pages), only 4 pages land at all, on four different rasters (2×9, 3×6, 6×3, 9×2) — noise.
• Color format: reinterp across nine reading modes yields 0 to 5 landings per mode, none with a dominant raster. The header reading mode YUV_444 3 ch also fails.
• The first macroblock is still plausible. Across three pages, MB 0 yields DC = [-227, 0, 0] or [-226, 0, 0] — a full Luma DC (MB 0 has no neighbors, so the residual is the entire value) and two Chroma zeros, constituting a neutrally colored macroblock. The single-channel Block 2 of the same page provides for comparison DC = [-272]. From MB 1 onwards, Block 0 is already incorrect (DC = [256, 128, 16], [2517, 1676, 0], [897, 980, 0]).
• How far off? A resync search (run MB 0 normally, then restart and evaluate at bit position End + δ, checking if the next 6 macroblocks yield plausible DC values) results over 25 pages in 23 cases of a negative δ, concentrated between −16 and −21: the run reads approximately 16 to 21 bits too many in MB 0. However, δ is not constant, and none of the hypotheses derived from it holds (§6).
• The seam says the same. vtplanes.py seam c01p4.pages, Block 0 reconstructed as a 128×128 RGB stream, decoded by WIC, 200 horizontally adjacent page pairs:

Block 2 fits cleanly together, Block 0 does not at all. The pixel spread of 100.6 for Block 0 alone constitutes the verdict: these are saturated primary colors, no image. (The spread threshold is necessary because a flat page joins seamlessly with any other flat page, thereby proving nothing.)

5. Why the macroblock counter is not the suspect

This is the most critical cross-check of the entire document, because without it, any statement about Block 0 and 1 would merely mean "our decoder cannot do it."

vtplanes.py refgen generates six 128×128 images, whose statistics frame a genuine texture page — flat with a detailed spot, normal-map-like smoothness, thin dots on a flat background, hard edges, fine grain, pure noise — and causes Windows' native WmpBitmapEncoder to write streams from them: three pixel formats (Gray8 → Y_ONLY 1 channel, Bgr24 with SubsamplingLevel=3 → YUV_444 3 channels, Cmyk32 → CMYK 4 channels), six quality levels (10…97), three overlap levels, and ImageDataDiscardLevel=1 for SB_NO_FLEXBITS as in the retail stream. This produces 324 streams.

324 exact, 0 not exact   by (cf, channels): {(4, 4): 108, (0, 1): 108, (3, 3): 108}
negative control (grid one column too wide): 0/40 come out -- must be ~0

The CMYK case with 4 channels is the decisive one: in jxrlib, CMYK follows exactly the same N-channel path as NCOMPONENT — DecodeCBP with iChannel = cNumChannels instead of 1, the per-channel-bit CBP in the lowpass, the chroma context tables from level 1, and UpdateModelMB with aWeight1[band][nch-1]. If the counter is bit-exact on 108 dense 4-channel streams, it will not suddenly be wrong on 2-channel NCOMPONENT.

The negative control serves as a safeguard against the idea that "comes out exactly" is a valueless criterion: the same streams with a raster specification one macroblock column too wide come out 0 of 40 times.

Additionally, the counter was checked line by line against the reference implementation (jxrlib, image/decode/segdec.c, image/decode/strPredQuantDec.c, image/sys/image.c, image/sys/adapthuff.c, image/sys/strcodec.c): DecodeMacroblockDC, DecodeMacroblockLowpass, DecodeCoeffs, DecodeCBP, predCBPCDec, DecodeBlock, DecodeBlockHighpass, DecodeSignificantRun, DecodeSignificantAbsLevel, DecodeFirstIndex/DecodeIndex, getHuff, AdaptDiscriminant, UpdateModelMB, ResetCodingContext, and the reset logic in getTilePos. All seven Huffman lookup tables and all five delta tables were compared machine-to-machine — line by line identical. readIS_L1/readIS_L2 are buffer loading routines and consume no codestream bits.

6. Hypotheses that died of numbers

Already handled by the predecessor and not repeated here: Frequency Mode, adjacent planes, nested planes, the Trim-Flexbits offset.

And a Correction

The predecessor writes to tools/vtdecode.py and the Blackboard fact vtorder.result: "No macroblock grid up to 34×64 makes either come out, on any page." This is incorrect for Block 1 — 765 of 4256 pages land exactly on an 8×8 grid, while every other macroblock count remains in the noise. tools/vtplanes.py belongs to me; tools/vtdecode.py does not; whoever cleans up there should correct the module docstring and append 1: (8, 8) to BLOCK_GRID — with the caveat from §3.2 that this only measures the 64 macroblocks, not their arrangement.

7. What This Means Combined

All three of the following statements are individually measured, and they fit together in only one way:

1. The decoder is correct (324/324 on foreign streams, negative control 0/40).
2. Block 1 is NCOMPONENT 2-ch with 64 macroblocks (765 bit-exact landings, every other macroblock count in the noise; the 8×8 shape only by analogy, §3.2).
3. Nevertheless, 82% of Block-1 pages and 100% of Block-0 pages fail, and the more content a page carries, the more certain this becomes.

From this follows: for Block 1, inverse reconstruction is complete except for the grid shape, and the remainder is no longer a header problem. The stream deviates as soon as multiple channels simultaneously carry coefficients. This is not proof that MachineGames changed the entropy coder — it is the state in which the measurements end.

The difference from single-channel planes is stark: Block 2 and 3 share the same code path up to the multi-channel branches, and they come out correctly 100% of the time. This confines the search space to what happens exclusively with multiple channels and exclusively when coefficients exist: the Chroma context tables (ah[8..10] in Lowpass, ah[16..18] and ah[19..20] in Highpass), the iDiffCBP loop across multiple planes in DecodeCBP, and the second model half (m_iFlcBits[1], aWeight1[band][nch-1]).

8. What Remains Open, and the Next Meaningful Step

Open:

• Why dense Block-1 pages start to fail from the first content-bearing macroblock. The desync point is measurable (page (94,96): MB 12), but the cause is not.
• ~~Block 0 completely — already MB 1 is wrong, and the run reads roughly 16–21 bits too much in MB 0 with fluctuating magnitude.~~ Resolved on bits, see §10: it is a constant 21 bits; it is a Highpass block of the third channel that Chroma CBP prediction wrongly demands, and upon correction Block 0 lands 823× out of 4256. The impression of fluctuation arose because the old search measured δ only at four plausible macroblocks instead of the landing of the entire plane — exactly the hardening this section itself proposed.
• Block 0 remains open on pixels, and specifically at a new location: jxrlib does not read the stream itself (§10.6), so the oracle is missing.
• ~~The seam for Block 1 is not measured and also not measurable with WIC: Windows has no output pixel format for a two-channel image and outright rejects NCOMPONENT with 2 channels.~~ Resolved, see §9.4: measured with jxrlib. Channel 0 hits (distance 120 on 33% of pairs vs 11% random), Channel 1 does not. The gap is half closed and the other half turned into a sharp question.

The two most promising next steps, in this order:

1. ~~Build jxrlib from source and insert Block 1.~~ Completed without building: A fully translated JxrDecApp.exe is already present on this machine (§9.1). The reference decoder reports the same result as WIC (324/324, §9.2) and the same as the Python counter regarding good and bad pages (§9.3). The next step is now Channel 1: §9.4 demonstrates that the first channel aligns spatially while the second does not, despite the bitstream landing correctly. Therefore, a bug must be found that does not change the bit count but only affects the second channel.
2. Disassemble PageCompression.cpp. The EXE references this file in Assert strings. The goal is to locate the encoder side for multi-layer planes — there it specifies what differs between Block 0 and Block 1. The search space has been reduced by §7: only cases where ≥ 2 channels and existing coefficients apply.

An Initial Attempt That Is Not Yet a Result

The Resync search from §4 was applied to Block 1: on a failing page, the first macroblock with an implausible DC is sought (threshold |DC| > 16, learned from landing pages where ±3 is typical), then attempts are made at the preceding macroblock boundary δ ∈ [−48, +48] to check if the next four macroblocks become plausible again.

80 pages, of which 35 had a found first Desync point
24 of these can be repaired by shifting at most 12 bits
delta (sorted by |delta|): -1: 7   +1: 6   -2: 4   -4: 2   -3: 1   +2: 1 ...

Thus, the deviation is small — on the order of a single bit. However: the sign is not uniform, and the plausibility criterion ("four macroblocks with small DC values") is weak enough that a one-bit shift can also satisfy it by chance. This is a lead, not a finding. Anyone pursuing this further should harden the criterion: instead of demanding "four plausible macroblocks," require that the repaired stream lands exactly at the end of the block. Then a hit cannot be dismissed as random.

9. Pixels for Block 1 — and What the Seam Says

Tool: tools/vtpixel.py. All measurements in this section use it.

python tools/vtpixel.py calib REFDIR        # jxrlib vs WIC, byte for byte
python tools/vtpixel.py census              # how many planes become pixels
python tools/vtpixel.py seam                # the seam, Block 2 as positive control
python tools/vtpixel.py shape               # the six 64-MB shapes on pixels
python tools/vtpixel.py rival               # shape test without bitstream as judge
python tools/vtpixel.py png c12p1.pages 95 96 0 --out DIR
python tools/vtpixel.py selftest
python tools/vtpixel.py selftest --sabotage # must FAIL (return value 1)

9.1 The Detour Was Unnecessary: jxrlib Is Already Fully Translated Here

§8 recommended building jxrlib in C because WIC lacks an output format for a two-channel image. A C compiler is not installed on this machine — but a fully translated JxrDecApp.exe from jxrlib 1.1 is already available, under ~/.cache/codex-runtimes/*/dependencies/native/jxrlib/jxrlib/bin/. It accepts NCOMPONENT with 2 channels without issue. Therefore, neither a compiler nor a custom inverse calculation (inverse quantization, inverse PCT, Overlap Filter) needed to be written: the reference decoder was there all along. vtpixel.py searches for it itself and clearly reports if it is missing.

The input is the same as for vtdecode jxr: the plane header in the block remains untouched; only the 16 bytes before it are reconstructed (OUTPUT_CLR_FMT = NCOMPONENT, container pixel format 24bpp3Channels). jxrlib then returns Channel 0 and 1 side-by-side; Channel 2 is null.

9.2 Calibration: jxrlib Is WIC

Before any Block-1 pixel has meaning, the foreign decoder must deliver the same result as the one this document relies on for the rest.

The second line is the more important one: it checks exactly the path that Block 1 takes — reconstructed IMAGE_HEADER, OVERLAP = 1, untouched plane headers — and it incidentally confirms that NCOMPONENT with 1 channel and Y_ONLY truly follow the same decoding path.

A trap that initially reported 62 of 108 RGB streams as "different": JxrDecApp writes its TIFF in RGB order, while WIC returns BGR. This is a byte order within the output wrapper, not a decoder difference — after swapping, they are 108/108. vtpixel.py calib handles this itself.

9.3 Block 1 becomes Pixels — and Bits and Pixels agree

vtpixel.py census, all six files, Mip 0, 7269 Block-1 planes. Two independent verdicts per plane: does the bitstream land in the last byte, and does a clean image without noise macroblocks emerge (worst 16×16 tile under variance 25).

jxrlib rejects no plane — but "decoded" does not mean "correct". The two off-diagonals represent the honest error margin of the two methods: 3.5% of planes are judged differently. Only 5 planes land in the bitstream and still look noisy; 248 look clean without landing (these are the very flat ones where a desync near the end does not ruin the image).

With this, the suspicion against the Python counter is finally settled. On dense pages, jxrlib itself introduces noise, and on the same pages: planes that the bitstream accepts come out smooth 120/120, while planes it rejects come out noisy 112/120. The desync location is also spatially visible — on page (94,96) of c12p1, tiles 0 to 16 are smooth and from tile 17 onward saturated; the Python run holds that same page as implausible starting MB 14.

9.4 The Seam: Channel 0 hits, Channel 1 does not

The test: two adjacent pages share exactly eight columns (or rows) at a page distance of 120. The MAD is measured over these shared lines for each distance from 116 to 124, plus a control from two lines unrelated to each other. Since almost all Block-1 pages are flat and there all numbers become small there, it additionally counts at which distance the seam is smallest for each pair: this is 1 out of 9 = 11% by chance.

vtpixel.py seam, all six files, 11459 adjacent Mip-0 pairs:

Correction to the seam test from §4: vtplanes.py seam compares columns 120…123 on the left side with columns 4…7 on the right. However, at a side distance of 120, column 120+k on the left should correspond to column k on the right — the old test was shifted by four texels. It still worked (3.02 against 24.99) because adjacent columns of a texture resemble each other; when properly aligned, the same measurement becomes significantly sharper (0.38 against 7.44) and reaches a minimum that lies exactly at 120. vtplanes.py was not changed for this; vtpixel.py computes it itself.

The distance profile for Block 1 Channel 0 is a clean V around 120: 116:0.068 117:0.065 118:0.063 119:0.054 120:0.036 121:0.054 122:0.065 123:0.074 124:0.073. For Channel 1, it is flat.

33% against 11% on 120 pairs is not random (z ≈ 7.8). This is the pixel evidence missing from this document — for the first channel. It holds equally at OVERLAP 0, 1, and 2 (Channel 0: 64%, 33%, 52% — Channel 1: 27%, 10%, 17%), so it is not a matter of the overlap filter.

And Channel 1 is not merely noise. Measured as roughness (mean second difference along rows, divided by standard deviation): Block 2, proven correct, lies at 0.10; a desynchronized Block 1 plane at 0.30; Block 1 Channel 0 at 0.08 and Channel 1 at 0.04 — on the same planes, Channel 1 even carries the most content (median spread 3.30 against 0.55). It is a smooth, content-bearing image that is in the wrong place.

This narrows §7 considerably: not "somewhere among several channels", but exclusively in the second channel, and within part of the calculation that does not change the bit count — otherwise the bitstream would not land. Candidates in this order: the second model half (m_iFlcBits[1], aWeight1[band][nch-1]), the chroma context tables from plane 1, and the assignment of coefficients of the second channel within the macroblock.

9.5 The Form: decided for Block 2, still undecided for Block 1

vtpixel.py shape decodes the same sides under each 64-macroblock form and maps the macroblock n back to its position in the 128×128 side. A wrong form shifts every macroblock, causing the seam to break:

Thus, the form test is very sharp on pixels — 0.04 against 0.98 to 1.18. The weakness from §3.2 lay in the method (bit length), not the test.

It still does not apply to Block 1, and vtpixel.py rival shows why. There, only sides that the bitstream accepts on both forms are counted — for them, the length argument is a tie, and only the image can decide. There are 80 such sides each, with their spread lying at 0.01 to 0.5, on 8×8 as on any rival, for Block 1 and for Block 2. Flat sides distinguish no forms. Therefore, the reservation from §3.2 remains; it is now quantified rather than merely conceded.

9.6 What the selftest guarantees — and what it does not

vtpixel.py selftest asserts three things and computes each against a control: Block 2 fails at distance 120 and only there (positive control), Block 1 Channel 0 likewise (distance 120 clearly above the random quote of 11%, seam below half the control), and bitstream and image agree plane by plane. It makes no conscious guarantee regarding Channel 1 or the Form; it prints the numbers and asserts nothing.

vtpixel.py selftest --sabotage claims the layers are 4×16 macroblocks and immediately returns FAIL with exit code 1: the positive control fails (seam 0.690 against control 0.880 instead of less than half) and Block 1 Channel 0 reverts to the random rate (14% of 85 pairs).

10. Block 0: The 21 Bits, and Why They Don't Come From Our Decoder

Tool: tools/vtpixel.py block0. Everything in this section is measured with it, purely on bits — it does not need jxrlib.

python tools/vtpixel.py block0                       # the number, both rules
python tools/vtpixel.py block0 --rivals 400          # the controls for that
python tools/vtpixel.py block0 --refs REFDIR         # the cross-check against WIC
python tools/vtpixel.py selftest                     # now contains Block 0

10.1 The Error Sits in Macroblock 0, and in No Other One

§8 proposed hardening the resync search: "demand that the repaired stream lands exactly at the end of the block". Precisely this, applied to Block 0:

150 Mip-0 layers, none land unchanged.
A single shift by delta bits, inserted
   after the DC of MB 0:       0 layers repaired, no delta in [-32,32]
   after the Lowpass of MB 0: 0 layers repaired, no delta
   after the Highpass of MB 0: 34 layers repaired -- delta -21: 33x, -28: 1x

This says three things at once, and each individually:

1. A single shift is sufficient for the entire 64 macroblocks. The error happens exactly once, in Macroblock 0, and never again thereafter.
2. DC and Lowpass of MB 0 end at the correct place — otherwise a shift there would have repaired something. The overflow is in the Highpass.
3. The magnitude is constant 21 bits, across pages with entirely different content.

The rest is reading off. For the repaired layers, the CBP of MB 0 and the bit cost of each Highpass block look like this on all checked pages:

diff CBP  [0x1, 0x1, 0x1]      predicted   [0x0, 0x0, 0x1]
ch0: 0 coded blocks     ch1: 0 blocks     ch2: 1 block, 21 bits

The 21 bits are exactly one Highpass block of the third channel, which the CBP prediction demands and which the encoder never wrote.

10.2 The Cause: The Two Chroma Channels Share a State

pred_cbp_dec gives Channel 1 and Channel 2 the same prediction state location (cbp_state[1]) and closes it after each of the two. In Macroblock 0, it starts at 0; Channel 1 is predicted with this (cbp ^= 1, cascade → 0 blocks), its closure sets cbp_count0[1] = -4 + 0 - 3 = -7 < 0 and thus puts the state on 1 — and then Channel 2 is read raw: 0x1 remains 0x1, one block. If both chroma channels are predicted from the state as it stood before the closure of Channel 1, then Channel 2 becomes 0x1 ^ 1 = 0 → cascade → 0 blocks, and the 21 bits are gone.

Macroblock 0 is the only macroblock that has no neighbor to the left or above, thus the only one with the start value cbp ^= 1. This explains exactly why the error happens once and then no longer.

10.3 The Number, Over the Same Corpus

Strict run, 8×8 macroblocks, must stop in its own last byte — same measurement and same corpus as in §3 and §9.3.

First corpus, the first 1200 datasets per file (the table from §3):

Second corpus, all Mip-0 layers (the population from §9.3, 7269 layers): 2 (0.03 %) → 1493 (20.5 %).

Block 1, 2, and 3 do not change here (765/4256 unchanged, 4233→4235/4256, 4256/4256): they are NCOMPONENT and do not take the chroma branch.

This places Block 0 in the same order of magnitude as Block 1 (18.0%) — and for the same reason: they are both sparsely populated pages. The value from §4, "1× on 4256 pages, exactly the noise limit," remains correct; it was the measurement of the old rule.

10.4 The Checks: the Rule Did Not Cheaply Grant the Criterion

A rule that lets everything land would have destroyed the criterion instead of solving the level. Thus, the same question as in §3.1 and §3.3, under the new rule, with 400 Mip-0 levels from c12p1 and c03p1:

And a second test independent of bitstream: the DC Residue. The stream encodes for each macroblock only the difference to its neighbors, so it remains small as long as the stream has the residue, and explodes once it loses it (§4 showed this with [2517, 1676, 0], [7424, 3328, 3332]). Over all 7269 Mip-0 levels, 95th percentile of |DC Residue| across macroblocks 1…63:

This is for Block 0 what §9.3 was for Block 1: two verdicts per level with no reason to agree unless they measure the same thing.

10.5 The Counter-Test, and What It Reverses

The most important measurement of this section is the one that speaks against the new rule. The same rule applied to the 324 reference streams from vtplanes.py refgen:

Gray8 (108/108) and Cmyk32 (108/108) remain unaffected — they do not go through the Chroma branch. It is exclusively the three-channel YUV_444 streams, and it is irrelevant how one varies the closure (per channel, once jointly, only after the last: 232 / 232 / 228) or whether one restricts the rule to Macroblock 0 — then both corpora yield exactly the same numbers. That too is a measurement: the deviation exists only in Macroblock 0.

This means: the two encoders are not compatible at this point. The macroblock counter of vtdecode.py is not wrong — it writes exactly what Windows' own encoder writes; §5 remains fully valid. The encoder of MachineGames does something different at Macroblock 0, and only there. The search space from §7 ("what happens exclusively with multiple channels and exclusively with existing coefficients") was correctly bounded — the answer was not a decoder error but an encoder deviation. Which of the two readings T.832 covers is thus not decided and also irrelevant for this purpose: what matters is which one the game wrote.

Therefore, the corrected rule stands in vtpixel.py and not in vtdecode.py: it is applied only around a Retail-Block-0 run via a with mg_chroma(): block and then removed. vtdecode.py and vtplanes.py retain the WIC rule, and vtplanes.py refcheck remains 324/324.

10.6 The Cost: jxrlib Is Not an Oracle for Block 0

This is the unpleasant consequence, and it is measured. JxrDecApp accepts Block 0 without objection — but it uses the same rule as vtdecode.py and loses the stream at exactly the same place. Tile-wise scattering of Channel 0, c12p1, Mip 0, the first 16 of the 64 tiles:

Block 0, Page (118,96): 23 46 17 0 0 0 0 0 84 0 0 0 0 0 0 0
Block 2, same page: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Block 0, Page (95,96): 67 0 0 0 0 0 0 54 0 0 0 0 111 0 0
Block 2, same page: 0 17 7 13 13 10 11 0 0 13 4 8 17 10 12 0

From the second tile onward, Block 0 is saturated while Block 2 is not. This is the same desync counted by the Python run, and it is the reason why §4 measured Block 0 as having "saturated primary colors, no image" and a seam ratio of 0.92: not because the reconstructed IMAGE_HEADER was incorrect, but because WIC and jxrlib cannot read the stream itself.

Consequently, the seam test for Block 0 is not measurable with the available means — and this is not an excuse, but rather the same statement from the other side: a decoder that reads Block 0 incorrectly cannot also show a seam. §9.1 explained why the detour via its own backward calculation (inverse quantization, inverse PCT, Overlap-Filter) is unnecessary; this holds true for Block 1, but not for Block 0. For Block 0, it is the only path to pixels.

The status is therefore, without embellishment: Block 0 is solved on bits but open on pixels. The two sentences do not contradict each other; they name two different processing steps. What the backward calculation already provides as preparation: the bit stream matches, and vtpixel.py dc_walk outputs the DC residuals already as numbers. What is missing are the coefficient values themselves (the Lowpass branch today only remembers that a coefficient exists, not what value it has), the dequantization with the QPs from §2, and the two stages of inverse PCT.

10.7 The shape of Block 0 is just as unproven as that of Block 1

The same reservation as in §3.2, and it has been measured: under the Retail rule, Block 0 lands on 4×16 macroblocks (that is, 64 pieces in a different arrangement) on 26 of 200 planes = 13%, compared to 21% on 8×8. This is the same weak separation as for Block 1 (26% against 17–23%) and for the same reason: the raster form only enters the bit count via context resets, and the planes that actually emerge are the sparsely populated ones.

Thus, for Block 0 only the macroblockcount of 64 is proven, not the arrangement — any raster with a different number remains at 0 to 1 (§10.4). For Block 0 there is, unlike for Block 1, a prospect of deciding this: its planes are not flat (spread 39 to 100 instead of 0.5), so the shape test from §9.5 would apply — as soon as there are pixels.

10.8 What selftest now additionally guarantees

vtpixel.py selftest checks Block 0 primarily and without jxrlib, and it secures only the Chroma rule and the macroblock count, not the shape:

• under the Retail rule, at least 10% of Mip-0 planes must land (measured 63 of 300 = 21%) — if mg_chroma were ineffective, this would be 0 and the test would fail,
• under the vtdecode rule at most 1% (measured 0),
• the best competing raster with a different macroblock count at most one quarter of that (measured 1),
• the DC residual of the landing planes less than one quarter of that of the failing ones (measured 1 against 16).

selftest --sabotage claims 4×16 macroblocks and returns FAIL with return value 1 — but not because of Block 0: its group holds 4×16 (26 of 200), exactly as §10.7 states. It breaks the positive control for Block 2 (seam 0.314 against control 0.006, ratio 55) and the seam test for Block 1 Channel 0. This is explicitly noted here because a self-test that does not bite on a claim looks like one that does.

11. Block 1, Channel 1: what died this time

Channel 1 remains not solved. Three measurements have been added; they narrow the question instead of answering it.

11.1 A new, independent test: the macroblock edge

The seam requires two neighboring sides and sufficient contrast; both are scarce in Block 1. However, there is a test that works with only one side: the Overlap-Filter is precisely what smooths the jump across a macroblock boundary. Therefore: mean |Δ| over the 16-px grid lines, divided by the mean |Δ| elsewhere. Block 2 is the calibration — it is proven on pixels:

The test separates sharply and confirms for Block 2 OVERLAP = 1 — it is therefore not blind. For Block 1 it states two things: the value lies at both channels significantly above that of Block 2, and the minimum lies at OVERLAP 2 instead of 1. Both are findings with n = 7; they are the hint where one should continue with more levels. Whoever picks this up must first check whether not simply the lower variance of Block 1 (Median 1.1 to 3.2 against 6.7) drives the ratio upward.

11.2 Is Channel 1 only offset? Not answered — and why not

If Channel 1 were only misregistered — by one macroblock, by half a side, by whatever —, a search over all offsets would find it. Two searches, both with Channel 0 as an embedded control; both fail on the control, not on Channel 1. The offset hypothesis is therefore neither proven nor refuted; it is untested — and that is the more useful information than one based on a failed measurement:

• 2D offset search between neighboring sides, dx ∈ [40,128], dy ∈ [−16,16], on the sides assumed by the bitstream: over four .pages files remain 7 measurable pairs, and their best offsets scatter (+112/−22, +32/+1, +42/−24, +32/0, +32/−1, +116/+1, +104/+24). The sample is too small for a statement — it is noted here so the next person does not run the same dead end again: among the landing sides there are hardly any neighboring pairs with contrast in both channels.
• Extending the search to all image-clean sides (the 248 levels from §9.3) brings 1731 neighboring pairs, but the method itself no longer holds — §11.3.

11.3 Grid spacing over the entire range — a test that does not stand its own control

re_probes/vtrest/probe12.py iterates through every side spacing from 8 to 126 for neighboring, image-clean Mip-0 pairs, instead of only 116…124, and counts the best per pair. Channel 0 must find 120; otherwise the test is worthless. Over all six files, 1731 neighboring image-clean pairs:

60 spacing candidates, random quote 1.7 %
ch0: 34 measurable pairs, spacing 120 wins  4/34 = 12 %
     most frequent:  8:11x   120:4x   32:3x   16:3x   100:2x
ch1: 70 measurable pairs, spacing 120 wins  7/70 = 10 %
     most frequent:  8:19x   126:10x  120:7x   124:5x   16:3x

The control fails, and it is explainable: at spacing 8 two sides overlap on 120 lines, and with two nearly flat sides with similar mean, a MAD over 120 lines is smaller than one over 8 — not because it fits, but because much area averages out. The wide spacing sweep thus systematically favors large overlaps and is not a usable test for flat levels. The narrow test from §9.4, which only compares 116…124, does not have this problem because there all candidates have nearly the same area; it finds cleanly for Channel 0 a 120 (48% of 69 pairs against 11% random, status vtpixel.py selftest).

Thus §11.2/§11.3 is not a finding on Channel 1, but a dead method. Whoever wants to revive it must normalize the MAD against a null hypothesis with the same overlap area — for example against the same spacing with an uninvolved neighboring side. It is noted here so the next person does not build it again from scratch.

Incidentally, this reveals a number that §9.5 only addressed qualitatively: out of 1731 adjacent, clean Mip-0 pairs, only 34 in Channel 0 and 70 in Channel 1 possess sufficient contrast (scatter ≥ 2) to be measurable at all. These amounts represent 2 to 4 %. The seam test for Block 1 is not weak because the test itself is weak, but because there is almost nothing left to measure.

11.4 What remains open regarding this

The finding from §9.4 stands unchanged and has become sharper with more pairs. vtpixel.py selftest was run on three files, involving 5423 adjacent Mip-0 pairs:

Channel 1 thus lies below the random quota of 11 %, and its distance profile is flat (116…124: 0,164 → 0,157, minimum at 122). The only new thing is what the error is not:

• not a matter of the Overlap filter alone — it changes both channels equally, and Block 2 as calibration selects OVERLAP 1 unambiguously from the same test (§11.1),
• and not the same as Block 0: the Chroma-CBP finding from §10 concerns YUV_444 and leaves Block 1 exactly unchanged (765/4256 before and after).

And open, but now cleanly open: whether Channel 1 is merely shifted. §§11.2 and §11.3 did not clarify this because the shift search lacks its own control. Whoever wants to clarify it must first perform a shift test that works on flat planes — §11.3 states where the naive approach fails.

The next sensible step remains that from §8: disassemble PageCompression.cpp. §10 has shown that MachineGames changed the encoder at least in one place — thus "the stream deviates" is no longer an excuse, but a proven property of this encoder, and disassembly is the only source stating where these places are.

Where the knowledge ends

Secured, recalculated at four locations:

• The headers of all four blocks, exactly one variant per block over 399 pages, secured by the 40-bit probe on ff 00 00 01 00.
• Block 1 = NCOMPONENT 2 channels across 64 macroblocks: 765/4256 bit-exact runs over six .pages files, every other macroblock count and every other color format reading in noise. The arrangement as 8×8 (= 128×128 px) is not measured but deduced from Block 2 and PAGE_WIDTH (§3.2).
• The macroblock counter is correct: 324/324, negative check 0/40. And it is not only internally correct: on the same retail pages, jxrlib judges exactly the same (§9.3), layer by layer, with a 3.5% deviation.
• Block 2 abuts its neighbors seamlessly (MAD 3.02 against control 24.99; with corrected column alignment 0.38 against 7.44, §9.4); Block 0 does not (97.68 against 105.89).
• Block 1 yields pixels (§9.3): 1225 of 7269 Mip-0 layers emerge cleanly both in the bitstream and in the image, while jxrlib rejects none.
• Block 1, Channel 0 abuts its neighbors (§9.4): Distance 120 is best at 33% against 11% by chance, seam/control 0.23. This is the independent pixel evidence missing from this document.
• Block 0 yields bits (§10): 823 of 4256 layers run all 64 macroblocks and stop at their own last byte against 1 prior, and across the full Mip-0 population 1493 of 7269. The cause is named and recalculated (§10.1/§10.2), the checks stand (every competing raster except the 63-macroblock near-misses at 0 to 1, every other color format reading at 0), and the DC residues of the arriving layers are at 1 against 16 for the failing ones. As with Block 1, it is established that the macroblock count is 64, not the arrangement as 8×8 (§10.7).
• The MachineGames encoder is not WIC-compatible (§10.5) — proven, not conjectured: the rule that Block 0 breaks violates 92 of the 108 YUV_444 reference streams, and no variant reconciles both.
• Fifteen hypotheses are refuted by numbers (§6).

Not solved:

• Block 0 on pixels. Solved on bits (§10), but without an oracle: WIC and jxrlib share the rule at which the stream fails, and output noise starting from the second tile (§10.6). The path there is now a backward calculation — coefficient values, dequantization, two stages of inverse PCT, overlap filter — no longer a search.
• Block 1 for the 83% dense pages. Newly bounded: Channel 1 is spatially incorrect, although the bitstream lands and the image is smooth (§9.4). The error does not change the bit count and affects only the second channel.
• The raster form of Block 0 (§10.7): 4×16 lands at 13% against 21% for 8×8, the same weak separation as with Block 1. Unlike with Block 1, it is here decisive once there are pixels — Block-0 layers are not flat.
• The raster form of Block 1 — and specifically from a now quantified basis: every Block-1 layer that decodes cleanly is flat (§3.2 box, §9.5). On pixels the form test is sharp (Block 2: 0.04 against 0.98–1.18), there is for Block 1 only no side on which it can grab.
• Thus still no pixel export of a complete page — the Diffuse layer is missing, and it is the one on which modding would aim. New, however, is what it lies in: not anymore that no one knows how the stream is read, but only that no one calculates it back.