[PD-dev] CAF file support?

[IOhannes m zmölnig]

On 4/20/19 11:08 PM, Dan Wilcox wrote:
> I'd also be up for an equivalent format, maybe RF64 which looks like a 64-bit WAV: https://en.wikipedia.org/wiki/RF64 <https://en.wikipedia.org/wiki/RF64> I'm not sure yet what could be consisted the "standard" for this. Maybe we should look at what files are used by Max, Ableton, etc.

when we (the IEM) designed the AmbiX fileformat (for higher order
ambisonics recordings) a couple of years ago, we looked for an open
"standard" fileformat that allowed us to have many channels which easily
exceed any 4GB limit (not to talk about 2GB limits as with most WAV
implementations).

in the end we opted for CAF, as it has (iirc) a much cleaner design all
attempts to engage WAV and 64bit.
e.g. RF64 seems (i forgot everything and just looked it up on the
wikipedia article dan linked to) to have a limitation of 18 (surround)
channels. wtf?

so yes. CAF would be a nice addition to support, although it can be a
very complex format. just supporting a basic set (a single PCM data
chunk) would be simple enough i guess.

I don't see any inherent problem with the 64bit format in
single-precision Pd (even with miller's suggestion to just skip the
header, you would only get into trouble if the header (and "early
chunks") would be longer than 2^24 bytes; whenever it comes to lengths,
you are mostly dealing with *frames* rather than *bytes*, so the numbers
should be scaled down reasonably anyhow; and of course, we want a
double-precision rather sooner than later anyhow)

gfmadsr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190422/25cb27b9/attachment-0001.sig>