Design — Synthesize Buckminster Fuller's Voice to Narrate His Books (TODO-6)

Date: 2026-06-28
Source: work/TODO.md → TODO-6 ("Synthesize Bucky's voice to narrate his books")
Status: Approved design; ready for implementation plan

Goal

Lay out a complete, accurate, grounded research + recipe for producing a synthetic R. Buckminster Fuller voice that can narrate his texts as audiobooks — so the project can later be executed in phases. This iteration produces documentation only; it generates no audio and makes no external API calls.

Why (from TODO-6)

Accessibility — make Fuller's texts available as audiobooks, widening reach to listeners who don't read long-form. Fuller's coined vocabulary and dense prose are a barrier; an audiobook in his own (synthetic) voice is an on-ramp.

Deliverable

A wiki project: .wiki/output/projects/fuller-voice-synthesis/

• WHY.md — project rationale, goal, scope boundaries, and success criteria (per the wiki project convention; required by lint C8a).
• recipe.md — the grounded research + recipe (the substance), structured as the six sections below.

No other files this iteration (no audio, scripts, datasets, or API calls).

Content structure of recipe.md

1. Voice-data corpus. Where Fuller's reference audio actually lives — Everything I Know (1975, ~42 hours), recorded lectures, interviews, and any holdings of the Buckminster Fuller Institute / Stanford archive. For each: approximate length, audio quality, access/licensing notes, and suitability as cloning reference (clean speech vs. lecture-hall noise). Cross-reference existing wiki sources where relevant.
2. Tooling — three options with a recommendation.
   • (a) Cloud — e.g. ElevenLabs Professional Voice Clone: easiest, high quality, paid, with vendor Terms of Service that restrict cloning real/identifiable people without permission.
   • (b) Local open-source — e.g. F5-TTS / XTTS / Tortoise: free, private, full control, needs a GPU and more setup, variable quality.
   • (c) Hybrid — iterate locally, finalize on cloud.
     A clear recommendation with reasoning (likely: local open-source for control/cost/privacy, with cloud as an optional quality finalizer).
3. Pipeline. Data prep (segment, denoise, transcribe reference audio) → voice clone / fine-tune → text prep (chunk a book into narratable units; handle Fuller's coined terms, headings, footnotes) → synthesize → post (loudness normalization, stitching, chapter markers) → QA.
4. Quality & evaluation. What "sounds like Bucky" means operationally — intelligibility, speaker similarity, prosody/pacing; a small eval rubric and a recommended A/B listening check.
5. Ethics & rights. Synthesizing a deceased person's voice: the Buckminster Fuller Institute / estate as rights-holders; the case for seeking permission; mandatory disclosure/labeling of audio as AI-synthesized; and each tool's ToS on voice cloning. A clear stance: get permission and label as synthetic.
6. Phased roadmap + cost. PoC (a few sentences) → one chapter → full book, with rough effort and cost per tooling path, and the data/compute each phase needs.

Grounding (accuracy requirement)

Before writing, verify the volatile facts with a few targeted web lookups so the recipe is current and correct rather than hand-waved:

• The actual availability/format of Fuller's recordings (esp. Everything I Know).
• The current (2026) state of the named voice-cloning tools (which are maintained, license terms, real-people-cloning policies).

Mark any claim that can't be verified as such; prefer "as of 2026, …" framing for tool facts (volatile).

Integration with the wiki

• The project lives under .wiki/output/projects/ and must satisfy lint C8a (non-empty WHY.md) and C8d (slug format: fuller-voice-synthesis, lowercase/hyphen, ≤40 chars, no dates).
• Update .wiki/output/_index.md and the master .wiki/_index.md Outputs count + Recent Changes, and append a log.md line.
• recipe.md may cite existing wiki sources (e.g. everything-i-know, the audio/lecture sources) where they exist; any such links must resolve (lint C4).

Out of scope (this iteration)

• Generating any audio, sample clips, or narrated text.
• Writing or running TTS/cloning code, or any external API calls.
• Acquiring or redistributing Fuller audio files.
  These belong to later phases the project's roadmap defines.

Verification

The repo has no automated test suite; its canonical verification is the wiki lint. Pre-merge success = /wiki:lint reports 0 broken links, 0 dangling sources, indexes consistent, the new project has a non-empty WHY.md, and the slug passes C8d.

Testing strategy

Not code, so testing = lint + self-review of the recipe for: accuracy of grounded facts, internal consistency, that the ethics section is unambiguous, and that the roadmap phases are actionable. No unit tests apply.