hi, [i just (re)subscribed to this list after i unsubscribed about 15 years years ago...surely i missed something (it's a pity that the list archives aren't searchable, btw)]
i'm writing as the lead (and sole) developer of the libambix library [1] that was designed as a reference implementation of the ambix fileformat as described by nachbar et al. (2011). it seems that people are starting to use both the ambix fileformat and the libambix implementation, and this brings back an old issue of mine, which i would like to discuss: in their paper, nachbar et al. propose a UUID "49454D2E-4154-2F41-4D42-49582F584D4C" as a chunk identifier in the CAF file. unfortunately this UUID has a serious drawback: namely, it is none. at least, it is not a well behaved UUID, and as such it is not guaranteed to be unique - which is the sole purpose of a UUID. the CAF specs are very clear what is to be understand by a "UUID", namely a "unique universal identifier as specified by ISO 14496-1". the ISO 14496-1:2013 in turns refers to ISO/IEC 11578:1996 for the specifications of the UUID. the UUID specs know a few variants and give detailed instructions on how to generate a UUID of a given variant in order to ensure that any UUID is indeed "universally unique"; those specs were simply ignored when coming up with the UUID for ambix. therefore the libambix library proposes an alternative (well-behaved) UUID, namely "1AD318C3-00E5-5576-BE2D-0DCA2460BC89" (for those interested: this is a valid UUIDv5 (SHA-1 + namespace)) (libambix accepts the nachbar-UUID when reading ambix files, but exclusively uses the UUIDv5 when writing files). obviously this situtation has led to some confusion, as there now are two UUIDs, one of them being documented in a published paper, and the other being promoted by a reference implementation. i would therefore like to persuade all parties interested in using ambix to use a single (valid) UUID. obviously my preference is to drop the nachbar-UUID and use "1AD318C3-00E5-5576-BE2D-0DCA2460BC89". cheers, fgmasdr IOhannes [1] https://git.iem.at/ambisonics/libambix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://mail.music.vt.edu/mailman/private/sursound/attachments/20160510/18f68662/attachment.asc> _______________________________________________ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit account or options, view archives and so on.
