SDIFF - Spectral Description Interchange File Format

Adrian Freed

What is SDIFF?

The idea is to create a new standardized file format to promote :

  1. the multiplatform interchange of spectral description,
  2. reduce the considerable duplication of effort for everybody to support everybody else's extant data formats. (there are more than 10 groups working on spectral descriptions for audio and computer music),
  3. encourage the development of new tools for manipulating spectral description,
  4. promote the use of spectral descriptions in general.

What's new?

file format (syntax)

Thank you everyone for your feedback and support for this effort. Much of your feedback has been concerned with the form SDIFF data is to be represented in. I believe that most of our efforts should be concentrated on the content of the data and successfully documenting how this data can be unambiguously interpreted (the semantics). However, we will need a file format (the syntax) and I am sifting through many candidates. Here are some possibilities:

Naming

Many of the available file formats make claims about extensibility, but I would like to address in SDIFF a flaw of the existing formats in this respect, i.e. the namespace of object data types is owned and managed by a central authority. In practice these central authorities are often inflexible or simply disappear. I propose to resolve the name space issue by using domain names, e.g. cnmat.berkeley.edu. These are already managed by a central authority which is going to be around in some form for a long time. This would facilitate a relatively open standard where new ideas about spectral descriptions could be quickly integrated into SDIFF.

Another thing that you notice in standards is the huge size of the documents that describe them and the subsequent documents to describe how to interpret the standard. I would like to propose a way to short cut most of the verbiage to reach what we are really doing this for: code we can build into our tools that facilitates interchange. The idea is that the specification for a particular spectral description consist of:

  1. example files in that format
  2. commented ANSII C code that reads and interprets those files by outputting an AIFF sound file.

The C implementations would be designed for readability, simplicity and portability at the expense, no doubt, of space and cpu efficiency.

We are examining the possibility of using URL's instead of domain names. The URL points to documentation and a java program that can read and interpret the SDIFF file.

Grouping

Many of you have raised the question of how to store information related to SDIFF data in the same file. Also you have expressed the need to group different related SDIFF data types into single files. I believe we can achieve a simpler, easier to understand and implement spec. if we adopt a one type/one file model for SDIFF data and use a more general mechanism to group files. I am interested in your suggestions/experiences for the grouping mechanism. Possibilities include:

Who has expressed interest in this effort?

Who is working on spectral descriptions?

In addition to the projects mentioned above I know of:

What existing file formats do people use?

Thanks for sending me your current formats or plans. Here is what I have received so far that I was able to readily put in html form:

How can I contribute to the SDIFF effort?

When will the SDIFF spec. be ready?

The plan is to proceed as follows:

  1. Throw up the spec. of a strong candidate .
  2. Address its known weaknesses.
  3. Incorporate the first round of your suggestions into the spec.
  4. Implement a reader/writer for the format and correct the spec. where it is not implementable.
  5. Post the implementation here for everyone to build into their tools (with example files).
  6. Integrate everyone's experience into a revised version.
  7. Do a final implementation of the revised spec.
  8. Finalize the documentation and implementation.

What do you mean by "spectral descriptions" anyway?

I take a broad view. The goal is to cover:

How on earth can all this be squeezed in one file format?

You can cover all these with one basic idea (suggested to me by Xavier Rodet): represent the data as a sequence of frames of time tagged matrices.

So the basic structure is something like this:

In most cases the rows correspond to frequency tracks, bins, or channels. The columns correspond to parameters such as:

Does anyone require more than 2d matrices? Do we really need a different number of columns on each frame.

How will SDIFF be supported on different platforms?

SDIFF is an interchange format so portability is very important. The following things are proposed to achieve this:

The keen observer will notice that such a format may not be especially space efficient since it affords more dynamic range and resolutions to parameters than is strictly necessary. This is to simplify the implementation and guarantee a lossless interchange, both essential features in an interchange standard. I would expect individual users for resource constrained platforms to develop formats optimized for space efficiency with lossy and perhaps loss-less compression such as the one described by Andrew Horner at this year's ICMC.