(Sorry, Sylvia, about the duplicate, hit the wrong reply button.) On Fri, 2009-06-05 at 08:07 +1000, Silvia Pfeiffer wrote:> Hi Elaine, > > I flipped through some of the code but wasn't really about to > determine this: Do you also support Skeleton in libogg++ ?Hi, Silvia. I studied your multi-track work when I was working on ALingA. It was a valuable guide. No, libogg++ tries to be agnostic about codecs. As I understand it, the Ogg format is inherently multi-track, but does not mandate any particular multi-track protocol.> > If you are creating multitrack Ogg files, they should contain a > skeleton track to identify the different contained tracks. > http://wiki.xiph.org/OggSkeletonALingA 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> 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.> > You may already be doing all of this - I just wasn't able to verify, > therefore the question. >I appreciate your interest, and would be happy to answer more. Regards, Elaine> Cheers, > Silvia. > > On Fri, Jun 5, 2009 at 6:57 AM, ter <et at ihear.com> wrote: > > Hi everybody, > > > > I posted here about two years ago about the initial release. This is a > > release that fixes many bugs, and has enhancements that make it possible > > to support a multi-stream format, ALingA, which I will mention briefly > > later. It also supports a PCM format, Neuro, both as part of the > > multi-stream codec, and stand-alone. > > > > libogg++ is a C++ library implementing Ogg. It is designed to be > > independent of the specific codecs for the interleaved data streams, and > > to be thread-safe in a threading model in which each codec or transport > > runs in its own thread. > > > > Main features added since initial release > > Selection logic which allows a co-ordinating stream's header > > pages which may contain info about the other streams to be > > decapsulated before the first header pages for these other > > streams have been claimed. > > > > A PageReader to read raw (un-decapsulated) pages either > > simultaneously with reading the decapsulated packets, or by > > themselves. The application can then route these pages to a > > Pagewriter. This allows logical streams to be ripped and merged > > into Ogg streams without re-encapsulation > > > > Downloads and checkouts are available at > > http://savannah.nongnu.org/projects/liboggpp > > > > ALingA (Aligned Linguistic Annotations) is a multi-stream format > > designed for interleaving linguistic annotations with the audio/video or > > other multi-dimensional signals against which they are aligned. > > libalinga is a C++ library that implements ALingA using libogg++. Neuro > > is the simple PCM format for the signal streams. libneuro implements > > Neuro also using libogg++. It is designed to work with libalinga, but > > the PCM codec can also be used stand-alone. More information about these > > libraries, and a web project using them, is at > > http://www.ihear.com/FreeCLAS/. > > > > Comments and feedback are very welcome, > > > > Elaine > > > > > > _______________________________________________ > > ogg-dev mailing list > > ogg-dev at xiph.org > > http://lists.xiph.org/mailman/listinfo/ogg-dev > >
On Sat, Jun 6, 2009 at 6:23 AM, ter<et at ihear.com> wrote:> (Sorry, Sylvia, about the duplicate, hit the wrong reply button.) > On Fri, 2009-06-05 at 08:07 +1000, Silvia Pfeiffer wrote: >> Hi Elaine, >> >> I flipped through some of the code but wasn't really about to >> determine this: Do you also support Skeleton in libogg++ ? > Hi, Silvia. I studied your multi-track work when I was working on > ALingA. It was a valuable guide. > No, libogg++ tries to be agnostic about codecs. As I understand it, the > Ogg format is inherently multi-track, but does not mandate any > particular multi-track protocol. > >> >> 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 > stuffThat 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.>> ?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?>> You may already be doing all of this - I just wasn't able to verify, >> therefore the question. >> > I appreciate your interest, and would be happy to answer more.And I appreciate the patience. :-) I am rather intrigued and curious.... Regards, Silvia.
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? Regards, Elaine