eeu.pcl — Phoneme Cluster List

Status: ✅ Identified — genuinely empty on this disc, real name and purpose confirmed via the disc's own files.cfg. · 94 bytes (header only, no body) · NOT_COMPRESSED

The file itself — nothing left to decode

94-byte header, zero body bytes — confirmed directly: file size is exactly 94, and bytes[90:94] (total_size, see Header Trailer Fields) also reads 94, an exact match to the header's own size (this is not one of the 2 known exceptions — eeu.iof/eeu.mod — that store the body size instead of the header-inclusive total). bytes[86:88] (record_count_lo16) reads 0, consistent. bytes[84:86] (file_type) reads 48 — confirmed not the same numbering scheme as files.cfg's own fileId below (e.g. eeu.rd's header file_type is 4, but files.cfg assigns it fileId 0 — two independent numbering schemes).

Why eeu.mod couldn't identify this file

eeu.mod's 1,605-string schema dump has no table block for eeu.pcl at all — re-confirmed here: every pcl occurrence anywhere in the file is a prefix inside compound field names — pcl_cnt, maxPclId, pcl_dir, pcl_hndl_list, pcl_hndl, pcl_offs, max_pcl_id, pcl_handle — all belonging to the unrelated "Ordinary Map File" MAP_COMPRESSED tile schema, where "parcel" is an internal spatial-subdivision/index concept for locating shapes inside a tile. No standalone NUL-delimited pcl token exists anywhere in eeu.mod. This dead end is what this project's eeu.mod write-up originally meant by "its real purpose is still unexplained."

The real answer: the disc's own files.cfg

The answer was hiding in a file this project had already partially used (for its top-level 4-compression-type legend) but never fully read line-by-line: files.cfg (plain text, disc root, not part of the db/ compressed-data model) is a literal fileId → extension → compressionType → one-line-comment table for all 39 logical file types the database format supports (numFileIds = 39) — not just the ~30-odd this specific EU-East disc actually populates. Its entry for id 27:

27 = pcl, 0, cached		# phoneme cluster list

compressionType 0 = NOT_COMPRESSED, matching the real file exactly (no eeuz.pcl exists). The comment places it squarely in the same phonetic/TTS-support family as eeu.abc (character repertoire), eeuz.pca (phoneme catalog — id 26, immediately before pcl in the table), eeuz.pct (phoneme city list — id 28, immediately after), and eeuz.prd (phoneme road list — id 29): a "phoneme cluster" is a standard TTS/phonetics term for a grouped sequence of phonemes (e.g. a syllable onset/coda consonant cluster), so this file's role was almost certainly a lookup table of valid/known phoneme clusters for the TTS engine's own pronunciation or syllabification rules — conceptually adjacent to, but distinct from, eeuz.pca's catalog of individual phonemes. Not independently confirmed against real content — there is none on this disc to check.

A side discovery: 3 file types that don't exist on this disc at all

Cross-checking files.cfg further surfaced 3 file-id entries this project had never encountered on disc: 7 = ptp ("point types"), 15 = pdx ("poi index file"), 16 = pti ("point types international") — none of eeu.ptp/eeu.pdx/eeu.pti/eeuz.ptp/eeuz.pdx/eeuz.pti exist anywhere under db/ on this disc, not even as empty 94-byte placeholders like eeu.pcl/.pmp/.pol/.pot. A real distinction between "declared by the format, file not even created this release" (ptp/pdx/pti) and "declared, file created but left empty" (pcl/pmp/pol/pot). Not pursued further.

Bottom line

eeu.pcl's identity is now fully established straight from the disc's own authoring metadata, not inference — a real, named, NOT_COMPRESSED "phoneme cluster list" table the map-authoring tool simply never populated for this specific EU East V17 release. There is no byte-level format left to reverse-engineer (zero body bytes exist to examine); this is as cracked as an empty file can get.

Reader code

research/pcl_reader.py — read_pcl(), is_empty_placeholder().