Proposal for Ambisonics format in vorbis comment.

--===============0177498127==
Content-Type: multipart/alternative; 
	boundary="----=_Part_11375960_921675.1448568854708"

------=_Part_11375960_921675.1448568854708
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Greetings,

I apologize if I posted this in the wrong list, I wasn't sure where to post=
 it, but seeing as the tags are called "vorbis comments" I thought vorbis, =
rather than ogg-dev, would be the right choice. (actually, I'm not even a d=
eveloper anyway)

What I'd like to propose is a simple way to encode ambisonic files in vorbi=
s comments as simple tags. By this I don't mean a single change to the form=
at itself or the codec, but a simple "official" tag so that hopefully, in t=
he future, we'll have decoders complying with it. Nobody ever wants to take=
 ambisonic storage off the ground in an *universal* fashion because there's=
 no standard in encoding the *channel orderings*, what *channels are presen=
t*, and the *normalization*, and people don't agree on one thing for some r=
eason. (perhaps being stubborn)

My proposal is different because it solves all issues: it allows only Panto=
phonic (or planar/2D) signals if you wish, as probably most music and peopl=
e will not even have a 3D system which includes height... at the same time =
you can specify a full 3D sphere encoding, or somewhere in between. The for=
mer is especially important because it needs far less number of channels an=
d thus consumes far less amount of space and bandwidth, so instead the orde=
r of ambisonic or quality of the audio itself can be increased.


Note that this proposal is *infinitely* extensible to an arbitrary "ambison=
ic order", *and* it can specify the normalization. I haven't decided on the=
 default normalization scheme, I'd like it to be N3D (why? well, just becau=
se? none is objectively superior but we have to agree on *something* for a =
standard) but it doesn't really matter as it can be specified.


Basically, it uses the ACN channel ordering described here: http://ambisoni=
cs.ch/standards/channels/ (it is mathematically defined by the relationship=
 l*(l+1) + m; where l is the mathematical degree, and m is the mathematical=
 order). (note that in ambisonics jargon, the 'order' of ambisonics actuall=
y refers to the mathematical degree)

However the filetypes are described here: http://ambisonics.ch/standards/fi=
letypes/

(Please note I have no affiliation with that site, I just found it and it i=
s the best way to describe ambisonics material)

This allows us to *uniquely* identify the channels used without wasting spa=
ce on empty channels at all. Because you specify both the "degree" of the P=
antophony and the "degree" of the height individually. The value (3,0) woul=
d thus mean "third order ambisonics pantophony" having channels 0,1,3,4,8,9=
,15 present with no height component at all because it is degree 0 for heig=
ht, which means a 2D/Planar signal requiring *only* 7 channels instead of 1=
6! Of course if you wanted a full-sphere 3D field, then you'd use (3,3) and=
 get all 16 channels in the file. Lowering the second degree simply lowers =
the "order" or "resolution" of the height component.

The important thing to remember is that by just these two values, the decod=
er knows *exactly* which channels are present and in what order, because th=
ey are defined precisely from it. No empty channels that waste space and ba=
ndwidth. Plus, the decoder is not confused as it knows exactly how and whic=
h channels and in what order they are present (there are only 7 in the 2D c=
ase).

The "way" to calculate which channels are present is easy enough if you loo=
k at the first link which describes the full channel orderings (ACNs). For =
a 2D planar case, you simply take, for each degree, the 'extremities' where=
 m is -l and +l, and only use those channels. For example, "third order" (3=
rd degree) planar has the channels with:

Degree 0: m=3D0 -> ACN 0
Degree 1: m=3D-1 and +1 -> ACN 1,3=C2=A0 (refer to the table which is built=
 from that math relationship)
Degree 2: m=3D-2 and +2 -> ACN 4,8
Degree 3: m=3D-3 and +3 -> ACN 9,15

Thus combining all of them up we have 0,1,3,4,8,9,15 our 7 channels! This i=
s what is actually present in the file itself (the 7 channels), but the dec=
oder knows where and how to decode and map them from just that. You can ext=
end this to arbitrary orders and degrees.

If you increase the second (height) degree, you simply add all the channels=
 for that degree. A (3,1) for instance will take all the missing channels f=
rom degrees 0 and 1. Since we didn't skip any channels from degree 0, and w=
e only skipped one channel from degree 1 (where m=3D0; we only took m=3D-1 =
and m=3D1), then we just add that channel where l=3D1 and m=3D0 -> ACN 2. T=
hus for (3,1) we get 0,1,2,3,4,8,9,15=C2=A0 (8 channels in the file), and i=
t *uniquely* identifies the channel ordering like this, zero ambiguity.

For (3,2) we'd add the channels in degree 2 that we missed (except for m=3D=
-2 and m=3D2), thus we add channels corresponding to l=3D2 and m=3D-1,0,1, =
thus ACN 5,6,7. Thus (3,2) has the 0,1,2,3,4,5,6,7,8,9,15 channels (11 chan=
nels in the file).

If you do (3,3) you end up with all channels for all 3 degrees, so all 0...=
15 channels. I hope you get it, it's easy enough to understand and no ambig=
uity whatsoever.

The last thing to add is the normalization which I think can simply be adde=
d after a colon. Thus finally, my proposal would be to add tag like this as=
 a vorbiscomment:

AMBISONIC=3D(3,0):N3D

The above tag defines a 2D planar file with "third order ambisonics" and no=
 height at all, using the N3D normalization scheme. Thus, when a decoder se=
es this, it knows this file has 7 channels and they are ACN 0,1,3,4,8,9,15.=
 The following tag:

AMBISONIC=3D(3,3):SN3D

defines a full-sphere 3D field using the SN3D normalization scheme. When th=
e decoder sees it, it knows the file has 16 channels, them being ACN 0...15=
. (of course the decoder can refuse to decode if it cannot! that's beside t=
he point!)

Would acknowledging such a tag as official format be much trouble and to be=
 added to the spec?

I simply want an *official* way to send this very simple information requir=
ing no more than just two values and the normalization scheme and store it =
in a file. I already use this tag format on my things right now (unreleased=
 because I need to know it is the best way) because I really want to take A=
mbisonics off the ground (even for music which is what I do). I want it off=
icially because then decoders will hopefully be made to comply with it. Alo=
ne, I have no power to influence that, sadly, so I turned to you.

I need your help here. This can work in FLAC too with vorbiscomments. Maybe=
 other formats will follow if they see this take off. And if possible it sh=
ould work on any other format that can specify tags, like Opus, I just need=
 the official recognition. There is zero change in the codec itself or the =
format, it's just an officially recognized tag in a way declared in the spe=
c, so decoders can know how to comply. Please if you do take this to heart,=
 and decide to implement it, feel free to describe it in much better detail=
 or technical terms as needed. I just wanted to explain it in an easy to un=
derstand manner.

If you have an alternative way to do this officially or a superior method (=
but this one proposed has *zero* shortcomings as far as storing ambisonic m=
aterial is concerned that I'm aware of), please tell me so I will use it in=
stead! Even if rejected, I will continue to use it just because I want to s=
ee it off the ground. I truly hope you'll consider it as an official tag fo=
rmat (I will encourage its use if so).

Thank you for your time and once again I am sorry if I mailed this in the w=
rong section, as this isn't necessarily about the codec, but I did not know=
 where to put it (because I'm not a developer).
------=_Part_11375960_921675.1448568854708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div style=3D"color:#000; background-color:#fff; f=
ont-family:HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helve=
tica, Arial, Lucida Grande, sans-serif;font-size:16px">Greetings,<br class=
=3D"" id=3D"yui_3_16_0_1_1448566193397_8481"><br class=3D"" id=3D"yui_3_16_=
0_1_1448566193397_8483">I apologize if I posted this in the wrong list, I w=
asn't sure where to post it, but seeing as the tags are called "vorbis comm=
ents" I thought vorbis, rather than ogg-dev, would be the right choice. (ac=
tually, I'm not even a developer anyway)<br class=3D"" id=3D"yui_3_16_0_1_1=
448566193397_8485"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8487">Wh=
at I'd like to propose is a simple way to encode ambisonic files in vorbis =
comments as simple tags. By this I don't mean a single change to the format=
 itself or the codec, but a simple "official" tag so that hopefully, in the=
 future, we'll have decoders complying with it. Nobody ever wants to take a=
mbisonic storage off the ground in an *universal* fashion because there's n=
o standard in encoding the *channel orderings*, what *channels are present*=
, and the *normalization*, and people don't agree on one thing for some rea=
son. (perhaps being stubborn)<br class=3D"" id=3D"yui_3_16_0_1_144856619339=
7_8489"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8491">My proposal i=
s different because it solves all issues: it allows only Pantophonic (or pl=
anar/2D) signals if you wish, as probably most music and people will not ev=
en have a 3D system which includes height... at the same time you can speci=
fy a full 3D sphere encoding, or somewhere in between. The former is especi=
ally important because it needs far less number of channels and thus consum=
es far less amount of space and bandwidth, so instead the order of ambisoni=
c or quality of the audio itself can be increased.<br class=3D"" id=3D"yui_=
3_16_0_1_1448566193397_8493"><br class=3D"" id=3D"yui_3_16_0_1_144856619339=
7_8495"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8497">Note that thi=
s proposal is *infinitely* extensible to an arbitrary "ambisonic order", *a=
nd* it can specify the normalization. I haven't decided on the default norm=
alization scheme, I'd like it to be N3D (why? well, just because? none is o=
bjectively superior but we have to agree on *something* for a standard) but=
 it doesn't really matter as it can be specified.<br class=3D"" id=3D"yui_3=
_16_0_1_1448566193397_8499"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397=
_8501"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8503">Basically, it =
uses the ACN channel ordering described here: http://ambisonics.ch/standard=
s/channels/ (it is mathematically defined by the relationship l*(l+1) + m; =
where l is the mathematical degree, and m is the mathematical order). (note=
 that in ambisonics jargon, the 'order' of ambisonics actually refers to th=
e mathematical degree)<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8505"=
><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8507">However the filetype=
s are described here: http://ambisonics.ch/standards/filetypes/<br class=3D=
"" id=3D"yui_3_16_0_1_1448566193397_8509"><br class=3D"" id=3D"yui_3_16_0_1=
_1448566193397_8511">(Please note I have no affiliation with that site, I j=
ust found it and it is the best way to describe ambisonics material)<br cla=
ss=3D"" id=3D"yui_3_16_0_1_1448566193397_8513"><br class=3D"" id=3D"yui_3_1=
6_0_1_1448566193397_8515">This allows us to *uniquely* identify the channel=
s used without wasting space on empty channels at all. Because you specify =
both the "degree" of the Pantophony and the "degree" of the height individu=
ally. The value (3,0) would thus mean "third order ambisonics pantophony" h=
aving channels 0,1,3,4,8,9,15 present with no height component at all becau=
se it is degree 0 for height, which means a 2D/Planar signal requiring *onl=
y* 7 channels instead of 16! Of course if you wanted a full-sphere 3D field=
, then you'd use (3,3) and get all 16 channels in the file. Lowering the se=
cond degree simply lowers the "order" or "resolution" of the height compone=
nt.<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8517"><br class=3D"" id=
=3D"yui_3_16_0_1_1448566193397_8519">The important thing to remember is tha=
t by just these two values, the decoder knows *exactly* which channels are =
present and in what order, because they are defined precisely from it. No e=
mpty channels that waste space and bandwidth. Plus, the decoder is not conf=
used as it knows exactly how and which channels and in what order they are =
present (there are only 7 in the 2D case).<br class=3D"" id=3D"yui_3_16_0_1=
_1448566193397_8521"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8523">=
The "way" to calculate which channels are present is easy enough if you loo=
k at the first link which describes the full channel orderings (ACNs). For =
a 2D planar case, you simply take, for each degree, the 'extremities' where=
 m is -l and +l, and only use those channels. For example, "third order" (3=
rd degree) planar has the channels with:<br class=3D"" id=3D"yui_3_16_0_1_1=
448566193397_8525"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8527">De=
gree 0: m=3D0 -&gt; ACN 0<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_85=
29">Degree 1: m=3D-1 and +1 -&gt; ACN 1,3&nbsp; (refer to the table which i=
s built from that math relationship)<br class=3D"" id=3D"yui_3_16_0_1_14485=
66193397_8531">Degree 2: m=3D-2 and +2 -&gt; ACN 4,8<br class=3D"" id=3D"yu=
i_3_16_0_1_1448566193397_8533">Degree 3: m=3D-3 and +3 -&gt; ACN 9,15<br cl=
ass=3D"" id=3D"yui_3_16_0_1_1448566193397_8535"><br class=3D"" id=3D"yui_3_=
16_0_1_1448566193397_8537">Thus combining all of them up we have 0,1,3,4,8,=
9,15 our 7 channels! This is what is actually present in the file itself (t=
he 7 channels), but the decoder knows where and how to decode and map them =
from just that. You can extend this to arbitrary orders and degrees.<br cla=
ss=3D"" id=3D"yui_3_16_0_1_1448566193397_8539"><br class=3D"" id=3D"yui_3_1=
6_0_1_1448566193397_8541">If you increase the second (height) degree, you s=
imply add all the channels for that degree. A (3,1) for instance will take =
all the missing channels from degrees 0 and 1. Since we didn't skip any cha=
nnels from degree 0, and we only skipped one channel from degree 1 (where m=
=3D0; we only took m=3D-1 and m=3D1), then we just add that channel where l=
=3D1 and m=3D0 -&gt; ACN 2. Thus for (3,1) we get 0,1,2,3,4,8,9,15&nbsp; (8=
 channels in the file), and it *uniquely* identifies the channel ordering l=
ike this, zero ambiguity.<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_85=
43"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8545">For (3,2) we'd ad=
d the channels in degree 2 that we missed (except for m=3D-2 and m=3D2), th=
us we add channels corresponding to l=3D2 and m=3D-1,0,1, thus ACN 5,6,7. T=
hus (3,2) has the 0,1,2,3,4,5,6,7,8,9,15 channels (11 channels in the file)=
.<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8547"><br class=3D"" id=3D=
"yui_3_16_0_1_1448566193397_8549">If you do (3,3) you end up with all chann=
els for all 3 degrees, so all 0...15 channels. I hope you get it, it's easy=
 enough to understand and no ambiguity whatsoever.<br class=3D"" id=3D"yui_=
3_16_0_1_1448566193397_8551"><br class=3D"" id=3D"yui_3_16_0_1_144856619339=
7_8553">The last thing to add is the normalization which I think can simply=
 be added after a colon. Thus finally, my proposal would be to add tag like=
 this as a vorbiscomment:<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_85=
55"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8557">AMBISONIC=3D(3,0)=
:N3D<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8559"><br class=3D"" id=
=3D"yui_3_16_0_1_1448566193397_8561">The above tag defines a 2D planar file=
 with "third order ambisonics" and no height at all, using the N3D normaliz=
ation scheme. Thus, when a decoder sees this, it knows this file has 7 chan=
nels and they are ACN 0,1,3,4,8,9,15. The following tag:<br class=3D"" id=
=3D"yui_3_16_0_1_1448566193397_8563"><br class=3D"" id=3D"yui_3_16_0_1_1448=
566193397_8565">AMBISONIC=3D(3,3):SN3D<br class=3D"" id=3D"yui_3_16_0_1_144=
8566193397_8567"><br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8569">defi=
nes a full-sphere 3D field using the SN3D normalization scheme. When the de=
coder sees it, it knows the file has 16 channels, them being ACN 0...15. (o=
f course the decoder can refuse to decode if it cannot! that's beside the p=
oint!)<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8571"><br class=3D"" =
id=3D"yui_3_16_0_1_1448566193397_8573">Would acknowledging such a tag as of=
ficial format be much trouble and to be added to the spec?<br class=3D"" id=
=3D"yui_3_16_0_1_1448566193397_8575"><br class=3D"" id=3D"yui_3_16_0_1_1448=
566193397_8577">I simply want an *official* way to send this very simple in=
formation requiring no more than just two values and the normalization sche=
me and store it in a file. I already use this tag format on my things right=
 now (unreleased because I need to know it is the best way) because I reall=
y want to take Ambisonics off the ground (even for music which is what I do=
). I want it officially because then decoders will hopefully be made to com=
ply with it. Alone, I have no power to influence that, sadly, so I turned t=
o you.<br class=3D"" id=3D"yui_3_16_0_1_1448566193397_8579"><br class=3D"" =
id=3D"yui_3_16_0_1_1448566193397_8581">I need your help here. This can work=
 in FLAC too with vorbiscomments. Maybe other formats will follow if they s=
ee this take off. And if possible it should work on any other format that c=
an specify tags, like Opus, I just need the official recognition. There is =
zero change in the codec itself or the format, it's just an officially reco=
gnized tag in a way declared in the spec, so decoders can know how to compl=
y. Please if you do take this to heart, and decide to implement it, feel fr=
ee to describe it in much better detail or technical terms as needed. I jus=
t wanted to explain it in an easy to understand manner.<br class=3D"" id=3D=
"yui_3_16_0_1_1448566193397_8583"><br class=3D"" id=3D"yui_3_16_0_1_1448566=
193397_8585">If you have an alternative way to do this officially or a supe=
rior method (but this one proposed has *zero* shortcomings as far as storin=
g ambisonic material is concerned that I'm aware of), please tell me so I w=
ill use it instead! Even if rejected, I will continue to use it just becaus=
e I want to see it off the ground. I truly hope you'll consider it as an of=
ficial tag format (I will encourage its use if so).<br class=3D"" id=3D"yui=
_3_16_0_1_1448566193397_8587"><br class=3D"" id=3D"yui_3_16_0_1_14485661933=
97_8589"><div id=3D"yui_3_16_0_1_1448566193397_8666" dir=3D"ltr">Thank you =
for your time and once again I am sorry if I mailed this in the wrong secti=
on, as this isn't necessarily about the codec, but I did not know where to =
put it (because I'm not a developer).</div></div></body></html>
------=_Part_11375960_921675.1448568854708--

--===============0177498127==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Vorbis mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/vorbis

--===============0177498127==--