“So using the Ambix format in a CAF container with ALAC compression is
a good choice.”
Seriously: Is a good choice for what?
In the production area people will happily continue to use Wave and
CAF files, because this just works - and file size reduction is not
really needed.
If you use lossless compression in the browser, the de facto standard
is really Flac. (As you of course know, because you have used this.)
Neither WavPack or ALAC are universally accepted formats, so you could
ask if “extended Flac” (normal adapation to changing realities
requires more than 8 channels) could be a better choice in the
long-term.
Compression factors are more or less similar, in all three cases.
Best,
Stefan
----- Mensagem de Marc Lavallée <m...@hacklava.net> ---------
Data: Sun, 23 May 2021 09:15:55 -0400
De: Marc Lavallée <m...@hacklava.net>
Assunto: [Sursound] ALAC (was Re: WavPack (was: Re: Ambix files))
Para: sursound@music.vt.edu
Fons, thanks for the precisions.
My question should have been "why CAF"?
I was more concerned by lossless audio compression, support for
multiple channels, and file size.
In
https://www.researchgate.net/publication/266602800_AMBIX_-A_SUGGESTED_AMBISONICS_FORMAT, WavPack is mentioned as a possible compression codec for the CAF format. At the time of publication (July 2011), the Apple ALAC compression codec was not officially released, but it was a 7 years old codec so I wonder why there's no mention of it; maybe at the time, ALAC was not usable in a CAF
container...
I assumed that ALAC compression is for Apple-only devices, but it
works on other platforms as well, and a quick test shows that ALAC
can be a bit more efficient than WavPack (for file size, no idea
about CPU usage).
So using the Ambix format in a CAF container with ALAC compression
is a good choice.
Marc
Le 2021-05-23 à 06 h 37, Fons Adriaensen a écrit :
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>
_______________________________________________
Sursound mailing list
surso...@music.vt.eduhttps://mail.music.vt.edu/mailman/listinfo/sursound -
unsubscribe here, edit account or options, view archives and so on.
----- Fim da mensagem de Marc Lavallée <m...@hacklava.net> -----
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20210523/a75ccb44/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.
