Re: Inconsistencies with large WAV file
Re: Inconsistencies with large WAV file
- Subject: Re: Inconsistencies with large WAV file
- From: William Stewart <email@hidden>
- Date: Fri, 4 Dec 2009 10:20:35 -0800
file bugs and we can look at all the issues you describe.
If you want to take a stab at the channel labels for this, we can just
support them if they look like a reasonable approach (advantage of not
having to reach consensus across a large number of disparate
interests)...
Orders don't really matter so much, because (unlike WAVE) the order
isn't defined by the way the channels are described.
We can also include a raft of new labels, so that different possible
uses (different channels) are covered, then we can also pick the most
common orders/num channel configs and define an explicit tag for these
- so if you want to take your best shot at some of these and put that
in the radar that is fine. we can post a proposal back to this list
before we set that in stone.
As for the iXML chunk - I'm not familiar with the contents of that,
but there are various chunks in CAF (notably the info chunk) that can
have arbitrary keys, etc, so this doesn't really need to be defined by
us. But I'm also happy to consider looking at that as well.
But, as with many things, the best way to bring things to our
attention is to file bug reports describing what you would like to see
- posting here is fine as well to start :)
Bill
On Dec 4, 2009, at 10:08 AM, Richard Dobson wrote:
Indeed; unlikely we will get to a stage of a single file format that
does solve everything; the tendency of carbon-based lifeforms to
think up new stuff does indicate against it. CAF (as CoreAudio to
some degreee I am not yet sure of) supports first-order B-Format;
and that is a format that can exhaust 32bit WAVE files relatively
quickly (talk of 3rd-order files (16chans) is commonplace, amongst
those who talk about such things). CAF would be a natural container
for it; but it would have to add a lot more channel definitions to
the current WXYZ. I would probably have concocted something myself
by now, but the Ambisonic cognoscenti have argued for at least ten
years on what metadata, normalization and channel names (and orders)
to define, for the ultimate do-everything format (including lossless
compression of course), with little sign so far of them agreeing. In
the meantime, libsndfile also supports my very modest but widely
used .amb file format :-). Nothing more complicated than a custom
WAVE_EX guid. Would be nice to see that supported in CoreAudio etc...
Richard Dobson
Paul Davis wrote:
On Fri, Dec 4, 2009 at 7:34 AM, tahome izwah
<email@hidden> wrote:
Looks like AudioFile needs to do the same. Of course, ~now~,
everyone should
be using CAF instead anyway.
That's right, but unfortunately noone really does (except Apple of
course).
libsndfile has had support for CAF for quite some time, meaning that
its entirely possible to use CAF on other platforms in a portable
fashion. applications that use libsndfile for audio file i/o (which
any sane cross platform application would do) can offer users the
choice to use CAF as a default no matter what platform they are on.
not that CAF solves all the same problems as the iXML chunk for
RIFF/WAV, so the choice is still not entirely clear :(
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden