What a software census can tell us.

COMPLETED DERIVED ANALYSIS · PUBLIC METADATA ONLY

Abstract

This study examines the composition of the reference catalogued as EQ The Outer Brood (TOB) client - (Release Client #630 - Sep 11 2025). It calculates distributions from the published extension census, rather than opening the client again. The input reconciles to 15,476 files and 15,870,202,692 declared uncompressed bytes across 45 labels. File counts and byte weights describe markedly different concentrations. This difference supports a practical research question: how should preservation work balance coverage of many small objects with examination of a few labels carrying most bytes? The result is a reproducible planning baseline, without identifying validated formats, dependencies, or cultural importance.

1. The installation as a population

A software installation contains objects that can be counted in several ways. Counting members treats every file as one observation. Summing declared lengths treats every represented byte as one unit of weight. Neither perspective is inherently the correct account of the installation. They expose different aspects of the same aggregate record, much as counting documents and measuring shelf space would answer different questions about a physical collection.

Here the categories are filename extension labels inherited from the earlier census. They are not verified format identifications. The Library of Congress has documented how extension reports can misrepresent formats and access requirements. Library of Congress: analyzing a born-digital archive That methodological caution matters before calling these figures a format ecology: the ecology measured here concerns labels and weights.

The reference inspection date is 2026-10-15. This derived analysis retains its ZIP identifier, 6cb5e3b52c27391051ddfe5f0896d05d6e240a87ec442269fdbe7739ec9397ab, to specify which census it summarizes. Reusing that identifier does not imply a new inspection of its payloads.

2. Arithmetic before interpretation

The offline Python method reads only reference-record.json. It requires nonnegative integer counts and lengths no greater than 2⁵³ − 1, rejects inconsistent totals, and preserves a deterministic lexical ordering when weights tie. The upper bound supports exact integer interchange with the public renderer. A label with zero files cannot carry positive bytes. These checks prevent some malformed inputs from producing authoritative-looking percentages, while leaving the truth of the original inspection outside this calculation.

For label i, let nᵢ denote its file count and bᵢ its declared uncompressed bytes. File share is nᵢ / Σn; byte share is bᵢ / Σb. The label mean is bᵢ / nᵢ. This last quantity is an average declared member length. It is not compressed transfer size, allocated disk space, memory consumption, or the size of a typical individual file.

The published totals reconcile exactly: both category sums equal their respective input totals. Integer sums remain exact; derived fractions and statistics are rounded to twelve decimal places. Undefined zero-weight distributions receive null values rather than invented zero entropy. Input checks establish internal consistency, not authenticity, completeness of the underlying installation, or freedom from unwanted additions.

3. Two rankings of the same collection

The file-count leader is .wav, with 3,977 members: 25.698% of files but 6.683% of bytes. The byte-weight leader is .eqg, with 10,131,920,050 bytes: 63.842% of the byte total but 16.626% of files. The leaders differ because frequency and accumulated length are different properties.

This distinction changes what an apparently broad survey would cover. Selecting many files from the most frequent label could provide substantial object-count coverage while leaving most represented bytes unexamined. Conversely, selecting work according to byte concentration could overlook numerous smaller objects. Neither selection can be called representative without specifying the outcome it is intended to describe.

Names such as these may suggest familiar technical roles, but this study does not assign them. A suffix alone cannot establish a decoder, internal structure, asset purpose, licensing status, or whether one member embeds many further objects. The measured results remain useful even while those interpretive questions are open.

4. Concentration makes the choice visible

The five leading file-count labels are .wav, .eqg, .dds, .txt, .s3d. Together they contain 11,337 files, or 73.255% of the census. The five leading byte-weight labels are .eqg, .s3d, .mp3, .wav, .zon. Their 14,820,719,006 declared bytes account for 93.387% of the byte total. These are independently ranked sets, rather than one set evaluated two ways.

The larger byte concentration means that a few extension groups carry most represented length. It does not establish that a few individual files dominate: each group contains its own unobserved distribution. Nor does it establish that the remaining labels are expendable. A small configuration or definition can matter to a particular research task even when its storage weight is negligible. That possibility requires investigation, rather than an assumption that size proves a dependency.

Top-one and top-five shares are deliberately simple summaries. They expose concentration without creating a priority score. Ties are settled lexically for deterministic output; that ordering does not make a tied label uniquely dominant. Another study could choose a different threshold, provided it records the choice before using the result to justify coverage.

5. Label diversity under two sampling rules

Following the discrete entropy measure, we calculate H = −Σ pᵢ log₂(pᵢ) over positive weights, expressed in bits. Shannon, A Mathematical Theory of Communication (1948) Our two probability models ask for the label of a uniformly selected file, or of a uniformly selected declared byte.

We define effective label count as 2ᴴ: the number of equally weighted categories that would have the same entropy. It is generally fractional. The file model yields 10.283 effective labels, while the byte model yields 3.943. Both models include 45 observed labels; the smaller effective counts reflect uneven weighting.

These quantities describe categorical diversity under stated sampling rules. They are not cryptographic entropy, estimates of payload compressibility, software complexity, artistic quality, cultural significance, or runtime dependency counts. Their value is comparative discipline: a later census analyzed with the same labels and rules could show whether concentration changed. A changed grouping rule could also change entropy without any payload changing.

6. What the averages leave unresolved

Each row’s mean compresses a label’s total length into one ratio. It gives a convenient arithmetic comparison but cannot reveal the median, range, maximum, or number of exceptionally large members. Two hypothetical groups could have identical counts and total bytes while one contains equal-sized files and the other contains one large file beside many tiny files. This census cannot distinguish them.

Accordingly, the average is useful for estimating the represented scale of a group, not for planning a per-file processing limit. Such a limit would need individual sizes. It also cannot forecast processing time: a small structured object might be difficult to interpret, while a large object might require little analysis for a specific question. No timing or decoder test was performed.

The same restraint applies to compressed storage. These inputs contain aggregate uncompressed member lengths by label, without corresponding compressed lengths by label. A claim that one group compresses better, costs more bandwidth, or consumes more physical storage cannot be derived from the available ratios.

7. A preservation triage model to test

The completed measurements suggest a proposed planning model with three independent axes: represented volume, unresolved format identity, and relevance to a declared research task. Volume comes from this census. Identification uncertainty and task relevance require new evidence. Keeping those axes separate prevents a storage-heavy label from automatically outranking a small member that an investigation actually needs.

A volume-oriented pilot could begin with the byte-leading groups and ask how well identification tools cover them. A breadth-oriented pilot could deliberately include every label. A task-oriented pilot could select components already associated with a specified question. These are alternative designs with different objectives, rather than interchangeable claims of comprehensive preservation.

Labels represented by one or two files number 16 here. Together they contain 22 files and 49,753,895 declared bytes, or 0.314% of the byte total. This rarity threshold is an explicit screening choice, not a diagnosis of obsolescence or fragility. Rare labels could merit documentation because a volume-only pilot would easily miss them; whether they matter requires examination.

8. Proposed format-identification investigation

A next study could compare extension labels with evidence from internal signatures in lawfully held members. It should retain both descriptions rather than silently replace the original label. The National Archives describes DROID as using internal signatures and the PRONOM registry for format identification. National Archives: DROID No such identification run is reported here.

Before that work, define a sampling strategy, the tool and signature version, the treatment of conflicting matches, and the handling of containers. An unknown result should remain unknown. It could reflect missing signature coverage, a different representation, or a tool limitation; this aggregate record cannot determine the cause.

Use original authored controls with deliberately matching and misleading extensions to test whether the proposed workflow distinguishes names from contents. Report false matches and unresolved cases. For a sampled study, publish coverage by both files and bytes, along with selection rules. The outcome would be a qualified identification record, rather than an inference that every member sharing a suffix has one validated format.

9. A baseline for software maintenance history

Composition can also frame later historical comparisons. An independently identified second census could show whether labels gained members, lost represented bytes, or changed average length. Keeping the procedure stable would make those aggregate differences inspectable. A shift could motivate questions about packaging, content accumulation, or toolchain change, but those explanations would remain hypotheses until corroborated.

For example, the selected labels .xml, .html, .js, .css jointly account for 451 files and 5,112,698 bytes here. That is a stated query over labels, not a verified category of interface resources. A later increase would justify asking what changed within the selected members. It would not independently establish an interface migration, more source code, or additional functionality.

A useful comparison should preserve absolute counts alongside shares. If one large group grows, every unchanged group’s byte share can fall. Calling that a decline in those groups would confuse a changed denominator with a loss of material. This is one reason the public output retains integer weights and ordered rows as well as summary statistics.

10. Reproduction and meaningful controls

The published Python tests include a balanced two-label distribution, a skewed example whose file and byte leaders differ, reordered inputs, tied weights, and a six-label concentration example. Singleton and zero-weight cases test the boundaries of entropy and shares. Invalid totals and weights are rejected. These controls check arithmetic expectations on small, independently understandable inputs.

A separate check regenerates the published analysis from the public census and compares the complete output. Reproduction therefore needs only the aggregate JSON and standard-library script. No client download, binary execution, network request, account, or submission is part of this method. A disagreement should identify the input record and method version before attributing it to the underlying software.

The contribution is a measured description of how this installation’s declared volume is distributed, with a research plan that can be challenged. It supports practical preservation questions while leaving source authenticity, actual formats, runtime behavior, significance, and any right to distribute software to their own evidence.

Derived analysis · JSON · Offline analysis method · Python · Input census · JSON · Project register · Reference ZIP and torrent

Source relationship: the analysis identifies the same reference ZIP as the input census; the two recorded identifiers agree. It performs no new archive inspection.