Open format for vibration-aware software

An open format that lets software read, store, compare, and transmit the vibratory signature of a sound.

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.

Four quality levels

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.

ECO — Essential

Suitable when a simple representation of the sound is enough.

STANDARD — Enriched

It allows more reliable comparison and a more nuanced reading of the vibratory signature while remaining relatively compact.

HIGH — Advanced

It is suited to uses where temporal evolution and the vibratory morphology of the sound truly matter in the analysis.

ULTRA — Detailed

It is intended for uses that require the richest possible representation of the sound for in-depth study and resynthesis.

Two public forms of the EEV format

The format can be distributed in two main forms.

EEV

The basic form of the format, readable and structured.

EEVZ

The compressed version of the same content. It makes transport and archiving more compact while keeping the same data logic.

Two ways to organize fingerprints

ENTRY

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.

LIB

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.

Why EEV is useful

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).

Where a team should begin

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.

1. Frame the contract

Read the Format page to understand sections, canonical order, transport variants, and the difference between tolerant reading and strict writing.

2. Fix the architecture

Read the Implementation page to separate container detection, text parsing, internal model, validation, export, and hashing.

3. Prepare the raw material

Read the Recording page and the resources to avoid a correct implementation built on useless or badly annotated recordings.

Canonical contract

The core work begins with the real v1 contract: known sections, writing order, modern fields, and the exact place of tolerated legacy variants.

Layer separation

The model must distinguish identity, global measurements, matrices, vectors, modes, peak tracks, and interpretive layers. Mixing them makes code fragile very quickly.

Export discipline

A reader can stay tolerant. A canonical writer must stay strict, readable, stable, and reproducible. That discipline is what makes the format trustworthy.