Skip to main content

Conformance

A conformant LIFE file must satisfy the following requirements.

Required

  • The file must be valid UTF-8 encoded JSON.
  • The top-level object must contain preamble, codec, and events keys.
  • The preamble must contain all required fields defined in The Preamble.
  • The codec must contain all required fields defined in The Codec.
  • The scaling_constant in the codec must match the value in the preamble scaling object.
  • The reference_frequency_hz in the codec must match the frequency_hz in the preamble reference object.
  • All events must be ordered by non-decreasing t value.
  • All voice ratio fields must be expressed as simplified integer ratios - 3:2 not 6:4.
  • All voice hz and wavelength_nm values must be mathematically consistent with their ratio and the codec definition.
  • The source field in the preamble should identify the origin of the content.
  • The rational field in the scaling object should be written in plain language sufficient for a non-specialist to understand.
  • The extensions object should be included with null values for all reserved keys, as a forward-compatibility signal.
  • Colour values should be included in voice objects for human readability, even though they are not canonical.

Forbidden

  • A file must not omit the ratio field from any voice object.
  • A file must not express ratio as a decimal. Only integer:integer form is valid.
  • A file must not define extension keys that conflict with the reserved keys in the extensions section for purposes other than those defined.
  • A binary serialisation must not be distributed without a corresponding JSON canonical form.

Validation

There is currently no automated validator for LIFE files. One is planned. In the meantime, conformance can be verified manually against this specification.

If you have built a LIFE validator, get in touch at hello@life-codec.org.

Binary serialisation

A binary serialisation of the LIFE format - .life.bin - may be implemented for performance-critical applications such as real-time light systems or hardware instruments.

Any binary serialisation must be:

  • Fully derivable from the canonical JSON form
  • Convertible back to the canonical JSON form without loss
  • Distributed alongside a corresponding JSON canonical form

The JSON form is always authoritative. The binary form is always derived.