# Presentation: 526850

## Preservation Audio Using METS:The Sound Directions Project

- Robin Wendler
*r_wendler@harvard.edu*
- Harvard University Library
- 7 May 2007

## Goals

- “*Develop best practices and *_*test emerging standards*_ for archival audio preservation and storage in the digital domain”
_*Establish*__ __*programs for digital audio preservation*_ at each university that will enable us to continue this work into the future, and which will produce interoperable results
- “_*Preserve critically endangered, highly valuable, unique field recordings*_ of extraordinary... interest.”

- Participants
- Indiana University
-     (Archives of Traditional Music)
- Harvard University
-     (Archive of World Music)

**Notes:**
The goals for this project were very ambitious, and some have been met and some have not.  Both organizations now have programs for digital audio preservation, although IU’s preservation repository is still under development.  Both institutions have preserved thousands of critically endangered, highly valuable, unique field recordings. And both have tested emerging standards for archival audio preservation.  Development of best practices and interoperable results are not where we would like them to be. 

Much of the rest of this presentation is really about that discrepancy between where we are and where we know we should be, and about why it’s so hard to get there.

## Parallel Play

**Notes:**
Any of you with children know that there is a developmental stage called parallel play, where children enjoy pursing similar activities in the same space, but they do not yet know how to cooperate and play together. That is about where digital archives are now

## Context

- Harvard
- 7-year-old home-grown preservation repository
- METS profile created to meet internal needs
- Mixed PC/Mac-based audio studio
- Pyramix

- Indiana
- No preservation repository now; Fedora implementation in process
- METS profile created for this project
- PC-based audio studio
- WaveLab

**Notes:**
Not only are Harvard’s and Indiana’s technical environments different, but Harvard has been archiving digital audio for several years. This means that Harvard implemented METS to meet its own internal requirements, and changing that would mean major redevelopment of tools and workflows plus large scale retrospective conversion of existing objects. Harvard’s audio METS design was influenced by a strong conviction that commercial tools and standards will be most supportable for rendering audio to end users and for subsequent re-engineering the objects as necessary. Thus Harvard’s METS is optimized for delivery back into commercial audio workstations, so that neither engineers nor users would interact directly with the METS. Indiana  believes it will easier to write and maintain their own audio presentation tools for users, and they have experience with this in the Variations projects. However, they are in the early stages of implementing a preservation repository and have not done quite as much planning for how to present archival files back to an engineering workstation. So H and IU have come at this from very different perspectives

## Sound Directions: Scope of interoperation today

- Preservation archiving and exchange *only*
- No end-user delivery required
- No descriptive metadata required
- Exchange  Ingest  Re-export

**Notes:**
Because of the enormous difference between the two universities’ practices, for this phase of the project the scope is quite narrow. We are leaving descriptive metadata and end-user delivery out of this phase. The libraries must show that they can exchange their digital audio objects, ingest each others, and re-export them intact to the original partner.

## Audio file format
AES31-2-2006 (Broadcast Wave)
Audio decision list
AES31-3-1999 
under revision to include markers
Archival packaging
METS
Technical metadata
AES Audio Object (in draft)
Digital provenance metadata 
AES Process History (in draft) 

- AES31-2-2006 (Broadcast Wave)
- Audio decision list
- AES31-3-1999
- under revision to include markers
- Archival packaging
- METS
- Technical metadata
- AES Audio Object (in draft)
- Digital provenance metadata
- AES Process History (in draft)

- Standards Used in Sound Directions

- Indiana using current version
- Harvard using new draft

**Notes:**
It was very important to both universities to adopt open standards, and there are many areas in audio processing where standards come into play. Doing this has helped us even when our choices of which versions to use and which options to adopt within a standard have differed. Apart from METS, the key standards for this project come from the Audio Engineering Society (AES). 

The audio file format is Broadcast Wave. The edit decision list is AES31-3. Indiana is using the current version, which does not include native support for markers. They put nuendo markers in an extension chunk. Harvard is using the new draft, which does include native marker support. Just this morning I learned that the proposal has been accepted to develop the new version in XML instead of as a text file, which will integrate better with METS and enable Unicode support, both of which are important steps forward.

Technical metadata for audio files and digital provenance metadata for each object are expressed using draft standards from AES.

## Digital Audio Object = What?

- Song?
- Performance?
- Capture Event?
- Side/Track?
- Physical Item?

- For archival preservation,
- we create one METS for each original piece of media.
***This does not prevent presentations based on other structures.***

**Notes:**
One of the earliest discussion centered on what kind of object was being modeled, that is, what would an archival object for preservation audio correspond to? There are many ways to model audio objects, but because of the archival nature of both collections, we easily agreed to create one METS per original piece of media. For rendering purposes, however, other presentations may be created, for example by using SMIL to deliver in a single presentation audio that is split across several separate METS objects.

## METS Sections Used

**M**
**E**
**T**
**S**

**Header**

**Descriptive **
**Metadata**

**Administrative **
**Metadata**

**File Section**

**Structure Map**

**Source Metadata**

**Technical **
**Metadata**

**Digital Provenance **
**Metadata**

**Notes:**
Rights being documented and tracked by each participating institution, but are not covered in this exchange.

## Source media

- Preservation master (in 1...n files)

- Preservation master intermediate (1..n)

- Production master (1..n)

- Deliverable(s) (1..n)

- techMD: Audio Object

- techMD: Audio Object (1..n)
- Audio Decision List (Harvard)

- techMD: Audio Object (1..n)
- Audio Decision List (Indiana)

- techMD: Audio Object (1..n)
- Audio Decision List

- techMD: Audio Object (1..n)
- SMIL (Harvard)

_*AUDIO VERSION*_

_*METADATA*_

**...****Plus one digiprovMD for the entire project**

**Notes:**
In the course of audio preservation, engineers will work with many different versions of the content. Metadata will be created and retained for all of them, but not all versions of the content will be kept.  
There is always a source object, analog or digital, for which technical metadata will be created 

## Toolfest

- Extensive set of small, modular tools and scripts

- Add markers
- Add pan entries
- Add to process history
- ADL dump
- ADL fix
- ADL info
- ADL interleaver
- ADL path substitution
- ADL source
- ADL to SMIL
- ADL to XMLBWave concatenate
- BWave cut
- BWave edit
- BWave info

- Calculate checksum
- Compare checksum
- Convert markers
- Convert SMIL
- De-interleaver
- Edit ADL header
- Generate USID
- Generate UUID
- Get pan maps
- Interleaver
- JHOVE
- Marker dump
- Make MBIT+ditherer MD
- Make RA producer metadata
- Make resampler metadata

- Make RmEditor metadata
- Mirror project
- Make RA tech metadata
- Reverse audio
- Time code dump
- Time code/sample convert

**Notes:**
As far as the tools go, I’m just going to talk about Harvard. Most of them are not specific to Harvard’s infrastructure and could be reused in other environments. All will be made available as open source.

## Now we’ve got all the parts. How do we make a METS?

- Populate directory on a file system
- Run one tool (DMART) to construct an audio deposit package
- mets.xml
- Including
- Audio object technical metadata
- Process history metadata
- ADLs
- Referencing external files
- Archival master audio
- Production master audio
- Deliverable Real Audio
- SMIL
- a batch.xml file containing administrative metadata about the deposit.

**Notes:**
Copy all the content files and metadata files into a specified directory structure. 

## File Groups

**M**
**E**
**T**
**S**

**Header**

**Descriptive **
**Metadata**

**Administrative **
**Metadata**

**File Section**

**Structure Map**

- <fileSec>
-      <fileGrp ID=“Wave”> ... </>
-      <fileGrp ID=“Real”> ... </>
-      <fileGrp ID=“AES31”>... </>
-      <fileGrp ID=“SMIL”> ... </>
- </fileSec>

- <mets:fileSec>
-      <mets:fileGrp ID=“files-audio”>
-           <mets:fileGrp ID=files-audio-preservation”
- 	USE=“PRESERVATION_MASTER “> ... </>
-           <mets:fileGrp ID=files-audio-preservationInt”
- 	USE=“PRESERVATION_MASTER_INTERMEDIATE”>...</>
-           <mets:fileGrp ID=files-audio-production2496”
- 	USE=“PRODUCTION_MASTER”> ... </>
-      </mets:fileGrp>
-      <mets:fileGrp ID=“files-aes31” USE=“ADL”> ... </>
-      <mets:fileGrp ID=“files-doc” USE=“descMD”>... </>
- <mets:/fileSec>

- Harvard

- Indiana

**Notes:**
So how are we using METS? I don’t have time to compare our use of all the sections, but suffice it to say that not one are we using exactly the same way. For us to interoperate, we must invest in changing our existing tools and processes or invest in conversion programs to change what we produce into a commonly-agreed upon form. 

There are a few main points I’d like to bring out here.  
Notice that Harvard is categorizing files by their format, while Indiana is categorizing them by their use. Both of these are legitimate approaches, and just serve to illustrate that there is no one right way to implement METS, even for one kind of digital object.

Both libraries felt the need to inventory here in the fileSec files that are function as metadata for the digital object. Today this is the only way to use the METS to convey checksum information to allow the receiving institution to check external files that are part of the exchange package for validity. The METS Board is looking into alternative approaches.

## One structMap Approach

**M**
**E**
**T**
**S**

**Header**

**Descriptive **
**Metadata**

**Administrative **
**Metadata**

**File Section**

**Structure Map**

- Indiana

- <mets:structMap TYPE="**logical**">
-   <mets:div TYPE="**recording**" LABEL="**atm_99003**">
-     <mets:div TYPE="**face**" LABEL="**atm_99003_01**">
-        <mets:div TYPE="**section**" LABEL="**Section 1**" ORDER="**1**">
-            <mets:fptr>
** **	<mets:area
- 	       FILEID="**file-atm_99003_010101_preservation**"
- 	       BETYPE="**TCF**" BEGIN="**00.00.00.00*0000**"
- 	       END="**00.13.25.03*2778**" />
**  **         </mets:fptr>
-            <mets:fptr>
**                   **<mets:area FILEID="**file-atm_99003_010101_preservationInt**"
- 	     BETYPE="**TCF**" BEGIN="**00.00.00.00*0000**"
- 	     END="**00.13.25.03*2778**" />
**           ** </mets:fptr>
-             <mets:fptr>
**                    ** <mets:area FILEID="**file-atm_99003_01_production2496**"
- 	     BETYPE="**TCF**" BEGIN="**00.00.00.00*0000**"
- 	     END="**00.13.25.03*2778**" />
** **           </mets:fptr>
** **    </mets:div>

**Notes:**
Remember I said that Indiana plans to render the audio from the METS? For this reason, while they keep the ADL, they also convert it into a logical METS StructMap, listing the archival, production, and deliverable versions of the content for each segment.  

## Cross-fade splice

**M**
**E**
**T**
**S**

**Header**

**Descriptive **
**Metadata**

**Administrative **
**Metadata**

**File Section**

**Structure Map**

- Indiana

- <mets:fptr>
-    **<mets:par>**
** **     <mets:area
-           FILEID="**file-atm_99003_010101_preservation**"
-           ADMID="**fade1**" BETYPE="**TCF**"
-           BEGIN="**00.27.51.15*0264**"
-           END="**00.27.51.15*2184**" />
** **     <mets:area
-            FILEID="**file-atm_99003_010201_preservation**"
-            ADMID="**fade2**" BETYPE="**TCF**"
-            BEGIN="**00.00.35.13*0721**"
-            END="**00.00.35.13*2641**" />
** **   **</mets:par>**
** **</mets:fptr>

**Notes:**
It is often necessary to splice audio files using a cross-fade technique. This can be expressed in a METS structMap using the  <par> element to indicate that the two files should be rendered at the same time for the duration of the fade.

## Alternative structMap

**M**
**E**
**T**
**S**

**Header**

**Descriptive **
**Metadata**

**Administrative **
**Metadata**

**File Section**

**Structure Map**

- Harvard

- structMap TYPE="**LOGICAL**">
-   <div>
-     <div LABEL="**archival**">
** **      <fptr FILEID="**archival_2FAWM_5FDAT_5F172_5Fside_5F1.adl**" />
-        <div LABEL="**archival_2FAWM_5FDAT_5F172_5Fside_5F1Media**">
** **           <fptr FILEID="**AWM_5FDAT_5F172_2Fside_5F1l.wav**" />
** ...**
**   **<div LABEL="**production**">
**     **<fptr FILEID="**production_2FAWM_5FDAT_5F172_5Fside_5F1.adl**" />
**     **<div LABEL="**production_2FAWM_5FDAT_5F172_5Fside_5F1Media**">
-            <fptr FILEID="**AWM_5FDAT_5F172_2Fside_5F1_.wav**" />
- ...
-   <div LABEL="**deliverable**">
-      <div LABEL="**deliverable_2Fsmil**">
** **       <fptr FILEID="**AWM_5FDAT_5F172_2FDeliverable_2F.smil**" />
** **    </div>
-      <div LABEL="**deliverable_2Fperformances**">
** **       <fptr FILEID="**AWM_5FDAT_5F172_2Fdeliverable_2F1.rm**" />
- ...
** **

**Notes:**
Harvard is not driving delivery off the METS, and the lead audio engineer believes that the ADL, being a standard native to the audio community, is a better choice for expressing the internal structure of the content, since audio workstations that will never understand METS will understand ADLs. For that reason, Harvard’s structMaps have never attempted to express the playlist, but invoke ADL and SMIL to support end-user delivery. 

## Different expectations drive different choices

- Role of METS for audio
- Navigation of content for end users
- Navigation of content for audio engineers
- Interaction of METS and audio standards
- Should file references within AES metadata reflect METS internal structure or unpacked directory?

## The way it  works now

**Indiana**
**Converts**
**For**
**Ingest**

**Harvard**
**Converts**
**For **
**Ingest**

**Harvard**
**Audio**
**METS**
**SIP**

- The way it  works now

**Indiana**
**Audio**
**METS **
**SIP**

**Harvard**
**Repository**

**Indiana**
**Repository**

**Notes:**
At this point, the audio labs are generating digital objects and pass them both to it’s own repository and to the partner institution for conversion and ingest. The partner then archives the other’s object and can re-export it back to the originating institution. Proof of concept exchanges have taken place at this point, but not full scale exchange.

## The way it should work

**Convert to/from Common Profile**

**Convert to/from Common Profile**

**Common **
**Audio**
**METS **
**DIP/SIP**

- The way it should work

**Indiana**
**Repository**

**Harvard**
**Repository**

**Harvard **
**Audio Object**

**Indiana **
**Audio Object**

**Notes:**
The long term intention is that audio labs in each institution will feed digital objects into their respective repositories, and the repositories would produce OAIS DIP/SIP packages compliant with a common profile for exchange.

## Sound Directions, 2005-2007

- Funded by grant from National Endowment for the Humanities (U.S.)

- _[http://](http://www.dlib.indiana.edu/projects/sounddirections/index.shtml)__[www.dlib.indiana.edu/projects/sounddirections/index.shtml](http://www.dlib.indiana.edu/projects/sounddirections/index.shtml)_

- Thank you!

- Interaction of METS and audio standards
- References within AES metadata: should they be correct within archival package or correct once unpacked?
- In what applications/contexts will the content be used?
- End users
- Audio engineers

## Things Harvard wishes it did differently

- Don’t keep Mac Creator Codes.
- We plunk in boilerplate ones, not the ones that actually apply to files in the package. Don’t need any.
- Don’t keep waveform files
- New technology generates them in under a minute vs. 40 minutes formerly.
- Keep technical metadata for discarded intermediate content files as metadata, not as content. Don’t ask.

## METS Element

- Harvard
- <mets xmlns="http://www.loc.gov/METS/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" OBJID="AWM_DAT_172" LABEL="AWM_DAT_172" TYPE="AUDIO_SIP" PROFILE="Harvard" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd">
- Indiana
- <mets:mets xmlns:mets=_[http://www.loc.gov/METS/](http://www.loc.gov/METS/)_ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink=_[http://www.w3.org/1999/xlink](http://www.w3.org/1999/xlink)_ xmlns:marc21=_[http://www.loc.gov/MARC21/slim](http://www.loc.gov/MARC21/slim)_ xmlns:rights=_[http://cosimo.stanford.edu/sdr/metsrights/](http://cosimo.stanford.edu/sdr/metsrights/)_  xmlns:aes="http://www.aes.org/audioObject"  xmlns:adlfade="http://www.dib.indiana.edu/xml/sounddirections/adlFade/" xmlns:ph="http://www.aes.org/processhistory"
-  xsi:schemaLocation="http://www.loc.gov/METS/://www.loc.gov/standards/mets/version15/mets.xsd      http://www.loc.gov/MARC21/slim://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd://cosimo.stanford.edu/sdr/metsrights/  http://www.loc.gov/standards/rights/METSRights.xsd://www.aes.org/audioObject http://www.dlib.indiana.edu/lib/xml/aes/audioObject.xsd://www.dib.indiana.edu/xml/sounddirections/adlFade/ http://www.dlib.indiana.edu/lib/xml/sounddirections/adlFade/adlFade.xsd://www.aes.org/processhistory http://www.dlib.indiana.edu/lib/xml/aes/processHistory.xsd"
- ID="atm_66127_ot6584">

## Header

- Harvard
- <metsHdr CREATEDATE="2007-02-09T15:58:34" RECORDSTATUS="PROD">
- 	<agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="DepositingAgent">
- 		<name>Harvard College Eda Kuhn Loeb Music Library</name>
-  	</agent>
- </metsHdr>
- Indiana
- <mets:metsHdr CREATEDATE="2007-03-08T08:01:10">
-        <mets:agent ROLE="DISSEMINATOR">
-           	 <mets:name>Indiana University</mets:name>
-        </mets:agent>
- </mets:metsHdr>

## Descriptive Metadata

- Harvard
- [1]	<dmdSec ID="DmdSec">
- 		<mdWrap ID="dmd" MIMETYPE="text/xml" MDTYPE="MODS" LABEL="is part of collection">
- 			<xmlData>
- 				<mods xmlns="http://www.loc.gov/mods/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-0.xsd" version="3.0"> ...
- Indiana
- [1]	<mets:dmdSec ID="atm_66127_ot6584-dmd-marc">
-        	<mets:mdWrap MDTYPE="MARC">
-            		<mets:xmlData>
-               			 <marc21:collection>...
- [2]	<mets:dmdSec ID="atm_66127_ot6584_01-dmd-index">
-        	<mets:mdRef MDTYPE="OTHER" OTHERMDTYPE="atm_index" LOCTYPE="URL"
-            xlink:href="atm_66127_ot6584_01_production2496_20070126.doc"/>
-    	</mets:dmdSec>

## Source Metadata

- Harvard
- 	<sourceMD ID="original_2Fcoreaudio.xmlTechMD">
- 		<mdWrap ID="original_2Fcoreaudio.xml" MIMETYPE="text/xml" MDTYPE="OTHER" OTHERMDTYPE="AESCoreAudio">
- 		<xmlData>
- 			<audioObject xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:tcf="http://www.aes.org/tcf" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.aes.org/audioObject" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.aes.org/audioObject http://hul.harvard.edu/ois/xml/xsd/drs/audioObject.xsd" ID="_11683680708410.3702112802312034" title="BACA Folk Arts '96 Week 5: Indo-Caribbean and African at Brooklyn Children's Museum" analogDigitalFlag="PHYS_DIGITAL" disposition="Returned to Loeb Music Library" schemaVersion="1.03b" xsi:type="audioObjectType">
- Indiana
- <mets:sourceMD ID="atm_66127_ot6584-source">
-            <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="AESCoreAudio">
-                <mets:xmlData>
-                        <aes:audioObject ID="atm_66127_ot6584-ao" title="Belgian Congo and Ruanda-Urundi, 1951-1952."

- Audio on deteriorating media
- Analog and digital
- Analog formats in decline
- Recording devices
- Players
- Replacement media

- © Simon Bierwald. http://www.flickr.com/photos/indeed/75622824/

**Notes:**
For many years the audio preservation community did not accept digital reformatting, due to fears about quality and persistence. Three factors changed that: 

## Technical Metadata

- Harvard
- <amdSec ID="AmdSec">
- 	<techMD ID="archival_2FAWM_5FDAT_5F172_5Farchival_5Fside_5F1_5FMedia_2FAWM_5FDAT_5F172_5FAM_5F01_5F01_5F_7B52A7EEB3_2D1ED4_2D4FA3_2D8385_2DC008F6F047F5_7D.xmlTechMD">
- 		<mdWrap ID="archival_2FAWM_5FDAT_5F172_5Farchival_5Fside_5F1_5FMedia_2FAWM_5FDAT_5F172_5FAM_5F01_5F01_5F_7B52A7EEB3_2D1ED4_2D4FA3_2D8385_2DC008F6F047F5_7D.xml" MIMETYPE="text/xml" MDTYPE="OTHER" OTHERMDTYPE="AESCoreAudio">
- 			<xmlData>
- 				<audioObject xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:tcf="http://www.aes.org/tcf" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.aes.org/audioObject" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.aes.org/audioObject http://hul.harvard.edu/ois/xml/xsd/drs/audioObject.xsd" ID="_11704511308900.11208489734956295" title="BACA Folk Arts 1996 Week 5: Indo-Caribbean and African at Brooklyn Childrens Museum" analogDigitalFlag="FILE_DIGITAL" disposition="Deposited into DRS" schemaVersion="1.03b" xsi:type="audioObjectType">
- Indiana
-  <mets:amdSec ID="atm_66127_ot6584-amd">
-        <mets:techMD ID="atm_66127_ot6584_010101_preservation-aesCoreAudio">
-            <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="AESCoreAudio">
-                <mets:xmlData>
-                    <aes:audioObject ID="atm_66127_ot6584_010101_preservation-ao"