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 <[email protected]> wrote: > Brian Willoughby <[email protected]> > >> 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 > [email protected] > http://lists.xiph.org/mailman/listinfo/flac-dev > _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
