eeuz.pct — Phonetic City Names

Status: ✅ Cracked · 15.7 MB compressed / 27.4 MB decompressed · FLAT_COMPRESSED (see container format) · Record format is cracked and validated at full file scale; the trailing "group" field's grouping behavior AND its own derivation are both cracked — the latter closed out in a later session via eeu.mod, the disc's own schema dictionary.

A phonetic pronunciation catalog for city names, specifically — the same family as eeuz.prd (road names) but for major places, and covering many languages per place. Not previously examined — only its FLAT_COMPRESSED container was known.

Record format

94-byte header, then self-delimiting variable-length records:

uint8    name_len
bytes    name           -- name_len bytes
uint8    phon_len
bytes    phon           -- phon_len bytes, same phonetic alphabet as eeuz.prd
bytes[6] group           -- see below

Validated at full scale: parsing the entire 27,386,485-byte decompressed body this way consumes every byte with zero leftover at EOF, producing exactly 649,956 well-formed records.

The 6-byte "group" field — fully cracked

This field reliably groups every language's name variant for the same real place. Checked directly against real, complete groups (not a cherry-picked pair):

Group (hex)	Members	Real place
744f180bf414	26	Venice, Italy — VENEDIG, VELENCE, VENETSIA, VENICE, VENISE, BENÁTKY, VENETIA, VENEZA, ...
e4ac7f072c00	26	Vatican City — VATIKÁNVÁROS, CIUDAD DEL VATICANO, CITTÀ DEL VATICANO, VATICAN CITY, ...
9b7c220eb618	22	Munich — MÜNCHEN, MONACHIUM, MÚNICH, MONACHO, MNÍCHOV, MUNICH, ...
bb934d036b0e	22	Frankfurt am Main

314,645 distinct group values across 649,956 records; median group size 2. The single largest "group" — 000000000000, 73,396 members — is a sentinel for "no roads linked" (this project's established 0 = unset/padding-sentinel convention, seen elsewhere in e.g. the false-edge topology bug). Its members are small, single-language-looking local place names with presumably no road data recorded, not a real 73,396-way collision.

The group value's own derivation — CRACKED (via eeu.mod)

The 6 bytes are [uint32 LE offset][uint16 LE count] — a pointer into eeuz.prd, naming that city's own list of road/route phonetic entries. Confirmed directly by eeu.mod (the disc's own schema dictionary), whose real field names for this exact table (phCity) are .../phonemeRoadOffset/phonemeRoadCount.

This also explains the earlier grouping-behavior finding from the other direction: multi-language name variants of the same real city correctly share the identical group value because they all refer to the same underlying place's same roads — what first looked like a "language- variant grouping key" is really "this city's own roads," incidentally shared across every spelling of that city's name. It also retroactively explains why the three offset-into-eeu.cty/byte-offset/hash hypotheses tested earlier all failed: the field was never a eeu.cty or .fea pointer at all, it points into a completely different file.

Validated directly against real content in eeuz.prd, not just schema-name-matching: interpreting the bytes this way and looking at eeuz.prd right around the resulting offset finds real, clearly place-appropriate road/route entries for every example checked — Venice's group (744f180bf414) lands right next to real Adriatic ferry-route entries VENEZIA-CORFÙ and VENEZIA-PATRASSO; Vatican City's group lands among real Italian streets (VIA ARIANO IRPINO, VIA SORRENTO — Vatican City sits inside Rome, so nearby Italian street names is exactly right); Munich's lands at a real Munich square (LEONRODPLATZ); Frankfurt's lands among real Frankfurt streets (MANNHEIMER STRASSE, DÜSSELDORFER STRASSE).

The exact byte-level anchor convention (whether offset is a raw absolute file position or needs a small fixed adjustment) wasn't pinned down to the last byte — the landing point is sometimes a handful of bytes before the nearest clean eeuz.prd record boundary rather than exactly on one — but the overall mechanism (offset+count pointer to a city's own road phonetics) is no longer in doubt.

Reader code

research/pct_reader.py — iter_pct_records(), group_int(), parse_group(). Full methodology in its module docstring and in eeu.mod's.