Re: [linux-audio-dev] open standards for file formats

On Mon, 2006-01-30 at 11:13 +0000, cdr wrote:
> i know design by committee can be horrible but these situations usually utilize vastly similar yet incompatible formats, so its sort of biting off something small, i hope.. :)
>
> (1) Peak Files
> some of my favorite wav files have 10 metafiles each. peaks generated for peak, spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep, ardour, plus a dir for "Apple Loops" data etc.
>
> it would be great if each time an audio file enters a new app, the user wasnt greeted with a 30 second burst of disk activity as peak files were generated yet again..what exactly is needed? here are some thoughts
>
> - average amplitude per time-slice to generate the waveform overview
> * what granularity is useful? peak files seem to run a few % of filesize..
> - spectral centroid for comparisonics/freesound style colorization
> - annotations (OPML etc)
> - timing (tempo, cue points, beat markers)
>
> rather than invent some new arbitrary plaintext (or XML) format, i'm interested in using OSC (as described at http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to encapsulate this data, at which point this is simply an exercise in selecting a schema/namespace...
>
> beside faster load-times (eg one could pregenerate this data before a performance or composition session via a recursive shell command and 'sox'), a commonly understood format would enable easier sharing of CC-licensed material among a variety of users and apps without useful metadata being 'lost in translation'. additionally web and other interfaces could be developed using the metadata hints (see archive.org, NI's KORE)

i think that this is a rather mistaken goal.

peak files and metadata are not equivalent except in the broadest sense.
annotations, timing information are all totally different beasts from
peak files. freq domain data is similar, for the most important reason:
there is no single format that will work well. ardour's current kludge
(a single peak file resolution) is likely to vanish at some point, to be
replaced by multiple peak files at different resolutions. spectral data
is the same thing: you need to know the window size at the very least,
and this can vary depending on what the user is doing.

note also that comparisonics is still covered by a patent that i expect
would be vigorously defended.

--p
Received on Mon Jan 30 16:15:12 2006