63
33
Sound Directions
Best Practices For Audio Preservation
3 Digital Files
T
his chapter explores critical issues related to the creation of preservation digital files, the
recommended target file format for preservation, the selection of local filenames, and the
verification of file data integrity.
3.1 Preservation Overview
Digital File Preservation Surrogates
All analog and physical digital audio recording formats deteriorate over time, degrading much
more rapidly than paper-based archival documents. Audio recordings rely upon reproduction
technology that adds wear, fosters deterioration, and eventually becomes obsolete.
51
For
these reasons, audio preservation has always required the creation of duplicate copies, often
called surrogates, which act as stand-ins for the original recording.
52
It is now widely accepted that, for both technical and economic reasons, the preservation of
audio must rely upon transfer to, and storage in, the digital domain.
53
As stated in IASA-TC
04, “the integration of audio into data systems, the development of appropriate standards,
and the wide acceptance of digital audio delivery mechanisms have replaced all other media
to such an extent that there is little choice for sound preservation except digital storage
approaches.”
54
There is general agreement among sound archivists that data file formats are
preferable to physical carriers containing digital audio streams, such as DAT and CD, for
ensuring data security, monitoring data integrity, and managing preservation assets.
55
Our
target preservation format is now the digital file, which must be managed over the long term
in such a way as to ensure data integrity and trigger action when its specific format becomes
obsolete. These files may reside on a number of different types of carriers—data tape, hard
drives, optical discs—each with their own strengths and weaknesses. Audio preservation,
then, requires a long-term responsibility to the digital file.
56
If digital files are properly created
and well documented, they not only represent the best chance for preservation of the target
content, but carry a number of technical advantages over any analog surrogates that might
be produced, including the possibility of using automated processes in the creation of copies
that are of the same fidelity as the original files.
51 This reproduction technology includes not only playback machines, but such things as tape heads, disc
cartridges and styli, tools used to adjust the machines, service manuals used in repairing the machines, and
format-related supplies such as empty reels and splicing tape. It also includes the expertise necessary to optimally
use, align, and repair playback devices. All of these will become obsolete in time. For some formats, obsolescence
is already a serious issue.
52 See IASA, Technical Committee, IASA-TC 04, 4. The term “surrogate” is particularly used in the image
preservation world.
53 These reasons include the near obsolescence and increasing cost of ¼”analog tape as well as past preservation
problems with this format, the consequent unavailability of tape machines, the difficulty in maintaining the highest
possible quality when migrating analog formats, and the flexibility and consequent expanded access options that
digital technologies afford, among others.
54 IASA, Technical Committee, IASA-TC 04, 2.
55 See IASA, Technical Committee, IASA-TC 04, 48 and 65; IASA, Technical Committee, IASA-TC 03, 8. See also
Kevin Bradley, “Memory of the World Programme: Risks Associated with the Use of Recordable CDs and DVDs as
Reliable Storage Media in Archival Collections - Strategies and Alternatives,” CI/INF/2006/1 REV (Paris: UNESCO,
October 2006), http://unesdoc.unesco.org/images/0014/001477/147782E.pdf.
56 This particular way of stating this idea comes from: Humanities Advanced Technology and Information Institute,
University of Glasgow and National Initiative for a Networked Cultural Heritage, “Preservation,” Chapter XIV in
The NINCH Guide to Good Practice in the Digital Representation and Management of Cultural Heritage Materials,
ver. 1.1 (NINCH, 2003), 198-213. Also available online: http://www.nyu.edu/its/humanities/ninchguide/.
57
34
Sound Directions
Best Practices For Audio Preservation
The digital file surrogate will gradually become the highest quality record of the original as
the original becomes more difficult or impossible to play due to media degradation and/or
format obsolescence. In time, it will become the only surviving record, bearing the original
content for use by future generations. Even if a recording has not yet deteriorated greatly,
digitization requires significant resources and it is unlikely that the means to repeat this work
will be available. These certainties carry many significant implications for audio preservation.
Therefore, utmost care must be taken in the creation of surrogates, and digital file roles
within the institution must be clearly defined and understood to ensure appropriate creation
and handling of different types of files.
Target File Format
There is general agreement in the audio preservation field that the Wave file format (.wav) or,
as more specifically recommended by IASA, AES, and the National Academy of Recording
Arts and Sciences, the Broadcast Wave Format (abbreviated BWF or BWAV), is the best
target preservation format.
57
Many audio file formats have been developed and used over the
years, some of which are now obsolete. The wider the use of a format within a professional
environment, the greater the chance that it will be broadly accepted and supported, including
the development of tools for migration to future file formats. Broadcast Wave is widely
accepted in the archival and professional audio engineering communities with literally
hundreds of thousands of hours preserved in BWF files. The Broadcast Wave Format is non-
proprietary, restricted in definition, contains assigned locations for specific metadata, and
has a sample-accurate time stamp. This is ideal for archival preservation.
The European Broadcasting Union (EBU) introduced the Broadcast Wave specification
58
in
1996 to facilitate the exchange of audio files between the increasing number of digital audio
workstations on different computer platforms in radio and television production. The format
is not new and is based on the widely adopted Microsoft Wave file format. BWF files are
essentially .wav files but more narrowly defined with additional restrictions on the types of
audio that they may contain. A BWF file also contains several extra data chunks
59
—the most
commonly used of which is called the <bext> or Broadcast Audio Extension chunk—into
which basic metadata may be entered. The audio contained in a BWF file can be reproduced
by any software that can read a .wav file, although software applications that do not support
the format will not be able to access the metadata in the <bext> chunk. A Broadcast Wave file
also carries an embedded sample-accurate time stamp that references the source timeline,
fixing its position in time. The time stamp facilitates the sequencing of related files on any
computer workstation that supports the format.
The Broadcast Wave Format was developed by the EBU as an “open” format—not tied
to any specific manufacturer’s hardware or software—allowing software developers and
standards organizations to support the format as an industry standard without the need to
address proprietary issues. BWF is neither application nor platform specific. The underlying
file format—.wav—is proprietary, owned by Microsoft. A BWF file maintains the usual
.wav extension, although some manufacturers and many users mistakenly believe that the
extension should be .bwf. To counter this misunderstanding, the term BWAV is increasingly
used to refer to the format even though BWF is the original abbreviation.
57 See IASA, Technical Committee, IASA-TC 04, 7. See also The Recording Academy, Producers & Engineers
Wing and Audio Engineering Society, “Recommendation for Delivery of Recorded Music Projects.” Note that later
in this section Sound Directions specifically recommends BWF as the target format for preservation.
58 The BWF specification is found in: EBU, “BWF – A Format for Audio Data Files in Broadcasting.”
59 A chunk—a basic building block of a digital file—is a self contained collection of data that contains a header
followed by the data itself. A file will contain a number of chunks.
61
35
Sound Directions
Best Practices For Audio Preservation
The Broadcast Wave Format allows for the entry of metadata into the header of the .wav
file. Because of the relatively small amount of information that may be included in the
header and the difficulty involved with editing each file when metadata is updated, the
Sound Directions Advisory Board suggested that, for archival institutions, a file header is not
an appropriate location for a complete, authoritative version of metadata relating to a file.
Nor is it a substitute for a full, external metadata creation and storage system. From within
our context—research archives with large audio holdings—we view the BWF <bext> chunk
as an appropriate location for “catastrophic metadata,”
60
that is, the information necessary
to interpret the contents of the file in the absence of the metadata system. In effect this is a
middle ground, where a limited amount of metadata that is unlikely to change and is easily
obtained is included in the file header.
While <bext> chunk metadata is insufficient it is important, and should be supplied for
eventualities such as these:
Files are exchanged with another institution and accompanying metadata is either lost
or not available
Files are disseminated to researchers who then, without permission, further distribute
files without accompanying metadata. In this case, header metadata would at least
suggest ownership and point to the origin of the files
61
Files are disseminated to researchers who lose the accompanying metadata
The metadata system either is temporarily unavailable or fails, or is not working
properly during a planned dissemination that includes a database lookup on the fly for
the most recent version of metadata
Files are made available to an access system that is owned by an outside organization
and archive-supplied metadata is either lost or not used
A file is corrupt, the filename is not obtainable, and the file must be examined using a
hex editor to gain clues as to its contents
The organization that produced the files does not yet have a sustainable metadata
system but is relying on maintaining accompanying metadata in an unsustainable
format such as a document produced by proprietary text-editing software
The name of the file is changed unintentionally
In addition, embedding metadata in the file itself might obviate the need for spoken
announcements or slates that identify content.
In a future that includes federated digital libraries holding content from a number of different
organizations as well as widespread privately-owned access systems for audio content of all
types, these scenarios do not seem implausible to us. There is ongoing research in the digital
library world into methods for machine-to-machine transfer and understanding of complex
digital objects, including both multiple versions of primary objects and metadata, that aims
to reduce the risk of content becoming divorced from its appropriate context.
62
Characteristics of Preservation Files
General guidance on the characteristics of preservation files in the BWF format and the
60 This term was coined by John Spencer of BMS/Chace.
61 Of course, files disseminated to researchers may not be .wav files, in which case the point is moot. We are also
not considering here intellectual property issues and contracts with researchers that govern when, or if, files may
be available for download to researchers.
62 See, for example: Open Archives Initiative, Object Reuse and Exchange.
http://www.openarchives.org/ore/.
How to C#: Convert Word, Excel and PPT to PDF C#.NET PDF Windows Viewer, C#.NET convert image to PDF file & pages edit, C#.NET PDF pages extract, copy, paste, C# How to C#: Convert Word, Excel and PPT to PDF.
paste jpg into pdf preview; copy a picture from pdf to word
54
36
Sound Directions
Best Practices For Audio Preservation
procedures used to create them can be found in both of the IASA best practices documents
as well as in the ARSC/AAA report that guided audio preservation in the 1980’s and 90’s
when analog tape was the target preservation format. This document cleverly points out that
the philosophical purpose of re-recording for the sound archivist is “saving history, and not
rewriting it.” Historical accuracy is the goal and, therefore, a “1-to-1” preservation transfer
of the original was advocated.
63
Unmodified transfer to the new format without subjective
alteration—forgoing the temptations of denoising or editing—remains a widely shared
principle of audio preservation processes in the digital world.
In addition to a “Preservation Master,” the digital preservation workflow generates numerous
types of files that serve different functions and have different characteristics, including files
for online streaming for example or files from which physical products such as CDs can be
made. These are described and explained in detail in the Recommended Technical Practices
section below. It is necessary to define the characteristics of each type of file produced in the
preservation workflow to enable future understanding of the role that a file plays, its value to
the institution, and its relationship to other files. Metadata that identifies a file’s function or
role must be preserved along with the file’s content.
The simple act of copying digital files does not incur the loss of fidelity inherent in analog
copying. If done within closed systems using error correction and including verification
using a checksum,
64
one digital copy should be identical to the next, with no loss of fidelity
from one “generation” to the next as would have been the case copying recordings from one
magnetic tape to another. (The integrity of data in digital files must be routinely checked,
however. Data integrity is the subject of section 3.2.4.)
Filenames
Creating structured, consistent, and well-formed local filenames supports local interoperability,
parse-ability, and efficient use for the preservation workflow only as long as the files are
controlled locally, that is, within the audio studio and/or curatorial unit. Files produced in
the preservation workflow require logically and consistently created unique identifiers that
match the content of the files with the metadata belonging to it. These unique identifiers
may be as simple as a number string that identifies a single file. For a digital repository with
a completely automated preservation workflow and robust external systems for handling
metadata, a simple number string may be all that is ever needed.
On the other hand, filenames can reflect catalog and preservation workflow information
in a human-readable form in order to facilitate a workflow that is either entirely or partly
manual. A meaningful local filename may provide a significant convenience, supporting a
particular workflow by quickly providing basic identification of files without the need to
refer to a metadata system. At this point in the development of audio preservation systems,
many institutions still rely on local filenames to carry content and to function as primary
identifiers.
What is critical to understand, though, is that filenames are not a reliable means of storing
information. They are for identification purposes only, and although they may contain catalog
and workflow information, they should not be relied upon as a database for cataloging or
other metadata. (An external metadata system should fulfill this function.)
63 Association for Recorded Sound Collections, Associated Audio Archives Committee, Audio Preservation: A
Planning Study (Silver Spring, MD: Association for Recorded Sound Collections, 1988), 21 and 107.
64 Computer-based storage media are formatted so that they are essentially error free. A system using such media
will warn the user if giving errors. This is quite different from digital audio formats such as DAT or CD that require
many levels of error protection and will, if necessary, interpolate data to correct errors.
VB.NET PDF - Convert Word, Excel and PPT to PDF C#.NET PDF Windows Viewer, C#.NET convert image to PDF & pages edit, C#.NET PDF pages extract, copy, paste, C# VB.NET PDF - Convert Word, Excel and PPT to PDF.
how to copy a picture from a pdf file; how to copy pictures from pdf file
56
37
Sound Directions
Best Practices For Audio Preservation
Filenames and file paths are especially significant to Audio Decision Lists (ADLs). The ADL
uses the file path and filename to locate related media. The workflow must account for the
filename’s role in this function. Typically, this means that, if upon deposit the repository
replaces a filename with its own unique identifier, then upon extraction from the repository
the original filenames must be re-instated. (Alternatively, upon ingest, the ADL could be
rewritten to reflect the unique identifier so that the filenames in the deposited ADL will be
correct upon extraction.)
File Data Integrity
Once a preservation file is created, assurance that it has not been modified accidentally or
purposefully during transmission from one location to another or during long-term storage is
necessary. Without this assurance it is not possible to claim that the preservation surrogate is
an authentic representation of the original. For preservation of the content information, the
OAIS reference model requires fixity information that documents the data integrity checks
which ensure that content has not been altered in an undocumented manner.
65
Preserved
digital content must be checked at regular intervals for data integrity.
66
Verification of data integrity is typically done using a form of redundancy check applied to
a file or group of files called a hash algorithm such as Message-Digest algorithm 5 (MD5)
that substitutes or transposes the data into a relatively small number called a digest. This
number serves as a digital fingerprint or signature of the target data. An algorithm such as
MD5 is substantially more accurate than error detection algorithms used in storage devices
and network protocols. This is a one-way process: it is impossible to reconstruct the target
data from the digest and it is statistically highly unlikely that two sets of data can have the
same digest. The term ‘checksum’ is widely used generically for this process even though,
strictly speaking, it refers to just one simple form of redundancy check. In the library and
archive community, MD5 is widely used and there are many software tools available for its
implementation. Another algorithm used in this community is SHA-1.
67
After a file is created, a Message Digest (often referred to as a checksum) is generated for the
file using software that produces the checksum value based upon an algorithm applied to
the data in the file. The integrity of the file may then be verified at any point by comparing
the originally-generated checksum value with a regeneration of the checksum from the file
in question. If the two values match, it is highly likely that the data in the file remains
unaltered. The algorithm is not an audio comparison utility such as may be found in some
audio software suites. Nothing is inserted into the file when a checksum is generated—the
value is stored in a separate checksum file by the generating software. This value may also
be stored with the technical metadata related to the target file in an institution’s database or
other metadata system.
In general practice an MD5 is calculated for a file using the entire contents of the file. In
the case of a BWF file this includes both the metadata in the <bext> chunk as well as the
audio content. In a preservation workflow it is often desirable to edit only the metadata while
maintaining the ability to separately verify the audio content. This is possible by using a
“chunk-specific” checksum that is applied to the audio content only, as described in section
3.2.4.4 below.
65 CCSDS, OAIS, 19 and 65.
66 See IASA, Technical Committee, IASA-TC 03, 9.
67 MD5 has been cracked, and it is now easy to produce “collisions” where two different sets of data have the
same message digest. This means that while MD5 is suitable for protecting against accidental file changes such
as corruption during storage or errors during transmission, it may not be effective within a security context that
is concerned with malicious behavior. Similar weaknesses have recently been demonstrated with another widely
used hash function, SHA-1.
41
38
Sound Directions
Best Practices For Audio Preservation
3.2 Recommended Technical Practices
3.2.1 Target Preservation Format
3.2.1.1 Best Practices
Best Practice 6: Use the Broadcast Wave Format for the preservation of audio.
Best Practice 7: Use the <bext> chunk of the Broadcast Wave Format for metadata that is
needed to interpret the contents of a file in the absence of accompanying metadata. Do not
use it as the authoritative source or for metadata that may change over time.
Best Practice 8: Include the local name for the file in the Description field.
Best Practice 9: Use the Time Reference field to provide a time stamp showing the location
of the file on a reference or destination timeline.
3.2.1.2 Rationale
As discussed above, the Broadcast Wave Format is ideal for archival preservation because it
is non-proprietary, restricted in definition, and has assigned locations for specific metadata
and a sample-accurate time stamp. BWF is a restrictive file format that can contain either
MPEG (Layer I or II), or PCM audio only. This is a distinct advantage over the general WAVE
file format that could contain any of the following codecs: PCM, ADPCM, µ-law, GSM,
CELP, SBC, TrueSpeech and MPEG-Layer III. This restriction will be valuable in identifying
the audio coding of objects. A further advantage of the broadcast wave file is the Broadcast
Audio Extension chunk, also known as the <bext> chunk. The <bext> chunk can contain
essential metadata. There is now strong support in the audio industry for BWF, with many
professionals using it because the time stamp can be transferred between digital audio
workstations. Applications that require audio files to be placed in either a specific order or
at a specific location can read the time stamp without the need to refer to a separate Edit
Decision List. This is particularly useful within an archival setting for preservation transfers
that must be stopped and restarted due to speed changes or preservation problems. This
results in multiple files that must be sequenced in the proper order for presentation to an end
user. In the past, workstations typically used a proprietary method for storing the time stamp
in a sound file, and the time stamp would rarely be useable with other workstation software.
The format is supported by industry leaders including Avid (maker of Digidesign’s Pro Tools),
Merging Technologies (maker of Pyramix), Yamaha (maker of Steinberg’s WaveLab) and
MAGIX (maker of Samplitude).
Non-changing metadata is entered into the BWF <bext> chunk to identify the contents
of a file in the event that it is detached from its metadata, as discussed above. Including
the local name for the file ensures that it is available within the file itself if the name is
unintentionally modified or if it is intentionally removed during normal ingestion into a
preservation repository.
3.2.1.3 Background
All of the metadata entered into the BWF <bext> chunk, plus much more, is also captured
VB.NET Imaging - Data Matrix Plug-in SDK Control Copy the following VB sample code to your barcode Sample.png") barcode.DrawBarcode( image, 150F, 150F) image.Save(ImageType into a certain page of PDF, TIFF, Word
copy pictures from pdf to word; how to cut an image out of a pdf
49
39
Sound Directions
Best Practices For Audio Preservation
in external technical metadata systems at both Indiana University and Harvard University. As
discussed above, we consider the BWF header as an appropriate location for “catastrophic”
metadata only at this time.
Note that the time stamp by itself is not enough to present seamless content when overlaps in
multiple preservation files from the recording process are edited out. In this case, an AES31-3
ADL is also required.
Also note that some organizations populate the BWF header from an in-house database,
requiring little effort by the audio engineer. Others have database applications that make use
of this metadata to find specific files. Because we have robust external search and discovery
utilities this latter use is of less value to us.
3.2.1.4 Use of the BWF <bext> Chunk at Indiana
In WaveLab, and other software, it is possible to establish defaults so that the metadata in the
BWF <bext> chunk copies from file to file, making its collection easy and efficient. At the
ATM, nearly all of the BWF metadata remains the same throughout a collection; typically,
we must update only the shelf number (incrementing by one digit), the original filename
(by cut and paste), and the origination date (at the start of each day) when moving from one
recording to the next within a collection.
3.2.1.4.1 Description Field
This field is designed to contain a free description of the sound sequence and may include
up to 256 ASCII characters. To aid software applications that only display a short sequence,
the EBU recommends that the essence of the description be contained within the first 64
characters. If the string contains fewer than 256 characters, the last one is followed by a null
character.
Here are the data elements we use:
[Collection ID] [Source Object ID] [File Use] [IUCAT Title Control Number] [Original
Filename]
Where:
Collection ID = ATM collection accession number
Source Object ID = the unique number that identifies the source of the file’s content—
usually the ATM shelf number
File Use = the role that the recording plays within the unit (ATM)
IUCAT Title Control Number = unique identifier for the collection within the Indiana
University Integrated Library System
Original Filename = the filename assigned to the file
A minimum of explanatory text introduces some of the elements. Here is an example:
File content: Collection 75-025-F number EC 5730. File use: Preservation Master. IUCAT
Title Control Number: BAA0584BT. Original filename: atm_75025_ec5730_010101_
pres_20070130
Explanation:
The first sentence contains perhaps the two most important elements of this string—the
45
40
Sound Directions
Best Practices For Audio Preservation
collection accession number and individual recording shelf number—from which all
documentation available at the ATM may be located. This sentence contains fewer
than 60 characters including spaces
The IUCAT Title Control Number is the unique number generated by the IU Integrated
Library System for the bibliographic record representing an ATM collection
The name of the file is included as the last element as a safeguard against the accidental
changing of the name, which would de-link it from its metadata. It is also possible that a
filename might intentionally change within a digital library setting, with the appropriate
reconnection of metadata to the new name and the tracking of the old name. In this
case, we think it might be useful to either the digital library or the organization that
generated the file to have a redundant copy of the original filename residing within the
file itself. Note that on Windows and most modern file systems, filenames are stored
separate from the files themselves. Adding the original filename into the <bext> chunk
ensures that it will reside with the actual file
3.2.1.4.2 Originator field
This field was created to contain the name of the originator/producer of the audio file and
may contain up to 32 characters. Although some DAWs will legitimately enter a reference
to themselves in this field, the ATM chooses to use this area to indicate the organization or
institution that created the file. The ATM uses this statement: IU Archives of Traditional Music,
which is, fortunately, exactly 32 characters.
3.2.1.4.3 Originator Reference field
The purpose of this field is to carry a unique identifier. The EBU has designed a format for
this field, which is one of many types of unique or persistent identifiers that might be used.
Because unique identifiers will be associated with ATM content by the IU Digital Library
Program, the ATM does not use this field.
3.2.1.4.4 Origination Date field
This field contains the date that the file was created using the standard ISO 8601 form of
yyyy-mm-dd (year-month-day).
3.2.1.4.5 Origination Time field
This field documents the time that the file was created. We do not enter any data into this
field, reasoning that within our setting documenting the exact time that a file was created has
little value compared to the time it takes to add this information.
3.2.1.4.6 Time Reference
This field contains the time stamp, documenting the start position on the reference or
destination timeline that this file should occupy. For the first Face (or side of a recording)
the value in this field is 0 as automatically generated by WaveLab. Additional Faces for a
recording will have a time stamp value greater than 0, representing their in-order location on
the timeline. In situations where multiple files were created for one Face, the time stamp for
each subsequent file would also be greater than 0, reflecting their appropriate positions on
the timeline in reference to the first file.
53
41
Sound Directions
Best Practices For Audio Preservation
3.2.1.4.7 Coding History
The Coding History field is designed to hold data on the digitizing process including signal
chain specifics, sample rate and bit depth, and other elements. It is defined as a collection
of strings, each presented on a separate line, containing a history of the coding processes
applied to the file. Each variable within a string is separated by a comma. A new line is
added when the coding history related to the file is changed, and each line should end with
a carriage return and line feed which are automatically added by WaveLab. According to
the EBU, each line should contain these elements, as appropriate to the coding history being
described:
68
Coding algorithm. String begins with “A=” For example:
A=ANALOG, PCM, MPEG1L3,
and others
Sampling frequency. String begins with “F=”
Bit-rate, for MPEG coding only. String begins with “B=”
Word length. String begins with “W=”
Mode—this corresponds to sound field, such as mono, stereo, or dual-mono. String
begins with “M=”
Text, free string—a free ASCII-text string for in-house use. The EBU suggests documenting
devices in the signal chain and analog source recording formats in this field. String
begins with “T=”
At Indiana, we include three lines of coding history in our BWF files for the digitization of
analog recordings. The first documents the analog source recording, the second contains
data on digitization chain, while the third records information on the storage of the file.
For example:
A=ANALOG,M=mono,T=Studer A810; SN3690; 15 ips; open reel tape,
A=PCM,F=96000,W=24,M=mono,T=Benchmark; ADC1; SN00252; A/D,
A=PCM,F=96000,W=24,M=mono,T=Lynx; AES16; DIO,
Line 1 reads: an analog open reel tape with a mono sound field was played back on a Studer
A810 tape machine with serial number 3690. Tape speed was 15 ips.
While the EBU document suggests including the tape brand and product number as the last
element, we prefer a general designation of the format for several reasons: it is more useful
to know the format than the specific brand and it avoids the need to interpret the brand
information and playback machine data to identify the format. When a range of formats—
analog cassettes, discs, DATs and others—are routinely digitized this interpreting might
become unnecessarily difficult. In addition, the format remains constant through an entire
collection (the brand and product number may or may not), providing one less element that
requires data entry for each source recording.
Line 2 reads: the tape was digitized in mono mode using a Benchmark ADC1 A/D converter
with serial number 00252 at 96 kHz sample rate with a bit depth of 24 bits.
68 European Broadcasting Union, Production Technology Management Committee, “Format for the
<CodingHistory> Field in Broadcast Wave Format files, BWF,” EBU Technical Recommendation R98-1999
(Geneva, Switzerland: European Broadcasting Union, 1999),
http://www.ebu.ch/CMSimages/en/tec_text_r98-1999_tcm6-4709.pdf.
24
42
Sound Directions
Best Practices For Audio Preservation
Line 3 reads: the tape was stored as a 96/24 mono file using a Lynx AES16 digital input/
output interface.
If we apply additional coding processes to produce a derivative file we add a fourth line in
the header of the derivative file. For example:
A=PCM,F=44,100,W=16,M=mono,T=Steinberg; WaveLab 6; Resampler, Waves L2; Dither;
DAW,
This line reads: A 16 bit, 44.1 kHz file was created using the WaveLab 6 Resampler and
Waves L2 Dither in the Digital Audio Workstation.
3.2.1.5 Use of the BWF <bext> Chunk at Harvard
In the <bext> chunk we populate the Description, Originator, OriginatorReference,
OriginationDateTime, TimeReference, and the Version fields. Entered in the Description
field is the owner supplied name of the audio file such as AWM_RL_0001_AM_01_01,
which means Archive of World Music Reel number 0001, Archival Master, side 1, file 1. The
Originator field is the name of the Pyramix DAW that created the file, either PyramixOne or
PyramixTwo. The OriginatorReference field contains the USID, or Unique Source Identifier. It
is a string that can be broken down into the Country Code (CH for Switzerland), Organization
Code (MTI for Merging Technologies, Inc.), Serial Number (PYRAMIX16934), Origination
Time (153213), and a Random Number (745780579). At this time our tools support the use
of the UMID (Unique Material Identifier) and the Coding History (description of coding
processes applied to the audio data), but we are not using either of them in our current
process.
Documents you may be interested
Documents you may be interested
