Usage Guidelines

iXML is the result of extended discussions between the various manufacturers of Field recorders, and editing systems. It is designed to standardise the exchange of metadata between these systems.

Some parts of iXML are new, others are intended to supercede existing metadata stored in a non standard manner. This would include the iSCENE=, iTAKE=, iTAPE=, iNOTE= metadata currently written by most recorders into the bext description field. Any existing practices should be continued in order to smooth adoption of a new standard, and any metadata which is repeated in the bext description, and in iXML should be the same. Reading applications should favour iXML if it is present, falling back to bext description if not.

All iXML parameters and objects are OPTIONAL. Readers must not assume that any particular parameters exist. Readers must pre-fill their anticipated values with their own preferred defaults before reading what they can from iXML. It is better for iXML writers to exclude an object or parameter than to simply add it with blank metadata, since reading applications may have a more useful personal default. which could be overwritten by iXML's blank data.

When updating information in an iXML object, the question arises of what to do if your new data exceeds the size of the existing iXML chunk. You have several choices, including completely re-writing the entire file. However, more useful options include : 1) The iXML writer may pad the iXML with white space when it is created, in anticipation of new data being added. We would recommend that this padding does NOT take the form of spaces_inside_ text fields, but rather between fields such that readers do not encounter rougue spaces which they must determine the function of. XML parsers will typically skip over white space outside of parameters. 2) Often the iXML chunk will be at, or near the end of the audio file. An iXML editor could then re-write the end of the file with the iXML chunk and any others it finds after iXML. Do NOT remove chunks you find after iXML - they are probably important to someone else. 3) Perhaps most simply, you can simply nullify the existing iXML chunk by changing the chunk header to 'oXML' or anything else, then write a new iXML chunk at the end of the file. Considering the relatively small size of iXML data, there is no problem with this approach even if it happens several times.

iXML writers can freely add Objects and parameters to iXML to define new private metadata, and most likely some of these parameters will ultimately make it into this specification. Hence readers must expect to see undocumented objects and parameters in iXML chunks. See the section 'Extending iXML'

UTF-8 / unicode notes
iXML commonly uses UTF-8 encoded text. However the specification does not define a specific encoding, and reading devices should also be prepared for 2 byte UTF-16 and other encodings. UTF-8 supports characters up to 0x7F with no encoding, but if you want to include higher ASCII chars inline with the text, you must encode them to UTF-8 2-byte representations before including them in a UTF-8 encoded iXML chunk.

UniqueID Generation
iXML writers often have the need to generate unique IDs for <FILE_UID> and <FAMILY_UID> objects. One recommend method for this is to create a text string based a series of parameters which together become unique. In order to create a 32 char UID which can also fit in the bext chunk originator reference field, we recommend:

<Manufacturer><Device><DeviceSN><Date><Time><Random><FileSetIndex>

- 3 chars for the Manufacturer ID: AAT, AVI, DIG, FOS, GAL, HHB, MTI, NAG, ZAX, etc...
- 3 chars for the Device ID: CAN, PMX, POR, etc...
- 5 chars for the Device Serial Number: 12345
- 8 chars for the date: YYYYMMDD
- 6 chars for the time: HHMMSS
- 3 chars for pure random digits that can very well be the millisecond in the given time second, to ensure that two generations occurring in the same second have a different UID.
- 4 chars for the file set index. These 4 digits are set to zero in the <FAMILY_UID> and to the <FILE_SET_INDEX> value in both the <FILE_UID> and BEXT Originator Reference of every files in the set.

This makes a total of 32 chars that perfectly fits in the BEXT Originator Reference.


Example:

A 4 channels recording + 2 channels mix file set generated by Pyramix SN#17654 on August 5th 2005 at 2:45:05PM would look like this:

All file: <FAMILY_UID> = MTIPMX17654200508051445053840000
File 1: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840001
File 2: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840002
File 3: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840003
File 4: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840004
File 5: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840005
File 6: <FILE_UID> and Originator Reference = MTIPMX17654200508051445053840006

The primary objective is to create a string which will be truly unique across all recorders, all countries, all devices. IN some cases it may be useful to encode information into the UID aswell for your own internal use, without affecting its usefulness as a UID.

The iXML specification is totally without any requirement to license or qualification of use. This specification document was drawn up by Gallery UK. Any comments or requested supplements / changes to this document should be sent to metadata@gallery.co.uk

The iXML logo may be used by officially iXML Compatible devices which have a published iXML Implementation chart. The logo may be used without specific license, but the logo design itself is © Air Inc. Ltd.

The iXML specification is released to the public domain but the specific documentary text describing iXML on this site is © Gallery UK and may not be reproduced in whole or in part without permission.