Whatever it is, if it's a 32-bit file format, it should be considered deprecated.
CAF is at least explicitly designed to be a 64-bit format. It's also designed such that during recording a crash of the app can leave a recoverable file behind by the way the header structures are designed, much like in the old days SDII files had that property and were thus a preferred choice of many in the audio field. https://developer.apple.com/library/mac/documentation/MusicAudio/Reference/CAFSpec/CAFSpec.pdf Any compression used should prioritize fast and CPU efficient decompression over max. compression ratio, because a file is compressed once, but decompressed many times, often on mobile devices. As such, an open standard that is implemented by many hardware devices would be rather useful. Apple Lossless comes to mind, which is fully documented and available under the Apache 2.0 license: http://alac.macosforge.org/ Ronald On 30 Oct 2012, at 12:01, "Michael Chapman" <[email protected]> wrote: >> There's also the possibility of a new version of Broadcast Wav (BWF). >> >> Dave >> > Thanks Dave, URL and/or other reference ??? > > > 'Native' CAF also has the possibility for 'W,X,Y,Z' so (again without > acknowledgment) I suspect that could be counted as a *.amb > variant. > > MPEG formats: anyone have the key URLs ? > > Technicolor ... started this round. > > Anymore ? > > Michael > > >> On 30 October 2012 09:40, Michael Chapman <[email protected]> wrote: >>> >>> "The thing that is really annoying, really frustrating, is that the >>> community that I am trying to serve (which includes me) keeps shooting >>> itself in the foot, incessantly, year after year, by arguing over the >>> same details, over and over and over." ED, Sunday. >>> >>> At the risk of another abortive cycle. >>> >>> We seem to have: >>> >>> Richard Dobson's *.amb >>> Widely used, widely accepted. >>> Problematic as order number increases. >>> Has the underlying *.wav problems (and advantages). >>> >>> Etienne Deleflie's 'UA' >>> I had thought this had been dropped in favour of >>> the fourth of these, so have rather taken my 'eye >>> off the ball'. >>> Perhaps Etienne could comment (he is one of the >>> author's of the fourth). >>> >>> The Graz Proposal of 2009. >>> This fell on stoney ground ;-(> >>> It was CAF based, and we did have promises of >>> a 'CafPak' from the 'WavPak' development team. >>> <http://mchapman.com/amb/reprints/AFF> >>> >>> The Kenticky Proposal of 2010. >>> The current situation is: >>> a library available at >>> <http://iem.git.sourceforge.net/git/gitweb.cgi?p=iem/ambix;a=summary> >>> and the unofficial documentation at >>> <http://iem.at/~zmoelnig/libambix/ambix_8h.html> >>> >>> I'll happily put up a webpage with URLs / links >>> to them all (and any others). >>> Even try a Wikipedia type table of 'what does/offers >>> what' (if the authors will assist). >>> (And genericlly these re not 'file format's so much >>> as 'interchange formats' (files, streams, ... .) >>> >>> Once we've got the facts straight perhaps we could >>> recommence on a solid basis ?? >>> >>> __________________ >>> > > [ . . . ] > > > > > _______________________________________________ > Sursound mailing list > [email protected] > https://mail.music.vt.edu/mailman/listinfo/sursound _______________________________________________ Sursound mailing list [email protected] https://mail.music.vt.edu/mailman/listinfo/sursound
