[Flac-dev] (Universal) Ambisonic implementation

e deleflie edeleflie at gmail.com
Sun Oct 4 20:46:41 PDT 2009


Hi James,

You have to consider the use cases to understand the implications of
certain file format configurations.

When you consider that many people use horizontal only speaker arrays,
I'd say it may be more appropriate to split up ambisonic channels into
both orders _and_ horizontal vs periphonic information. Then you can
deliver just the horizontal info. That will actually also allow you to
cater for slightly higher orders (4th and above) working within the 8
channel limit.

The difference is do you align the properties of the container to the
maths of spherical harmonics, or do you align the properties of the
container to use cases?

Then I'd ask ... how practical is it to drop certain flac streams from
an Ogg container? There are 2 ways that it could be done ... you could
have the flac streams as separate files, then combine them into an Ogg
on delivery ... or you could have the whole thing already glued
together and then break them up on delivery. Either way, you cant just
serve a file (from something like Amazon S3) .. you have to do some
processing. And either way, you have to have knowledge of the
end-point speaker array.

And if you know what speaker array the ambisonic data will be
delivered to, and you are going to do some processing ... then why not
do the full job and deliver already-decoded speaker feeds?

There are lots of other considerations, many of which have been
discussed on the ambisonics Google groups.... but to cut a long story
short, its all about whether you align the container to the maths of
spherical harmonics, or whether you align the container to how people
produce/consume surround sound.

I also strongly suggest that before anyone consider defining an
ambisonic format, they read the 3rd paper here:
http://www.ai.sri.com/ajh/ambisonics/BLaH.html, called "Is My Decoder
Ambisonic?". It outlines how Ambisonics is much more than just
spherical harmonics.

Etienne




> On Oct 4, 2009, at 16:48, James Cloos wrote:
>> I always thought that the best way to put ambisonic media in flac
>> was to
>> use an ogg container, with the 0-order w channel in one flac
>> stream, the
>> three first-order channels in a second flac stream, the five second-
>> order
>> channels in a third flac stream and the seven third-order channels
>> in a
>> forth flac stream.
>
> Excellent idea!
>
>> An alternative would be to group the 0-order and first order into the
>> first stream and continue as above for the second and third order
>> channels.
>
> This was my first thought, but I did not know how well received the
> idea would be.
>
>> Keeping the same-level channels together should help the compression,
>> but different-order channels are likely to have less inter-dependence.
>
> Very true.  I'm not sure how the three (?) first order channels would
> allow FLAC to take advantage of inter-dependence, because I cannot
> remember the limits of the current algorithm.  Certainly, stereo is
> analyzed, as are mid-side and a few other variations.  I'm just not
> sure whether any advantage is gained beyond two channels.  Archives
> of this list should have comments from Josh about the current
> algorithm's capabilities.
>
>> Limiting each flac stream to just same-order channels requires four
>> flac streams for a sixteen-channel third-order ambisonic, rather
>> than just two streams, but makes it easier to drop the higher-order
>> channels when desired.
>
> Agreed.
>
>> Allocation of forth and higher order ambison channels into the flac
>> streams is left open, but higher orders are increasingly difficult
>> to record and therfore are increasingly rare.  Forth and higher level
>> may be a purely theoretical concern.
>
> This also makes sense.
>
> Perhaps you should write up an official recommendation!
>
> Brian Willoughby
> Sound Consulting
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>


More information about the Flac-dev mailing list