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