[ogg-dev] libogg++ release 1.1.0

ter et at ihear.com
Mon Jun 8 16:23:02 PDT 2009

On Tue, 2009-06-09 at 00:12 +1000, Silvia Pfeiffer wrote:
> On Sat, Jun 6, 2009 at 6:23 AM, ter<et at ihear.com> wrote:
> >> If you are creating multitrack Ogg files, they should contain a
> >> skeleton track to identify the different contained tracks.
> >> http://wiki.xiph.org/OggSkeleton
> > ALingA is a multitrack format
> > (http://www.ihear.com/dtds/ALingA/0.1/ALingA.dtd) which has a skeleton
> > track (what I call the co-ordinating stream), but one that is very
> > specific, and based on the notion of a Manifold. It is implemented in
> > the separate library libalinga, subclassing libogg++ to do the Ogg
> > stuff
> That sounds fine - as long as your files have a Skeleton track, you
> can put whatever you want into Ogg. Have you specified your special
> skeleton track and the data that you're putting into Ogg somewhere in
> more details? What do you understand by a Manifold? I'm curious about
> more documentation.
http://www.ihear.com/FreeCLAS/wiki/ALingA has most of the important
bits. The skeleton track specifies the counts of the number of
interleaved LingA and signal streams (which may or may not be
interleaved), the underlying manifold, and the relationships of the
signal manifolds to the underlying manifold. (LingA is the linguistic
annotation format.) The notion of Manifold as used here:
        One dimension of this manifold is time-like, i.e., of indefinite
        extent. All other dimensions are space-like, i.e.,of definite
        extent, or size. The measure for all the dimensions is in
        "granules". However, this measure does not imply anything about
        the actual sampling of the signals, including whether it is
        uniform or not. The co-ordinates of the alignment of the labels
        of an annotation are "granule positions". The signals have their
        own manifolds. The granule size of the signal manifolds are
        (integer) multiples of the granule size of the underlying
The Manifold attributes specify among other things the number of
granules perTime and perSpace. The skeleton track is written by a
"co-ordinating codec" (the ALingA codec) to which the signal codecs
submit their manifolds. The ALingA codec then adjusts the underlying
manifold and updates the corresponding relationships to the signal
manifolds to satisfy the requirement stated above, which essentially
says that the signal manifolds have to be decimated versions of the
underlying manifold, and some edge requirements. The ALingA codec does
not do this in the most general way, namely finding least common
denominators. It will reject a codec's manifold if it is not compatible
with the existing underlying manifold, nor can it become the underlying
manifold. This is all that is required to integrate an existing signal
codec, such as Vorbis, Speex or Theora into ALingA. This is how the PCM
codec Neuro is integrated.

> >>  And if the files aren't audio or
> >> video files, you should then use the extension .ogx
> >> http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions .
> > libogg++, libalinga and libneuro are all agnostic about whether the
> > signal streams are audio or video or not. These libraries are aimed at
> > analytical processing, and not at online multimedia. They defer to
> > applications to conform to MIME naming.
> What applications are you currently using on your special Ogg files?
> Since you are using skeleton and ogx is already specified as a
> standard for Ogg files with any types of multi-track content, it seems
> appropriate. I assume you built some command-line applications (if
> only for testing) with your libraries, so they would create the files
> etc?
My applications are in speech processing. I have been using the .ala
extension (has sort of a ring to it). There is a small database in the
FreeCLAS project that has been dispensing .alas to the public. But not
to worry, it has not attained social networking status. I am about to
update it to the next release, and I'll be happy to use an Ogg standard
extension. In that regard, since the "x" in this case is quite
specificly "linguistic", could I bid for an .ogl extension for
multi-track with linguistic content, if it is not already taken?


More information about the ogg-dev mailing list