That was a lot of information, I was only thinking of distribution to end-users on the web.
It would save a bit of volume in comparison to wav. This is the current state of ohti, We are to add more buttons for routing of mixed order Ambisonics, the channel routing can be edited before playback. I am waiting for Roger to fix it, but he has just bought a new condinium... http://www.ohti.xyz/2021/original.html Den sön 23 maj 2021 12:38Fons Adriaensen <f...@linuxaudio.org> skrev: > On Sat, May 22, 2021 at 06:15:48PM -0400, Marc Lavallée wrote: > > > In the document, "Universal Ambisonic" is described to work with WavPack. > > "Universal Ambisonic" is as dead as can be, and that's probable the > best that could happen to it. It was precisely a desire to get rid > of ill-conceived 'standards' like this that motivated the design of > the Ambix format. Which is also what everybody uses today. > > As an audio file format Wavpack is rather primitive. It could be > useful as a format for content delivery to the end user, but for > production it is pretty useless. > > AFAIK, you can convert .wav, .caf and others to Wavpack and back > again, but only the audio data is preserved. Both WAVEX and CAF > support a lot of other data as well. > > Wavpack was considered by the Ambix designers as a way to cater > for unused channels (like for horizontal-only AMB). These would > simply be set to all zeros and compressed to only a few bytes. > > But the matrix based method was chosen in the end as a better > alternative that also offered other functionality. > > The reason why CAF was chosen was that it was (and still is) the > cleanest and most versatile format available. > > CAF has several advantages: > > * 64-bit filesize, no problem with long multichannel files exceeding > the size limit. > > * Support of 'user' extensions. CAF is a 'chunked format' (like WAVEX), > and it also supports UUID [1] chunks, extensions that are identified > using a 128-bit unique identifier. These can be used without needing > approval or registration by Apple. Any software that doesn't know > how to interpret a particular UUID chunk should just ignore it. > Thus users can extend the format in a way that is future proof and > that will never be in conflict with other extensions. This is how > the Ambix 'extended format' is implemented and why it requires CAF. > > * No history of unofficial variations and extensions with all the > resulting fragility. > > Now compare that to what happened with the WAV format. The original > WAV specs where quite ambiguous in some respects, and also lacked > functionality. So various unofficial and mutually incompatible > vendor extensions started to appear, and pretty soon a .wav file > created by software X could not be used by software Y. > More than 20 years ago Microsoft decided the clean up the resulting > mess and created the WAVEX format. Since then, every .wav file that > has more than 2 channels or uses more then 16 bit resolution has to > use the WAVEX format. But there are still a lot of defective WAV > files around, and WAVEX has no way to add UUID chunks as in the > CAF format (they could be added easily, but that has not happened). > > > Ciao, > > > [1] <https://en.wikipedia.org/wiki/Universally_unique_identifier> > > -- > FA > > _______________________________________________ > Sursound mailing list > Sursound@music.vt.edu > https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, > edit account or options, view archives and so on. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/800f2540/attachment.htm> _______________________________________________ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit account or options, view archives and so on.
