Hi, > As the dust settles, I think it is clear that UA should look more like > what it is slowly morphing into. Spec attached, summary below. > Comments and suggestions welcome. > > (...) > > URL: > <https://mail.music.vt.edu/mailman/private/sursound/attachments/20101124/b3c0f099/attachment.pdf>
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. - The same goes for "Gerzon Ambisonics" - In relation to the main table, the meaning of the angles theta and delta should be defined - I would consider adding more parenthesis to the equations to ensure that they can't be misunderstood. E.g. is the equation for X20 to be read as: cos(2*theta) * sqrt(15/4) * pow(cos(delta), 2) or sqrt( cos(2*theta*(15/4) ) * pow(cos(delta), 2) Would it be an idea to provide equations in pseudo code format (C/C++), so that programmers could copy and paste directly into their code? 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) 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. Best. Trond _______________________________________________ Sursound mailing list [email protected] https://mail.music.vt.edu/mailman/listinfo/sursound
