[ogg-dev] libogg++ release 1.1.0

[Silvia Pfeiffer]

On Tue, Jun 9, 2009 at 9:23 AM, ter<et at ihear.com> wrote:
> 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
>        manifold.
>
> 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?

The definition of new mime types (including file extensions) is
something that should be well considered, if you are planning for a
wider uptake of the file format. ogx  (for ogg multiplex) is useful in
that it claims there could be anything in this ogg container and you
are free to use this extension for it. If that is not sufficient for
you and you think that your particular combination of tracks requires
a new mime type (e.g. "it is not just a ogg multiplex file, but a file
with linguistic content that will typically be used by linguistic
applications"), then you should totally invent your own mime and file
type (e.g. application/ogg+linguistic and .ogl). It's your choice. :)

Cheers,
Silvia.