On 26/11/2011 05:07, Sampo Syreeni wrote:
..
As I said this may be the 'true way', but basically, IMO, it's yet
another attempt by Apple to create yet another format 'the other lot
can't read'.
Fully agreed. Though then you'd have to agree it's a neat format per se.
Well-thought out, as clean as de novo ones come, and perhaps the only
new one which includes at least some support for ambisonic. It might be
that we're a bit partial here, being that many around here like
ambisonic. But you too have to admit it's a neat de novo design.
Of course it only works for Apple, as an ecosystem. That's why nobody
here really bets their livelihood on it. Just look at the logs and be
assured of that. :)
The CAF format is published, and is implemented in libsndfile. So any
FOSS software linking with libsndfile automatically has, in principle,
support for the CAF format. Possibly not "fully comprehensively", but
the trick is usually to ask Eric de Castro Lopo to add whatever you
want. With 1001 variations on file formats floating around, he tends to
prioritise what people actually say they need.
There is nothing to stop third party developers (say, on Windoze)
providing support for CAF files if they consider it important to do so,
or if their customers ask for it in sufficient numbers to justify the
man-hours. It would not surprise me at all if the Quicktime player on
Windoze could read a CAF file, thought I have not "got around" yet to
finding out, as I hardly use the PC for audio work at all these days.
The general point is quite simple - the vast majority of soundfiles
winging around the net are relatively short, and easily contained within
the WAVE or AIFF formats people already understand, and have lesser or
greater allegiance to. Ostensibly the only technical benefit given by
CAF files is for huge files > 4GB, and the chances are that few files of
that size will be posted online, and fewer actually downloaded. The
other reason is trivial - Apple is now on little-endian processors, so
AIFF is less appropriate as a container. Reading one or two is no
problem; reading 100s or 1000s of them involves a ~serious ~ amount of
byte-swapping.
Add to that the myth that CAF is a closed format, and the rest becomes a
self-fulfilling prophecy; Windoze developers and users will simply
assume it is not viable for them.
Note that it is perfectly easy to add 1001 speaker position IDs to a
file format; not quite so obvious how to handle them in a playback
application on a system that likely does not have speakers in all those
positions ready and waiting. Someone can write the ultimate catch-all
position-remapping code to route whatever arcane combination of speaker
positions are specified to whatever other arcane layout the particular
user has, if they have the time and the inclination. Could be a nice
little research project; but testing it could be "interesting".
I see two choices - either you pre-map your sounds to the speaker and
delivery layouts that already exist in the consumer universe, or you
manage to define the layout you really want as a new standard which will
magically be adopted by both manufacturers and consumers within your
lifetime. The price of insisting on maximum generality and flexibility
is that such a standard and level of adoption is unlikely ever to
happen. This is of course exactly the problem Ambisonics sought to
solve, but at the price of requiring decoding at the destination. But
the same issue applies - the more general and flexible and
specify-every-possible-option the spec is, the less likely it is that
any product will implement it. It will remain the province of the
research lab, and of the enterprising domestic experimenter with lots of
spare time (and money).
Just to add, for the sake of completion: Apple have made their "ALAC"
lossless codec open-source, under the Apache 2 licence:
http://alac.macosforge.org
Richard Dobson
_______________________________________________
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound
