[Flac-dev] (Universal) Ambisonic implementation

[e deleflie]

Hi Martin,

One of the designed features of UA is no mandatory information is lost
if the metadata is lost.

So it would be ok to have the metadata in the Ogg wrapper (and not in
the FLAC streams). In any case, if the FLAC streams are limited to 8
channels, then there's no clean way to split up a 16 channel 3rd order
file. The first 8 channels would contain 1st order and most of the
second order channels, the second 8 channels would contain a few
second order channels and the rest of the 3rd order ones.

Its messy but workable. And its actually a very similar predicament to
WavPack in that the metadata would be contained in the top level
wrapper, and not in the channels. A bigger question is what is the
useability/user experience patterns around encoding/exploding 16
channel into 2 lots of 8 in a parent container ... can it be done in
one command?

Etienne


On Wed, Sep 23, 2009 at 11:09 AM, Martin Leese
<martin.leese at stanfordalumni.org> wrote:
> Brian Willoughby <brianw at sounds.wa.com>
>
>> Isn't there a standard option to place FLAC data within an Ogg
>> container?  I don't use it myself, but I understand that it is quite
>> popular.  Would it be possible to interleave multiple FLAC blocks
>> this way?  In other words, can Ogg suffice as the second level of
>> grouping that you refer to?
>
> Etienne was asking for more channels in the
> FLAC stream, so I was trying to put some meat
> on Josh's bare bones statement that it "would
> actually be a lot of work and require extensions
> to the flac format".
>
> Having multiple FLAC streams in an Ogg
> container would, indeed, provide a second
> level of grouping -- actually grouping in
> chunks of eight, but that works.  The problem
> then becomes where to put the metadata.
>
> The metadata could still go in the (multiple)
> FLAC streams, as you suggested, but should
> more logically be up in the Ogg container.
> Currently, the only place available in Ogg is as
> name-value pairs in an OggSkeleton stream.
> After OggSkeleton has become well supported
> then metadata can go into its own stream, but
> we are not there yet.  There does not seem to
> be a neat solution.
>
> Regards,
> Martin
> --
> Martin J Leese
> E-mail: martin.leese  stanfordalumni.org
> Web: http://members.tripod.com/martin_leese/
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>