The user asked for more compression 'by any means possible', suggesting
base-62 numbers and dictionary phrases. Both ideas shipped — cranked up:
- Dictionary grew ~170 data-mined entries: every function WITH its open
paren (sin(, if(, megabuf(, …), every engine variable (vol_att, time,
bpm, sv, …), AVS idioms ("hue = hue + dt * ", "t = t + dt * ", " * 0.",
") * ", "(0."), header lines ("linewidth: ", "blend: additive",
"mode: lines"), blank-line+section skeletons ("\n\n[point]\n"), CRLF
statement ends, ~70 number literals, and the library's common variable
names (ring, spokes, chroma, segs, …) — all mined by frequency over the
101-preset embedded corpus with a greedy-cover scorer.
- New scheme ▼ 'big-base packing': the dictionary output is read as ONE
BIG NUMBER over its own alphabet and rewritten in base 32,164 — one
digit per character from CJK Unified + Hangul. ~15 bits/char vs
base-62's 5.95 ("1400" costs ~0.85 chars). The body's alphabet rides
in a ~32-char bitmap header (dict-symbol bitmap + ASCII bitmap + raw
non-ASCII tail) instead of ~80 literal symbols.
- Pair-packing kept as the fallback for short scripts (encoder picks
whichever body is shorter); ▲ strings from v7.7 still decode via the
kept legacy tables; still lossless for ANY text (verified: 101-preset
corpus + 21 edge cases incl. CRLF, Hangul/CJK literals, lone
surrogates, platform-injected zero-widths), still copy-safe, still
self-checking (8 FNV check digits).
- Base packing gated at 16K symbols (O(n²) BigInt); encode 1.1 ms on the
largest preset. Decode input capped at 40K chars.
Corpus measure: 64854 → 18026 chars = 72.2% reduction (v7.7: 49.1%);
median share string 26.9% of source, best 21.9%. Bass Bloom: 1341 → 326.
Browser-verified: encode→copy→paste→decode→load round-trip through the
dialogs for both ▼ and legacy ▲ strings, What's New 7.8 entry, mobile +
desktop layout, sticky footer.
698fc1c2a3