ECO — Essential
Suitable when a simple representation of the sound is enough.
EEV is an open format designed to capture the vibratory identity of a sound in a structured and readable way. It does not try only to say which note is being played. It aims to preserve what makes a sound truly itself: its partials, its evolution, its sustain, its density, its timbre, and its overall vibratory behaviour.
For a sound therapist, two sounds tuned to the same fundamental frequency do not necessarily vibrate in the same way. They can have a different colour, a different richness, a different sustain, and a different felt quality. EEV is meant to describe that difference in a structured way so that software can read it, compare it, archive it, transmit it, or use it to support a finer analysis.
The format can be produced at several quality levels. The goal is not to change the nature of EEV, but to increase the fineness of the sound description depending on the intended use.
Suitable when a simple representation of the sound is enough.
It allows more reliable comparison and a more nuanced reading of the vibratory signature while remaining relatively compact.
It is suited to uses where temporal evolution and the vibratory morphology of the sound truly matter in the analysis.
It is intended for uses that require the richest possible representation of the sound for in-depth study and resynthesis.
The format can be distributed in two main forms.
The basic form of the format, readable and structured.
The compressed version of the same content. It makes transport and archiving more compact while keeping the same data logic.
A simple structure designed to contain one vibratory fingerprint. It is the most direct choice when you want to store, transmit, or process one sound at a time.
A library structure designed to contain several fingerprints in one organized set. It is useful when you need to manage a collection of sounds, build a reference base, or group multiple fingerprints in one logical file.
EEV is useful as soon as software has to handle sound as more than raw audio or a note name.
Keep a usable vibratory fingerprint.
Compare several sounds with one another.
Note the sonic and vibratory qualities of an instrument.
Archive sound signatures.
Transmit analyses between tools or software environments.
Recreate the sound of an instrument in its essence, its soul (resynthesis).
This site avoids dropping the raw repository on the reader all at once. It proposes a short reading path so a team can define a realistic implementation scope quickly.
Read the Format page to understand sections, canonical order, transport variants, and the difference between tolerant reading and strict writing.
Read the Implementation page to separate container detection, text parsing, internal model, validation, export, and hashing.
Read the Recording page and the resources to avoid a correct implementation built on useless or badly annotated recordings.
The core work begins with the real v1 contract: known sections, writing order, modern fields, and the exact place of tolerated legacy variants.
The model must distinguish identity, global measurements, matrices, vectors, modes, peak tracks, and interpretive layers. Mixing them makes code fragile very quickly.
A reader can stay tolerant. A canonical writer must stay strict, readable, stable, and reproducible. That discipline is what makes the format trustworthy.