Hi Trond, > I don't feel qualified to respond to the decisions inherent in the proposal, > but in terms of the layout of the document itself, I would like to suggest a > few improvements that might render it more readable and self-contained, in > particular helping readers/developers with limited prior knowledge of > ambisonics to understand it correctly and in full: > > - The term used for the normalisation scheme N3D should either be further > explained, or a reference provided.
I'm not sure where the term was actually coined, or if whether or not it is an ambisonics-only term. None the less, Fons has a good description in the ambdec manual: "each spherical harmonic has unity power when integrated over the sphere". Fons can I steal your definition? > - The same goes for "Gerzon Ambisonics" This is the name that appeared during the ambisonics Google group discussions, again I'm not sure of the provenance of the term. I just searched the list and could not pin point it ... I assume it makes reference to some papers published by Michael Gerzon. Does anyone know of the provenance? The term should perhaps be dropped altogether, and rather, the sequence described mathematically. > - In relation to the main table, the meaning of the angles theta and delta > should be defined I've added to the document: θ is the azimuth δ is the elevation l is degree m is order > - I would consider adding more parenthesis to the equations to ensure that > they can't be misunderstood. ok, I've turned the formulas into clearer pseudo-codish equations > I am also wondering if the conversions to B-format /FMH be more clear if > given as full equations, eg: > > X = X1 > R = X20 * sqrt(5/4) yes, I've done that > And finally, once the ambisonic file format has been stored in a correct way, > it need to be decoded again. Would it be an idea to provide equations for > this as well? As a developer, I would expect the document not only to provide > information on encoding and storing, but also decoding the format. I understand your point. But I would advise the developer not to write an ambisonic decoder! Let the audio engineer do it. That's half the reason I moved away from SN3DxW .... because N3D has good support in quality ambisonic decoders like AmbDec (and I assume Rapture3D (?)). But you might have a point, because I would also advise the developer not to develop an ambisonic encoder! ... let the audio engineer do it. The spherical harmonic equations don't actually cater for the behaviour of sound in space ... the speed of sound in air, attenuation due to energy dissipation and humidity, sound sources with size (as they practically all have), sound sources that emit different sounds in different directions (as they practically all do). Reflections, 1st, 2nd, diffuse .. all very important spatial audio cues. And diffraction for occlusions and openings... etc. etc. Etienne > > Best. > Trond > > _______________________________________________ > Sursound mailing list > [email protected] > https://mail.music.vt.edu/mailman/listinfo/sursound > _______________________________________________ Sursound mailing list [email protected] https://mail.music.vt.edu/mailman/listinfo/sursound
