Skip to content

Zero Knowledge Patch Generation and Forensic Evidence

Jump to bottom
atom edited this page Sep 3, 2026 · 1 revision

Proof of Zero Prior-Work Knowledge and Forensic Evidence

This is specialist reproducibility/forensic material, not required reading for ordinary FWG use. It asks whether a procedurally generated result can provide evidence of an independent computational origin.

Short answer: FWG can make a strong, independently testable statement about the inputs and deterministic computation that produced a disclosed generator-only result. It can show that a compatible archived executable plus the disclosed seed/settings reproduce that output and that the audited generation path has no documented input for a specified earlier work. That is useful technical evidence. It is not a signature, trusted timestamp, proof of authorship, proof of historical execution, or legal conclusion.

For ordinary seed use, start with Randomisation and Seeds. For the exact named-draw/hash contract, see Deterministic Randomisation — Technical Reference.

On this page

Disclaimer

⚠️ This is speculative technical commentary, not legal advice. It assumes no jurisdiction and does not predict how a court, tribunal, expert, insurer, platform, or other decision-maker would treat the evidence.

FWG records reproducible technical facts. Lawyers and other specialists can argue about what those facts mean in a particular dispute.

Scope of the claims

Five claims are easy to blur together:

Claim What FWG can support What FWG does not supply
Algorithmic input exclusion Source inspection can show that the identified generator-only code path has no documented input for a specified earlier work or derived features. Proof that an untrusted browser, modified executable, extension, operating system, or external tool did not add another path.
Deterministic reproducibility A compatible implementation can recompute named draws, reconstruct the disclosed patch, and render the disclosed FWG source output. Universal bit-identical behaviour across every browser, processor, future version, or downstream audio tool.
Historical provenance External records can corroborate that the recipe and output existed at a relevant time. A signature, trusted timestamp, author identity, remote attestation, or proof that this was the historical creation route.
Search difficulty Exact, narrowly specified mapped constraints can make blind seed search impractical. A universal security level for broad similarity, perceptual resemblance, alternative patches, or user-chosen weak seeds.
Legal significance The record can provide facts for a legal or expert argument. A legal conclusion, presumption, burden shift, or jurisdiction-independent rule.

Scope note: The easiest way to defeat an overstated historical or legal claim is usually not to break SHA-256. It is to challenge the input boundary, substitute the executable or output, fabricate the record, rely on later edits, or dispute provenance. Those attacks do not refute the narrower forward-verification fact that a disclosed seed and archived build generate a particular source-blind output. External audition or selection may affect what can be said about the curator's knowledge or legal intent without retroactively becoming an input to the generator computation.

Why this question arises

Music-related copyright disputes may concern two different things:

  • the sound recording: the particular recorded performance or master, including an allegation that audio was sampled or copied; and
  • the musical work or composition embodied in it: such as melody, rhythm, harmony, or a recognisable riff.

Those categories, their boundaries, and the legal tests applied to them vary by jurisdiction. The narrower technical question addressed here is whether an earlier recording, composition, derivative, or information extracted from them was used as a source for the disputed sound or sequence.

A randomly generated FWG patch may produce both a particular recorded sound and a repeating musical phrase. A reproducible generation record may therefore be relevant to an allegation about copied recorded audio, copied musical content, or both. It does not decide the legal dispute; it records a possible independent computational origin for the material being compared.

The coined phrase proof of zero knowledge is the organising idea for this page. It is intentionally memorable rather than formally cryptographic: the phrase names a reproducible evidential argument that the generating computation had zero knowledge of a specified prior work.

Why call it “proof of zero knowledge”?

The phrase is deliberately coined here as both a play on the established cryptographic term zero-knowledge proof and a conceptual inversion of it.

A formal zero-knowledge proof allows one party to prove possession of some knowledge or secret without revealing that secret. Loosely, it is a proof with zero disclosed knowledge.

FWG’s qualifying random-generation record does almost the opposite. It reveals the seed, versioned algorithm/planner identity, resolved patch settings, render settings, and compact generation context. Detailed named-draw traces remain available to controlled diagnostic/audit instrumentation rather than being repeated in ordinary current sidecars. The recipe is disclosed so that anyone can reproduce FWG’s output, inspect every input to that reproducible computation, and compare the regenerated output with an allegedly copied work.

Within a fully random, generator-only FWG computation, that disclosure can provide a precise, inspectable account showing that the identified code path was supplied no earlier recording, machine-readable composition, derivative material, extracted features, or resynthesis data. Subject to the exact executable and input boundary being trusted, the inspected path exposes no documented input channel through which those materials could influence that computation.*

Scope note: “Demonstrate with mathematical precision that [the prior work] was not used” is broader than the code-level evidence unless the complete execution environment and historical inputs are also established. The defensible claim is absence from the audited computation’s disclosed input boundary, not omniscience about everything a person or machine may have done.

This Wiki uses proof of zero knowledge for that opposite evidential pattern: not proof that the generator possesses hidden knowledge, but proof that specified prior-work knowledge was absent from the reproducible computation. The more precise expanded term is proof of zero prior-work knowledge.

This is project-specific wordplay, not a cryptographic claim, algorithm, protocol, zero-knowledge proof system, signature, or trusted timestamp. The claim concerns the knowledge available to the reproducible FWG computation. It does not cover everything a human producer may have heard, remembered, selected, edited, arranged, or processed later, or everything that may subsequently be done with FWG’s output.

An informal summary is:

The generator heard nothing, saw nothing, and knew nothing about the prior work.

In one sentence: a zero-knowledge proof conceals the knowledge used by a prover, while FWG’s proof of zero knowledge discloses the complete reproducible recipe to show that specified prior-work knowledge was not available to the generator.

*This claim is bounded by the reproducible FWG computation. It applies only to features attributable to that output-generation process. Drawn or other user-supplied waveform data, later manual changes, manually selected Morph/render behaviour, downstream processing, or external target-guided selection may fall partly or wholly outside that proof. Once FWG’s output has been exported, later arrangement, processing, sampling, performance, combination with other material, or other use is not automatically covered by the original generation record.

What counts as a qualifying record?

The strongest form of the argument requires, at minimum:

  • the exact executable bytes or a trusted public release hash identifying them;
  • the complete sidecar and effective render context;
  • where exact historical PCM reproduction matters, available browser/engine and runtime-version context;
  • a generator-only path with no Drawn/imported/user-supplied source material relevant to the disputed feature;
  • the random-origin snapshot and any recorded later field differences;
  • a clear account of which settings were random and which were manually fixed;
  • a regenerated output that matches the disclosed FWG source under the supported implementation; and
  • external provenance if the argument concerns when or how the material was historically created.

Even that record cannot prove a universal negative about external target-guided auditioning or selection. It can show what FWG received and did; it cannot inspect every reason a human selected one output rather than another.

The four auditable facts

For a qualifying fully random patch, the technical argument rests on four related facts.

1. This is not AI

FWG randomisation is deterministic procedural synthesis. More precisely, it does not use machine learning, a trained generative model, or a corpus of prior works. That is an auditable property of the implementation and its input boundary.

It does not use:

  • a trained model;
  • model weights, embeddings, or a latent space;
  • a training corpus or database of recordings;
  • retrieval from a body of prior works;
  • prompt-to-audio generation; or
  • a learned representation from which memorised material could leak.

The algorithm has only its published synthesis rules, the supplied seed and settings, and any explicit user-supplied data used by the patch. It has no body of music to draw upon, imitate, interpolate between, recall, or accidentally reproduce from memory.

This distinction matters because debates about trained generative systems often concern what entered a training set, what a model may have memorised, and whether prior material can leak into an output. Those mechanisms do not exist in FWG. The relevant qualification is instead much simpler and inspectable: whether Drawn or other user-supplied data, later manual changes, or an external target-guided selection process materially contributed to the disputed feature.

Scope note: “This is not AI” is a useful headline but not a stable technical category. The auditable claim is narrower: FWG uses no machine-learning model, learned parameters, training corpus, retrieval corpus, embeddings, or learned representation in the identified generation path.

2. Auditable input exclusion

For the identified generator-only code path, the earlier work and its derivatives are absent from the disclosed algorithmic inputs.

Scope note: “Provably unavailable” is safe only after defining the proof boundary: exact code, exact path, exact inputs, and trusted execution assumptions. “Auditable input exclusion” is less rhetorically strong and technically harder to misread.

The inspected generator path receives the seed, versioned rules, current FWG state, and render configuration. It does not receive:

  • an earlier recording;
  • an earlier composition in machine-readable form;
  • a sample or copy derived from either;
  • extracted notes, rhythm, timing, spectrum, features, or resynthesis data;
  • a trained model or corpus that could contain the work.

The source code and exported record can be inspected to determine what the reproducible computation did and did not receive.

3. Reproducibility

The disclosed seed, application version, named-draw algorithm, resolved patch settings, and render settings can reproduce the FWG output recorded by that evidence. If the output was later used or transformed elsewhere, the reconstructed FWG source can be compared with that later material, but the later work is not itself reproduced by the FWG record.

A matching WAV and JSON can allow another person to:

  1. identify the FWG version;
  2. inspect the seed, named-draw model, and per-file trace where present;
  3. reconstruct the START and END endpoint patches;
  4. reconstruct Morph and render settings;
  5. render the output again; and
  6. compare the regenerated audio with the source WAV used in the later work.

For Bulk Random, one per-file JSON normally provides the clearest record because the random planning, resolved patch, and render state are captured together.

4. Conditional search infeasibility

Verification and construction are asymmetric. Given a seed and complete recipe, it is straightforward to recompute the named draws and test whether the publicly archived FWG build produces the disclosed source output. Working in the opposite direction - starting with an already fixed target output and searching for a seed that satisfies it - can become practically infeasible when only a vanishingly small fraction of the searched seed distribution is acceptable.

That asymmetry is the central forensic proposition. Starting from a seed, generation is trivial. Starting from a sufficiently constrained output, constructing and disclosing a seed that makes the archived generator reproduce it is an inverse search problem. A person attempting to invent an FWG explanation after a disputed recording has been fixed does not gain a shortcut merely because the forward algorithm is public. Public disclosure makes verification easier; it does not make inversion easier.

A signature or trusted timestamp would answer a different question: whether a particular record demonstrably existed at a particular time. Current JSON already records created_utc, which is useful contextual evidence but not independently certified. The computational resistance to post-hoc seed construction comes from the target predicate and seed-to-output mapping, not from timestamp secrecy. Provenance still matters where the history, identity, substitution of files, or exact creation route is disputed.

Appending a compact timestamp to automatically generated seed text has been considered but not adopted. Such a suffix could hedge against a catastrophically repeating RNG and would bind the claimed seed-generation time into the deterministic output: changing the timestamp characters would change the draws. That could substantiate, but not prove, time. The clock could be wrong, the complete seed remains user-editable, multiple seeds may be generated at different times, and a batch can render outputs over minutes. An impossible date would undermine the claim; a plausible date would still need corroboration. The current decision is to retain the plain 130-bit generated token and keep created_utc as the file-level creation field.

A concrete opposing allegation might be: you deliberately chose this seed in order to reproduce my client's work. Forward reproduction does not logically prove that the seed was selected innocently. It does, however, make the allegation technically testable. The critic must explain a plausible route from the already fixed target to a satisfying seed and qualifying random trace. For an exact or tightly bounded target, the absence of a practical inverse method is substantive evidence against post-hoc construction; for a broad resemblance accepted by many outputs, the argument is correspondingly weaker.

For an acceptance predicate satisfied by a fraction α of candidate seeds, an unstructured blind search takes about 1/α trials on average. That statement is useful only when α is defined or bounded. A list of trace decisions does not automatically prove it, because decisions can be conditional, correlated through one seed, inactive, rewritten, many-to-one, or irrelevant to the accepted audio.

Scope note: “Many specific, separately addressed outcomes must all match” suggests multiplying independent probabilities. Separate addressing does not prove independence, and matching the final audio may not require matching every trace entry. Any numerical work-factor claim needs an explicit acceptance predicate and dependency analysis.

A candidate seed may need to reproduce the same:

  • engine family and variant;
  • control values;
  • taps and routing;
  • modulation state;
  • source and result windows;
  • Wavetable Type;
  • filter state;
  • START and END relationship;
  • Morph Render Mode;
  • FFT anchors, curve, or cycle stepping;
  • timing and render behaviour;
  • other audible details fixed by named random draws.

As the number and specificity of separately addressed outcomes that must all match increase, each additional requirement removes most of the remaining candidate seeds.

For arbitrary exact constraints on mapped named outcomes, no practical classical shortcut is known that predicts satisfying seeds without evaluating candidate hashes. Search implementations can parallelise, reject candidates early, reorder cheap constraints, exploit repeated planner structure, or admit a broad acceptance criterion. Those efficiencies may change the cost by enormous factors, but they do not presently provide a useful gradient through SHA-256 toward an arbitrary exact vector of retained outputs.

Blind search cannot require more candidate evaluations than the finite seed space being enumerated, while its expected cost can be far smaller where the acceptance set is broad. It may also be far less than 2^130 where the seed was human-chosen from a weak distribution or where alternative patches and later processing satisfy the target.

SHA-256 does not prove that no faster search method could ever exist. Broad similarity targets, equivalent renderings, weak or deliberately restricted user-chosen seeds, exploitable planner structure, implementation defects, future cryptanalytic discoveries, or quantum search could reduce the work required. In an ideal unstructured-search model, Grover’s algorithm would reduce a unique-target search over 2^130 candidates to the order of 2^65 coherent oracle evaluations; implementing the complete planner and acceptance test reversibly would add substantial practical cost, but the quadratic reduction must still be acknowledged. More generally, an acceptance fraction α gives ideal quantum query complexity on the order of 1/√α. The narrower classical claim is that the public seed-to-draw mapping exposes no known practical gradient or inversion shortcut for an arbitrary exact target.

Scope note: Do not call 2^130 a post-quantum security level. FWG has no formal security target, and a realistic quantum resource estimate for its complete acceptance predicate has not been performed.

The static analogy

A finite random source can produce any finite output that lies in its support. A suitably sampled and quantised noise process could, with fantastically small probability, encode an image resembling the Mona Lisa or audio resembling an act of Hamlet.

Scope note: Physical “static” is not automatically an ideal uniform generator over all finite files. The analogy is about possibility within a defined support, not a claim about the distribution of real television or radio noise.

FWG itself can produce outputs ranging from effectively inaudible or collapsed signals to dense noise that may be essentially indistinguishable from radio static. Those extremes do not define everything between them. Between near-silence and apparent randomness lies a large space of tonal, rhythmic, evolving, unstable, and emergent structures whose practical limits remain to be discovered.

The relevant question is not whether an extraordinary coincidence is mathematically possible. It is whether it is remotely plausible or practically discoverable. FWG may produce unexpectedly recognisable sounds or musical structures, while deliberately locating a particular sufficiently detailed target within its random search space can remain computationally infeasible.

The same distinction applies to alternative recipes. More than one seed or mathematical construction may theoretically produce the same output. But where many specific random decisions must all agree, finding any alternative seed that deliberately reproduces the complete result can require an infeasible search.

Default seed space

Default generated seeds select 26 symbols from a 32-symbol alphabet:

32^26 = 2^130

1,361,129,467,683,753,853,853,498,429,727,072,845,824 possible default tokens.

One duodecillion, three hundred and sixty-one undecillion, one hundred and twenty-nine decillion, four hundred and sixty-seven nonillion, six hundred and eighty-three octillion, seven hundred and fifty-three septillion, eight hundred and fifty-three sextillion, eight hundred and fifty-three quintillion, four hundred and ninety-eight quadrillion, four hundred and twenty-nine trillion, seven hundred and twenty-seven billion…

In short, the default token namespace contains approximately 1.36 duodecillion possible values. “130 bits” is compact and mathematically useful, but “more than one duodecillion possible default seeds” better conveys the physical scale: it is not merely a very large playlist or a lifetime of auditioning, but a search space beyond exhaustive practical exploration.

Even a machine testing one billion seeds every second, without interruption and with an unrealistically cheap exact acceptance test, would need about 43 sextillion years to enumerate the entire 2^130 namespace. That is roughly 3.1 trillion times the age of the universe. This comparison is illustrative rather than a performance claim about FWG rendering, which is vastly slower than one billion complete patches per second.

Scope note: Exhaustive enumeration is not the same as expected time to find any acceptable seed. A unique uniformly random target would be found after half the space on average; a broad target could be found much sooner. The one-billion-tests-per-second figure is deliberately hypothetical and should not be presented as benchmark evidence.

The code maps one browser-generated byte to each symbol by taking its low five bits. Because 256 is exactly divisible by 32, that symbol mapping is unbiased if the browser supplies uniform bytes as intended by the Web Crypto API. The specification describes getRandomValues() as cryptographically strong but sets no lower bound on information-theoretic entropy. The 2^130 figure is therefore a token-namespace size and an intended generated-uncertainty figure under the browser-RNG assumption, not an attestation of the physical entropy inside every device.

Random-source weakness mainly affects honest sampling, uniqueness, and the amount of uncertainty attributable to a newly generated token. It is not the main defence against post-hoc target construction, because an attacker may choose candidate seeds directly. Even a biased generator can still produce deterministic SHA-256-derived draws, but hashing cannot create missing entropy and a severely restricted seed distribution would reduce the space actually sampled.

For uniformly generated 130-bit tokens, the birthday probability of any duplicate is approximately n(n-1) / 2^131 while the probability is small. That is about 3.7 × 10^-28 after one million generated seeds, 3.7 × 10^-22 after one billion, and 3.7 × 10^-16 after one trillion. The 50% point is roughly 4.34 × 10^19 generated seeds.

A consequential musical collision requires much more than a duplicate token. The same application version and other effective inputs must align; both results must be auditioned and selected; both must enter recorded works; both works must be distributed to overlapping audiences; the shared element must be noticed; and the issue must matter enough to justify a dispute and potentially the expense of lawyers. If two producers genuinely reach the same complete seed and effective recipe independently, both computational routes may still be source-blind. FWG cannot decide priority, ownership, publication history, or the legal significance of the resemblance.

A defective RNG could make duplicate tokens more likely. The defect would need to be much more serious than ordinary bias before repeated complete 130-bit strings became routine. A broad failure of a system cryptographic RNG could create problems far beyond FWG, although a defect in the JavaScript-facing API would not by itself prove that the browser's TLS stack uses the same implementation path. For FWG, duplication is an accidental-uniqueness and priority problem rather than a secret-key catastrophe or a method for steering the generator toward a preselected target.

Demonstrating that a disclosed seed and recipe reproduce a complete patch is easy to test. That verifies internal consistency; it does not by itself prove when the record was made, who made it, or that no alternative workflow was used. It also does not provide a known shortcut for calculating the seed from a sufficiently constrained target.

A generic exact search evaluates candidate seeds and rejects them when their named outcomes differ. Candidates can be tested in parallel and rejected after the first failed constraint, but no known method uses a near miss to move gradually toward the required SHA-256 outcomes. For a sufficiently detailed patch whose effective requirements exceed the seed-space size, the 2^130 default-token namespace becomes the limiting exact-search space.

A larger informal pre-release development study also exercised controlled Classic and Absurd batches using the deterministic engine/model that became the v3 contract. The retained development evidence included the tested source archives and analysis material, so the measurements were reproducible from the preserved test corpus.

The useful public conclusion is qualitative rather than a new security claim:

  • Classic deliberately fixed most of the signal path and varied a relatively narrow set of generator/Morph decisions. Its recorded traces therefore represented a comparatively small construction space.
  • Absurd ranged across much broader endpoint and Morph domains and produced substantially larger recorded decision traces.
  • The selected-outcome descriptions in those traces could exceed the 130-bit default seed namespace because many mapped decisions are deterministic functions of the same seed. That larger description does not create extra independent random entropy.
  • Some recorded decisions can be inactive, masked, overridden, or perceptually irrelevant in the final render, so raw trace size must not be equated with audible uniqueness or target-search difficulty.

The pre-release study was useful engineering evidence that the planner was exploring the intended narrow-versus-broad regimes and that the named-draw records could be analysed reproducibly. It was not a randomness certification, cryptanalytic experiment, population survey of all FWG outputs, or legal probability calculation. Detailed development-corpus statistics belong with the internal test/archive material rather than this user-facing technical manual.

Are Classic and Absurd lower and upper bounds?

They are best understood as lower and upper design anchors, not as proven universal entropy bounds for the whole preset ladder. Classic fixes almost the entire signal path and randomises a narrow set of generator and Morph decisions. Absurd independently draws across the complete public endpoint domains and all public Morph families. In directly randomised final-parameter breadth, they are intentionally near opposite ends of the current Bulk Random design.

That does not prove that Classic always produces the lowest trace total or Absurd always produces the highest. Fixed versus random Morph selection, FFT anchor policy, conditional source branches, correction draws, and other preset-specific planning can change the trace. A curated planner may record more internal decisions without creating more final-patch or audible variation. Establishing bounds for every preset would require comparable Cycle-coherent, Smooth, Edge, Glitch & Noise, and Unrestricted samples under identical settings, or analytical enumeration of each planner.

For the two current planners under the exact sampled setup - one selected pool and random Morph selection per file - source inspection does give narrower trace-metric bounds:

Classic core: 10–15 draws; approximately 42.90–83.41 idealised trace bits
Absurd v1:    43–54 draws; approximately 237.52–331.88 idealised trace bits

The observed larger-pool ranges fall inside those bounds. These remain bounds on a planner trace-description metric under specified settings - not bounds on independent seed entropy, complete-patch entropy, rendered-WAV entropy, subjective musical variation, or every FWG workflow.

As a scale reference, a patch space containing 2^69 candidates contains 590,295,810,358,705,651,712 possibilities. Rendering one three-second WAV for every candidate, all at one fixed pitch, sample rate, direction, duration, and other render settings, would produce about 1.77 sextillion seconds, or more than 56 trillion years, of audio. That is more than 4,000 times the age of the universe, which is about 13.8 billion years. The 2^69 reference is close to the centre of the tested Classic traces, not a universal Classic value or an entropy bound for the output. Many broader FWG configurations have substantially larger trace-description spaces, and changing the render variables expands the practical search problem further.

What the bit counts do and do not mean

Three prominent bit counts describe different parts of FWG’s randomisation:

  • 130 bits describes the namespace of one default generated token: 26 symbols from a 32-symbol alphabet. It is the intended generated uncertainty only under the browser-RNG assumption.
  • 256 bits is the size of a SHA-256 digest produced for one named path.
  • 32 bits per draw is the portion of that digest FWG actually maps into one integer, choice, probability result, weighted result, or unit float. One path therefore has only 2^32 raw results, and path-level collisions - different seeds producing the same retained 32-bit value for the same path - are ordinary rather than evidence of a flaw.

None of those numbers, individually, defines the entropy of a particular rendered WAV or a universal upper or lower bound for any complete patch.

For one fixed planner, fixed non-random inputs, and one generated default token, the independently supplied random uncertainty cannot exceed the uncertainty in that token, with 130 bits being the intended default under the browser-RNG assumption. SHA-256 can deterministically expand that seed into many named draws, and the resulting list of selected settings may require far more than 130 bits to describe independently. That larger description does not create extra independent randomness; it means the seed selects a sparse subset of a larger theoretical decision space.

That 130-bit figure describes one generated default seed, not the allowed size of every user-supplied seed. Current FWG accepts committed user seeds up to 128 UTF-8 bytes, with a single character as the shortest ordinary user-entered value. The hash core can process a literal empty string, although committing an empty or whitespace-only value in the normal UI requests a fresh default seed instead. Seed-string length is also not the same as entropy: a known or deliberately chosen seed may provide little or no uncertainty regardless of how many characters it contains.

FWG does not apply Unicode normalisation to user-entered seeds. Visually identical text can have different underlying Unicode representations and therefore produce different deterministic draws. Exact reproduction requires the exact stored seed string, not merely text that looks the same on screen.

The effective result can also contain much less than 130 bits of distinguishable variation. Different seeds may converge on the same settings or audio; controls may be inactive, rounded, clamped, overridden, or inaudible; and a conservative planner may expose a much smaller effective result space.

Conversely, a complete patch assembled from multiple independently generated random components may have more than 130 bits of independent input uncertainty. For example, separately randomised START and END endpoint patches can carry separate random origins. That conclusion requires the origins to have been generated independently; two stored seed strings can be equal, correlated, copied, or deliberately chosen. The relevant accounting depends on the actual generation process, not on one number printed beside the hash function or seed generator.

Mathematical bits are equal as units of information, but their audible consequences are not. One random bit that selects silence versus noise, or one engine family versus another, may change the result far more than several bits spent choosing an inactive control, a fine numerical increment, or a detail masked by later processing. Therefore:

  • seed entropy;
  • theoretical planner information;
  • exact-patch match difficulty;
  • rendered-audio distinguishability; and
  • subjective musical variation

must not be treated as interchangeable quantities.

Mapping precision and the accepted modulo bias

FWG maps one unsigned 32-bit value into each integer range or ordinary pool choice. Direct modulo reduction is exactly uniform when the range size divides 2^32; otherwise some outcomes receive one additional 32-bit source value.

For any one outcome, the absolute probability error is less than 2^-32, about one part in 4.3 billion of absolute probability. That phrase needs care: for a very large range, the relative difference between rare buckets and the total distance from a perfectly uniform distribution can be larger. The largest current public integer range, 2,400,000 Pitch Offset magnitudes in hundredths of a cent, has a maximum per-bucket relative deviation of about 0.0318% and a total variation distance of about 0.0137%.

The direct modulo mapper is fit for purpose. Rejection sampling would remove the mathematically measurable bias, but even under extraordinary use it would provide no measurable musical or workflow benefit. It would require a versioned retry rule, could consume additional digest-derived values, and would change deterministic outputs. Any such change would require a new draw-model identifier.

Scope note: “Fit for purpose” is well supported for exploratory sound design by the quantified bias, but it is application-specific. Do not generalise this acceptance to security, gambling, scientific sampling, or any system where exact distributional guarantees are part of the contract.

Chance and weighted choices are likewise quantised to a 2^32 probability grid. The trace studies use idealised probabilities and should not be read as exact cryptographic entropy calculations.

Retaining only the first 32 digest bits is an engineering choice, not a security claim. A 32-bit unsigned value is represented exactly by ordinary JavaScript number arithmetic, maps directly into FWG’s current integer ranges and probability grid, and provides far finer raw-result granularity than any current musical control can use. The browser still computes the complete SHA-256 digest. Mapping more digest bits would reduce the already immaterial modulo bias and path-level collision rate, but would provide no measurable musical or workflow benefit and would redefine the public draw model.

See Deterministic Randomisation — Technical Reference for the exact mapping formulas and representative ranges.

Why SHA-256 when each draw retains only 32 bits?

SHA-1 already produces more than the 32 bits FWG needs for one named draw. Its published collision weaknesses are also not the same problem as finding one seed that satisfies a complete vector of mapped outcomes across many fixed named paths.

Switching to SHA-256 therefore does not give each draw 256 bits of variation, increase the 130-bit default seed space, or remove the 32-bit raw-result granularity of one mapped draw.

FWG chose SHA-256 for its first public named-draw contract because:

  • it avoids a distracting argument based only on the headline that “SHA-1 is broken”;
  • it is a current, widely reviewed standard primitive;
  • no practical weakness is known that is relevant to this deterministic named-draw use;
  • its browser implementation cost is essentially the same as SHA-1; and
  • it provides a cleaner long-term public contract without pretending FWG is a security application.

The pre-public prototype used SHA-1, but no public FWG release established SHA-1 named-draw compatibility. Choosing SHA-256 before publication primarily improves the quality, durability, and explainability of the first public contract. It does not turn FWG into an authentication, secrecy, signature, password, or formal proof system.

A sound and a riff

A random patch can determine more than timbre. Depending on its periodic motion, modulation, windows, Morph behaviour, direction, duration, and other render settings, it can also produce a repeating phrase or riff.

The same technical record can therefore reproduce and document a procedural account of:

  • the particular FWG-rendered source sound; and
  • a musical sequence or riff produced by that patch.

Scope note: A generator-only seed and archived build that exactly regenerate the disputed FWG source demonstrate an independent computational route: the disclosed algorithm can account for the sound or sequence without receiving the earlier work as input. The sidecar alone does not establish that this route was historically used first, that files were not substituted, or that a human later selected the result because of a recognised similarity. Those are provenance and legal-significance questions, not failures of the source-blind generation account.

Whether that distinction establishes legal independent creation is outside FWG's scope and may vary by jurisdiction. In United States Copyright Office guidance, independent creation means creating a work without copying; musical works and sound recordings are also treated as separate protected works. FWG supplies technical evidence relevant to derivation, but it does not decide whether a similarity concerns protectable musical expression, a particular recording, an unprotectable or commonplace sound, or some other right. Sound trademarks are a separate category: THX publicly identifies the Deep Note audio mark as a registered trademark, which should not be confused with general copyright ownership of every acoustically similar sound.

Random origin and later edits

A patch can begin randomly and later be edited.

The useful factual comparison is:

generated random baseline
versus
final exported patch

For endpoint random-origin records, the generated snapshot and final endpoint values can show which recorded fields differ.

This does not answer:

  • who made the change;
  • why it was made;
  • whether the change was influenced by another work;
  • whether the change materially caused a disputed similarity;
  • what significance anyone should assign to it.

The complete final patch in JSON remains authoritative for reproduction.

Qualification: what remains attributable to the random process

The claim of zero prior-work knowledge applies to the extent that the disputed features remain attributable to the reproducible FWG computation.

Its strength may be reduced where:

  • the patch incorporates Drawn or other user-supplied waveform data derived from the allegedly copied material;
  • randomised settings are subsequently edited by hand;
  • manually selected Morph or render settings materially create the disputed feature;
  • later processing, arrangement, performance, resampling, or editing materially contributes to the disputed result; or
  • an external target-matching process analyses the earlier work and uses it to search or select generated outputs.

None of those circumstances automatically establishes copying. A target-aware selection step does not retroactively put the target into FWG's generator inputs, so the original record can still establish a source-blind computational origin for the generated material. What it cannot establish by itself is why that material was selected, whether later intervention materially caused the disputed similarity, or what legal significance follows from knowingly adopting a resemblance.

Drawn waveform boundary

Drawn may be:

  • hand-drawn;
  • imported from a file;
  • copied from Input 1; or
  • edited after it was populated.

FWG may preserve one most-recent initialisation record:

initialised_from_file

or:

initialised_from_input_1

A newer file import or Input 1 copy replaces the older record. Reset to Sine clears it. Later drawing does not alter the record.

This metadata describes how Drawn was most recently populated, not how it was later edited, and it is separate from waveform authority. While a pristine construction/transform/normalise pipeline is retained, that pipeline is the saved authority and its bounded 512-sample table is runtime materialisation; after editing/flattening, the literal Drawn table is authoritative. An exact untouched built-in sine with no retained construction may use the compact built-in representation.

A filename is useful context but is not proof of file identity. When Input 1 is copied into Drawn, FWG records the generator family, variant, Pot1–Pot3 values, and tap used at that moment.

Auditioning and target-guided search

Music producers normally audition multiple sounds before choosing one.

Ordinary auditioning does not make an earlier recording a computational input to FWG. If a producer auditions one thousand source-blind outputs and chooses one that happens to resemble a familiar recording, the chosen FWG material was still generated from its seed without that recording being supplied to the generator. The selection may be informed by recognition, and lawyers may dispute the significance of that choice, but the computational origin does not become sample-derived after the fact.

Ordinary auditioning is also not a practical way to search a meaningful portion of a 130-bit seed space.

At three seconds per patch, uninterrupted listening would require approximately:

1,000 patches      50 minutes
10,000 patches     8.3 hours
100,000 patches    3.5 days
1,000,000 patches  34.7 days

Those figures exclude loading, replaying, comparing, fatigue, sleeping, eating, making notes, saving candidates, and making music.

Even one million auditions would examine only approximately:

0.00000000000017% of a 2^69 search space
0.000000000000000000000000000000073% of a 2^130 search space

Put differently, after auditioning one million patches, essentially every candidate in either search space would still remain unheard. For the 2^130 default-token namespace, the examined fraction is so small that writing it as a percentage requires thirty-one zeroes after the decimal point before the first non-zero digit.

Scope note: This fraction describes coverage of a uniform token namespace, not the probability of independently creating a broad musical resemblance. Human audition is target-aware, outputs are not perceptually uniform, and an acceptance set can contain many seeds. Use this comparison only to rebut claims of exhaustive manual exploration.

Those proportions also assume one fixed rendering of each candidate: three seconds at one frequency, direction, sample rate, and set of render conditions. FWG can produce materially different audible results when the same underlying patch is rendered at different frequencies, durations or cycle counts, directions, sample rates, Morph settings, and other relevant variables. Searching one million three-second WAV files under one render configuration therefore examines an even smaller portion of the practically available output space.

A separate automated system that analysed a target work and searched generated outputs for similarity would be different. In that larger pipeline, the earlier work or features derived from it would be an input to the external search-and-selection process, even though FWG's oscillator engine still did not sample it. The technical claim should then be split cleanly: source-blind generation remains true of FWG, while source blindness is false of the complete target-guided pipeline.

The JSON alone cannot prove that no external selection process was used. It can show what FWG itself received, how its output is reconstructed, and whether the disclosed generator route excluded prior-work inputs. It cannot determine the curator's reasons for choosing that result.

Reproducibility is not self-authentication

A technically consistent WAV/JSON pair can be created, copied, or edited after the event. FWG does not sign sidecars, authenticate users, seal the browser environment, or obtain a trusted timestamp. A malicious person who already has a constructible FWG patch can also write a record that reproduces it.

That observation must not erase the forward/inverse asymmetry. If the disputed target output was fixed independently of FWG, fabricating a convincing generator-only explanation requires finding some seed, version, fixed settings, and permitted recipe that make the publicly archived method reproduce the accepted target. For a narrowly specified exact target, that is the hard construction problem discussed above. Editing JSON is easy; calculating a seed that makes edited JSON regenerate an already fixed arbitrary output is not.

This does not eliminate evidentiary attacks. A person might substitute the target WAV, broaden the acceptance criterion, rely heavily on manual non-random settings, exploit an equivalent-output route, or dispute which file was historically used. Timestamps and chain of custody address those historical and substitution questions. They are not the source of the seed-inversion difficulty.

Reproduction therefore establishes a narrower and still useful fact: the disclosed recipe is sufficient to generate the disclosed FWG output under the identified archived implementation. It demonstrates an available independent computational route; external provenance determines how strongly that route can be identified with the historical creation event.

The evidential value is stronger when the reproducible record is supported by ordinary provenance, such as:

  • contemporaneous project files and DAW sessions;
  • version-control history;
  • backups or transfers made before a dispute;
  • publication or third-party receipt;
  • trusted release hashes; and
  • a documented chain of custody.

This distinction is especially important because a cryptographic hash can verify bytes against a known reference but cannot, by itself, authenticate the author, creation date, or historical execution of those bytes.

For ordinary users, contemporaneous cloud-storage/version history, project files, backups, transfers, correspondence, publication, and similar records will usually be the practical provenance layer. More specialised users can independently sign or externally timestamp the final FWG artifacts. That optional crypto/forensic workflow is documented separately in Authenticating and Timestamping FWG Outputs; it is deliberately not part of FWG's generation or reproduction contract.

WAV/JSON linkage

FWG WAV metadata can preserve:

  • the application version;
  • the original WAV basename;
  • the corresponding JSON filename; and
  • a shared export ID.

This link survives an ordinary external rename of the WAV.

The filename may contain a time-derived run token, but it is not an independently certified timestamp. Its usefulness is stronger when corroborated by ordinary production records such as DAW sessions, backups, source-control history, published files, transfers, or dated archives.

The canonical SHA-256 hash of the uncompressed FWG HTML can identify the exact executable bytes used for reconstruction when compared with a trusted expected hash. The hash is an integrity identifier, not a signature, certificate of origin, proof of execution, or timestamp. Public release hashes may be recorded in the changelog.

What the record can reasonably establish

This is the practical core of FWG’s coined proof of zero knowledge: a transparent, reproducible record can show what the generator knew, what it did not receive, and how its output was produced.

For a fully random, generator-only and unedited construction, the record can provide:

  • a reproducible recipe for the FWG-generated source output under the identified compatible implementation;
  • code-level evidence that an earlier work and derived features were absent from the audited generator path’s disclosed inputs;
  • an audit trail of the recorded seed-derived decisions;
  • evidence consistent with procedural synthesis rather than sample import within that path; and
  • a basis for estimating the difficulty of a precisely defined seed-search target.

Scope note: None of these items is self-authenticating. “Complete,” “provable,” and “computationally infeasible” each require a stated implementation, input boundary, acceptance predicate, and provenance model.

For mixed or later-edited work, those statements apply only to the portions still attributable to the disclosed source-blind generation process.

What it does not establish automatically

A sceptical review should actively test whether any excluded claim has slipped back into the positive language above.

Do not infer from the record alone that:

  • every seed produces unique audio;
  • every audible feature contains 130 bits of randomness;
  • no producer had ever heard another work;
  • no external target-guided selection occurred;
  • no later edit was influenced by another work;
  • generated audio can never infringe any right;
  • the embedded run token is a certified timestamp;
  • the JSON or any separately captured named-draw trace is signed, tamper-evident, or historically self-authenticating;
  • the build hash proves who ran the software or when it ran;
  • FWG provides a formal cryptographic zero-knowledge proof; or
  • any particular court or jurisdiction must accept a particular interpretation.

How a sceptic should try to break the argument

A serious review should attempt at least these attacks, while keeping constructive inversion separate from historical/evidentiary substitution:

  1. Executable substitution: Can a modified HTML produce the same-looking sidecar while accepting hidden inputs?
  2. Record or output substitution: Can a JSON/WAV pair be created after the event and made internally consistent by replacing the disputed output, rather than by finding a seed for the already fixed target? External provenance is relevant to that historical attack.
  3. Input-boundary escape: Can Drawn data, imported audio, browser state, extensions, or downstream tools introduce prior-work information outside the claimed generator-only path?
  4. Target-after-generation: Was the comparison target identified only after hearing the FWG output? That does not refute source-blind generation; it changes the question from deliberate target construction to coincidence, recognition, selection, and legal significance.
  5. External target-guided search: Did another system analyse the prior work and rank FWG outputs? If so, the prior work entered the complete selection pipeline even if it did not enter FWG's oscillator. State both facts rather than collapsing them.
  6. Weak seed distribution: Was the seed browser-generated, or chosen from a small dictionary or predictable pattern? This tests claims of generated uncertainty and uniqueness. It does not itself provide a route from arbitrary target audio back to a satisfying seed.
  7. Constraint inflation: Do quoted trace bits count inactive, conditional, overwritten, or perceptually irrelevant decisions?
  8. Equivalent-output attack: Can many different patches, cleanup settings, or downstream processes produce the accepted sound without matching the trace? This can enlarge the acceptance set and reduce search cost, but any qualifying generator-only route still demonstrates an independent computational origin.
  9. Fixed-output inversion: Starting with the disputed output rather than the seed, can the reviewer actually construct and disclose a seed/recipe that the archived build maps to the accepted target?
  10. Reproduction ambiguity: Does the record reproduce only under one browser/build, or is the claimed equivalence robust under the stated supported environment? Would browser/engine, declared ECMAScript target, Web Audio path, sample rate, platform, architecture, or dependency versions help explain a mismatch?
  11. Duplicate-seed scenario: Under the claimed RNG model, what is the birthday probability of any duplicate complete seed, and what additional events would be required before that duplicate became a consequential musical or legal dispute? If the observed duplicate rate is implausibly high, is the RNG, environment cloning, or record history defective?
  12. Timestamp confusion: Is created_utc, a filename token, file-system date, or possible timestamp-bearing seed being presented as trusted time evidence? A time value can have contextual or self-binding value without authenticating the clock. Timestamping supports history; it is not the source of inverse-search resistance.

A claim that survives these attacks is narrower than the most dramatic version of “proof,” but much more credible. The most important technical challenge remains asymmetric: producing output from a seed is easy; producing an acceptable seed from a fixed detailed output may be infeasible.

Legal speculation

Any discussion of possible copyright, evidential, or forensic use on this page is merely speculation out loud about how the technical records might be argued.

It is not legal advice. No legal jurisdiction is assumed. The applicable law, procedure, expert requirements, and significance of the evidence may differ substantially between places and disputes.

Copyright-background references

These are general or illustrative background sources, not jurisdiction-specific advice and not authority for the speculative legal commentary on this page.

Technical references

Documentation rule: The executable code is authoritative. This Wiki describes the supported Fractured Wavetable Generator v3.0 contract and workflows.

Project repository · Public hosted release

Fractured Wavetable Generator

Start here

🎹 Workspaces

🎹 Build and shape sounds

🎹 Make and keep results

🎹 Scanning and custom trajectories

Help and reference

🔧 Advanced / technical reference

Clone this wiki locally