Advice
By Media
By Stage

Metadata and Audio Resources

Comments (0)

Summary

Working with metadata can be a very time-consuming and resource heavy activity, so it is important to have a firm understanding of your objectives before initial decisions are made. Before reading this advice document, it is worth familiarising yourself with the document An Introduction to Metadata.

Introduction

Metadata is essential in providing the means to describe, share, search, manage and preserve our digital resources, ensuring maximum potential for use and re-use throughout their lifecycle. The selection of metadata, and its management and administration, should be tailored to meet the specific needs of the collection and its various users, and follow established best practice, where it exists, within the community in which you are working. While metadata should be created focussing on the resource at hand, ideally some thought should also be made towards making it possible to share your data with other collections, catalogues and systems to maximise the potential use and re-use of resources.

Identifying required metadata

Preparing a set of specifications is a very good way to start the process of identifying metadata requirements. These specifications should be based on a survey of stakeholders' needs and attempt to describe both the resource at hand and to sketch out methods for searching, retrieving, managing and preserving the resource. As well as general questions about how best to describe your resource, at this stage some audio specific questions may arise like, for example: Will users want to search for keywords that are spoken in audio files which are not in the title? Is information regarding the analogue recording chain important to collection archivists or researchers? It is advisable to perform some research into common and popular schemas and vocabularies, with a view to utilising their features to your needs. See the advice documents; Putting Things in Order: a Directory of Metadata Schemas and Related Standards and Controlling your Language: a Directory of Metadata Vocabularies for in-depth information.

It is extremely worthwhile investigating other metadata systems in projects similar to yours. Finding out what members of your community (be it HE, FE, museum, archive etc) have implemented, and what (if any) standards they have used can produce invaluable information. This communication is also beneficial for spreading consistency and good practice within your immediate community. Metadata should accumulate over time, and it is important that this is taken into account to allow for future expansion, for input from all of the stakeholders involved.

Once you are clear in your objectives it will be easier to identify which schema or extension schema should be implemented to best meet the needs of the production staff, the repository and the users. Once these needs have been identified a draft list of required metadata can be drawn up.

Metadata standards and interoperability

In principle there is nothing wrong with taking your resultant list of metadata, indicating just how each field should be filled out (in practice, this might prove to be a lot of work) and to beginning to create a simple database record for each audio file. However, problems might occur if you later wished the share your collection with an outside institution. Further problems might also occur if you wished to use software tools to automatically extract your metadata and add them to the database.

For these reasons, working with interoperable standards in recommended. Digital audio metadata standards are in their infancy when compared to those developed to deal with generic resources and specifically for images and text. This is partly due to the extensibility of existing schemas and standards which can be adapted successfully to incorporate audiovisual resources.

With so many schemas, accompanying languages and vocabularies available, it can be difficult to build a route that encompasses the complexities or the simplicities of your collection. This is heightened by the fact that variations exist that can offer a lot of crossover amid similar ground.

Unfortunately however, the ‘definitive metadata standard', which can be used without modification, does not exist. As outlined above, your metadata needs are inextricably linked to the various needs of your own users, making a globally accepted ‘definitive metadata standard' impossible. Some modification (even if this is simply omitting some fields) will almost certainly be required to make the standard you choose fit your needs.

Dublin Core (DC) is a set of metadata elements which comes closest (so far) to a universally exchangeable standard, but not without compromise. With its very broad aim as a standard that can be used for any digital resource irrespective of type, DC can be criticised as not being detailed enough when it comes to dealing with specific resources. However whatever its failings, DC does provide a well defined core set of descriptors, is widely used and relatively straightforward to implement. Also in its favour, Simple DC can prove very useful in facilitating simple machine to machine data interoperability and is used commonly in data sharing protocols like the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH), Z39.50 and Resource Description Framework (RDF), among others, which facilitate the cross searching and sharing of information from one access point.

You may decide one particular schema is more suited to your needs than another. Or, perhaps more likely, that a number of different elements from several different schemas will best fit your needs. Schemas can be mixed together. When mixing elements from different standards into one record, problems can occur when attempting to share this data with other machines and systems, as usually they are set up to deal with one standard set of metadata at a time. To overcome this problem METS (Metadata Encoding and Transmission Standard) has been developed by the Library of Congress to provide an Extensible Mark-up Language (XML) 'wrapper' into which various metadata elements - perhaps using various standards used to describe one object - can be placed and read by another machine which understands the METS standard. It's possible, for instance to use Simple DC and Metadata Object Description Schema (MODS) for descriptive metadata, the METSRights schema for copyright information and PREMIS for preservation metadata (see below). You can see a populated METS record for a digital audio file which includes the extension schemas MODS and AudioMD

Another approach to mixing elements from different schemas is through the development of a metadata 'Application Profile' usually tailored to the needs of a specific domain or resource type. There is more detail on Application Profiles in the advice document Metadata Standards and Interoperability.

Mapping or crosswalking metadata

If you decide not to use an established schema ‘as is' but modify one or several to meet your requirements, interoperability need not be sacrificed. Metadata elements can be mapped between schemas. This involves approximating an element in one schema to an element (or multiple elements) in another. Although this map can be developed when it is required, it is not a foolproof operation and compromise will most likely be needed; an element from one schema may not have a direct equivalent in another, for instance.

If using an in-house schema, it is best to plan ahead and facilitate future mappings as you construct your set of metadata elements. Mapping can also prove useful if a set of older ‘legacy' metadata was inherited along with a collection and this to be added to a newer management system or database.

UKOLN have an extremely useful list of existing mappings between many popular schemas.

Management systems and metadata

Metadata handling can be closely associated with the choice of software management system. A system may be as simple as creating a small database with fields for the required pieces of descriptive information and the location of a digital video file on an internal hard drive. Such simple systems allow for infinite customisation and are usually relatively straight forward to develop. But for collections that perhaps require a more complex set of metadata, a a fully functioning Digital Asset Management System (DAMS) may be required. Dedicated management systems allow for more advanced operations and often support at least some commonly recognised metadata schemas. There are many different commercial and open source management systems available, so if you plan to acquire one you should, given the choice available, be able to fulfil your needs with at least one of them. A further point to note is that your choice of system can also be affected by local considerations such as the skills available to you in terms of staff and also the technical infrastructure of you institution. Therefore it may be worthwhile consulting with your IT department to ascertain which database software and systems can be supported.

Which information to record?

Structured metadata is divided into four main categories that contain information which is defined by the schemas or extension schemas being used:

Structural metadata. This is information about the structural relationship with other parent or family files and how the metadata relates to the file.
Descriptive metadata. This is information about the content of the digital file. The information recorded here is more curatorial than technical, and is the primary portal for users to access your resource. Data including File name, creator, associated dates, description, summary, locations etc should be standardised using a interoperable schema such as Simple DC or MODS.
Administrative metadata. This contains information about the analogue source material, the rights of the content and any preservation information. Information here provides support to the managerial team of the collection and researchers in organising and providing access to the resource. Information about rights, ownership and usage restrictions is also kept within the administrative metadata.
Technical metadata. To make good use of the digital object data is required which describes the technical qualities of the physical and/or digital object. This includes information such as channel number, bit-depth, sampling rate, and the unique file identifier. AudioMD, is an XML based schema that has been designed primarily for this purpose. It is soon to be superseded by AES-X098, developed by the Audio Engineering Society, upon its formal release.

Structural metadata

Audio files from analogue media, such as tape, may be relational to other files. For example one recording from a 1" multi-track tape will contain multiple tracks which will need to be examined in context with each other. If it is one take of a track, then the other takes will also need to be referenced, along with other related audio on that tape and others. Another example is when a digital file is an excerpt of a larger piece. By including information on the structure of the related digital content, the resource is shown in as broader context as possible. Building up an ordered ‘family-tree' as such of all the relational material should be accomplished within the structure of the metadata.

Information specific to time based media files, such as location points and markers within the files can be used to identify and locate important content. Furthermore individual files within multi-track arrangements require accurate pan position (generally via DAW (Digital Audio Workstation) automation) to recreate the original work. Again, this is included within the structural metadata.

Descriptive metadata

Descriptive metadata is the primary retrieval gateway for most end users. As such, the kind of information recorded is likely to be very specific. In order to make your collection interoperable, consider making use of elements from the Simple DC metadata set such as: Title, Creator, Subject, Description and Coverage. These can either be used directly, if they fit your identified requirements, or ‘mapped' to, from the elements you decide to use (see below). The MODS schema is another strong alternative.

Administrative metadata

Generally, administrative metadata assists collection managers in organising, providing access to and preserving digital collections. Such information may not directly describe the resource itself, but may provide useful, even vital data from elsewhere, such as legal rights or the source of a digitised video's content. METSRights is an excellent schema which can be used to describe intellectual property rights. MPEG's Rights Data Dictionary (or RDD) is a highly detailed rights management schema, often used in conjunction with MPEG-21.

The PREMIS (PREservation Metadata: Implementation Strategies) schema offers elements designed specifically to assist with the complex task of digital preservation and is used alongside other schemas in order to achieve this special purpose.

Technical metadata

Some technical metadata is required to make use of digital files, the file type for instance. Much richer technical metadata can often be automatically extracted from a file upon ingestion to a management system and so represents a large gain for little time outlay. AudioMD is a schema created specifically for describing the technical properties of digital audio.

Alternatively, Adobe's XMP (Extensible Metadata Platform) schema has elements which together form a very detailed description of digital audio material. XMP is usually used as embedded metadata (see below) but can also be imported and exported from a central management system. Another prominent contender for describing the technical aspects of digital audio is MPEG-7. This extensive schema offers audio specific elements which together paint a comprehensive picture of a digital resource. Adaptors may wish to select elements from such detailed schemas carefully, as it is easy to make descriptions too rich and so overburden cataloguing staff.

Vocabularies

Metadata schemas consist of well-defined elements and description of how these should be used. DC's ‘Title' element for instance is:

"The name given to the resource. Typically, a Title will be a name by which the resource is formally known... If in doubt about what constitutes the title, repeat the Title element and include the variants in second and subsequent Title iterations. If the item is in HTML, view the source document and make sure that the title identified in the title header (if any) is also included as a Title."

But the values which are used to populate an element's field are not necessarily as tightly controlled. Would the soundtrack to Stanley Kubrick's timeless movie be ‘2001: A Space Odyssey' or ‘Two Thousand One: A Space Odyssey'?

Authority lists and vocabularies are controlled lists of terms or names which institutions can draw upon in order to maintain consistency. While inevitably there are some caveats given its broad remit, the Library of Congress Subject Headings is perhaps the best known of these and offers several different authorities for searching names, subjects, titles etc. You may also want to consult more subject focussed vocabularies, which are listed in the advice document Controlling Your Language: a Directory of Metadata Vocabularies .

Using controlled vocabularies, whether from an existing list developed externally, or from one drawn up in house, provide consistency in use of terms and spelling. They will help to make sense of the collection in isolation and if used effectively can provide a sound basis for cross searching and data sharing with other similar collections.

An ISAN (International Standard Audiovisual Number) works in a similar way to a printed book's ISBN (International Standard Book Number), acting as a unique identifier for analogue or digital moving image works.

The International Standards Organisation (ISO) and similar organisation (such as the British Standards Institution) publish standards documents which can also help improve consistency. ISO 8601 for example, describes standard notation for time and date values. The IANA (the Internet Assigned Numbers Authority) list of MIME types should be used for classifying digital video file type and subtype (e.g. video/mpeg). These conventions can be drafted in to cataloguing procedures to improve uniformity. See our advice document on Vocabularies for more information.

Embedded metadata

There are two primary methods of storing metadata for audio, embedding it within the audio file wrapper alongside the audio data, or separately within a database of sorts. Which of these methods you choose to use is largely dependent on the scale of and/or objectives of the project you are undertaking. In some cases it may prove prudent to use both methods if resources allow, an example case being where files are intended for delivery and can be easily identified and used by users through the embedded metadata. All digital files hold some form of metadata, even if it's just the name of the file. A number of popular audio file wrapper formats allow for some further, albeit limited, metadata to be embedded in the file. These include the MP3 (using ID3 tags) and BWF formats. This information is designed to give users identification data for aiding playback. An example of the content embedded metadata can contain is this populated iXML data chunk, which has been designed to be used as a RIFF chunk inside a Broadcast Wave File. iXML has been designed to supersede the older BEXT chunk in BWF files and to support multi-channel files (along with sound for film) whilst allowing for simple BEXT information to conform with the European Broadcasting Union standard for BWF files (only time will tell of the popularity and ultimate success of ixml). More detailed information on the BWF format and the BEXT chunk can be found in this excellent user guide published by the Eurpopean Broadcasting Union.

On its own, embedded metadata provides a simpler option for small scale digitisation projects where resources to host and populate a separate system may not be available. On the other hand it can also work as a form of limited metadata backup if a separate metadata system were to fail or become corrupted. However, larger collections using only embedded metadata would be an impractical and unsustainable solution. Most large metadata systems allow for metadata to be kept in two locations, embedded and separately to strengthen the resource.

Using embedded metadata can also benefit users where information can be displayed in software audio file players, mobile devices, or optical disc players such as hi-fis or car stereos. This can achieve instant file identification or provide other track information at no extra effort. There are however, potential risks to be aware of when investing time in recording embedded metadata. If the file were to be become corrupt, then metadata may not be retrievable, Similarly if the file were to be lost, erased or misplaced, then not only the audio content but all the attached information will have gone, deeming the resource completely inaccessible. A scenario only bettered by storing metadata in a separate database.

Metadata for broadcast

Aside from the implementations discussed above, metadata in broadcast and production is collected using different approaches. Emphasis is placed more on technical metadata to assist broadcasters and technicians to seamlessly integrate files together. Systems made by popular developers such as Dolby utilise digital hardware to stream audio data alongside metadata.Metadata for newly created content

Collecting metadata is just as important when producing new audio recordings which may or may not be initially added to library or archive collections. A series of podcasts or audio recordings of interviews will have a wealth of information surrounding the file which should be stored as well as the audio data. However, the ability to do this will likely depend on resources and the objectives of the project. Collecting this information is useful for current and future users, the preservation of the resources, any future integration of the resources with an existing repository, and will have a significant effect if the commercial or intellectual value of the resources changes. Regardless of producing new or digitising existing content, recording metadata allows for the recording of rights clearance and copyright information which needs to be managed during the entire lifecycle of a digital audio file.

Conclusions

There is no ‘one-size-fits-all' solution when it comes to implementing a metadata schema for audio. Every resource is unique and and may have idiosyncrasies that can impact upon the decisions of how best to record your metadata. There are steps, however, that you can take to ensure that the system you choose is best suited for your resource, and preparation is a key factor. Understanding the specific needs of all your users as well as the bigger picture of how your resource can harmonise with existing internal and external analogous collections is crucial to ensuring a successful outcome.

An effective method of selecting and using metadata is to begin by drawing up a set of requirements that will best describe the resource at hand. When complete, assess your requirements against available standard metadata and vocabularies, and investigate the approaches to metadata handling of collections with similar aims and objectives to your own. This approach will a) ensure your resource is described in a way that makes it fit for its intended purpose, b) potentially save you time in developing cataloguing rules and accepted field terms and mappings, and c) ensure a better likelihood that your resource will be interoperable with other related collections.

JISC Digital Media provide a helpdesk service and can assist by providing expert tailored advice on your own collection and the associated metadata.

Ask us a question

We provide a FREE enquiry service giving advice to the UK Further and Higher Education community.

You can ask us anything, typical questions include - "What formats should I use?" "How do I...?" "What tools can achieve the result I need?" "What is new and emerging?"