Powered by
JSPWiki v2.8.2
g2gp 17-01-2009
View PDF
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Digital Audio#

This Guide is still in draft format.

Section 1. Introduction to Digital Audio#

Section 2. Creating Digital Audio#

Section 3. Preserving Digital Audio#

Bibliography and Further Reading#

  • Aims and Objectives of Specific Guide
    • Background to the guide's focus in an archaeological context (uses)
      • what is #
      • applications of #, how is # used in archaeology

As with digital video, digital audio files have become far easier to create over the last ten years. Although digital video has perhaps found more applications in archaeology, digital audio files are often create as a component of projects looking to record oral histories or to recreate 'archaeological sounds', either through the modern reconstruction of archaeological musical instruments or through the recording or sounds within archaeological contexts such as reconstructed - physically or virtually - churches or henges/theatres etc. (NEED SOME EXAMPLES HERE E.G. INTARCH).

This guide aims to cover the issues involved in the creation and preservation of 'born digital' audio files and will not aim to cover the creation of files from analogue originals (although many of the issues raised here equally apply). The digitisation of analogue audio files is covered in detail in ... JISC DIGITAL MEDIA AUDIO FILE LINKS.

  • Creating # data
    • project planning and requirements
    • sources of data
original recordings material extracted from other sources e.g. video or 3D files
    • file types (whilst creating, working with, processing data)
    • documenting data creation and processing

  • Archiving # data
    • deciding what to archive
      • Selection and retention
      • preservation intervention points / file and data lifecycles (specific to guide, will also be covered generically)
    • deciding how to archive
      • archiving strategies (migration (to new format, to 'basic' format), emulation, refreshment)?
      • significant properties
      • file types
    • Metadata and Documentation
      • project level
      • file level
      • standards specific to #
    • Structuring your archive

  • Copyright
    • specific copyright considerations for each guide.

  • Case study/studies


DeliveryPreservationPresentationDocumentation Required
Waveform Audio .wav
Preferred format
Waveform Audio .wavAny one of the following compressed audio formats (preferably supplied by depositor):
Quicktime .mov
Real Audio .rm, .ra or .ram
Windows Media Audio .wma
MPEG-1 Audio Layer III .mp3
Ogg Vorbis .ogg
Software used to create/encode (if applicable)Bit rate (kbps) and sampling frequency range (KHz) if applicable. NOTE: mp3 and ogg both have the option of variable bit rate compression. Codec used (where appropriate) and documentation of conversion process. Length of recording (mins and secs). Copyright clearances (very important for audio files, especially oral history). Transcriptions of interviews etc (where appropriate).
Audio Interchange File .aif
Preferred format
(likely from Mac users)
Audio Interchange File .aifas .wavas .wav
SUN au.auWaveform Audio.wavas .wavas .wav

Notes on formats#

[also see preservation manuals]

.wav and .aif are uncompressed audio files and are therefore the only suitable formats for delivery and preservation. Whereas .wav is the default format for MS Windows, .aif is the equivalent on a Mac. As we work on Windows PCs, here at the ADS, .wav is the preferred delivery format.

SUN .au is a straightforward UNIX format, unfortunately not widely supported outside the UNIX community so therefore not suitable for preservation. We can accept these files and convert them to .wav for preservation. It should be noted that .au files are usually very slightly compressed so are often not as high quality as .wav and .aif files. We will accept .au files but depositors should be encouraged to use .wav or .aif if possible.

As well as a raw audio file (.wav, .aif, .au), depositors should also supply a compressed version of their audio files that we can use for web delivery. There are a wide number of different formats that we can accept for delivery. We can create these ourselves if need be but this will obviously require time and money!

In situations where the depositor supplies only the compressed version of their audio files (for example .rm, .wma, .mp3, .ogg), they should be strongly encouraged to send us uncompressed originals as well. It is possible that the device they recorded with saved directly to a compressed format. If for whatever reason the depositor can not give us uncompressed files, we can use a free conversion utility to convert the files back to an uncompressed .wav format. It should of course be noted that by converting back to .wav we will not be regaining any of the information and quality from the uncompressed original, we will just be creating a file that we can refresh alongside other preservation files in the future.

Future Directions#

A number of open source audio formats are being developed by Xiph.org (e.g. FLAC, Speex, Ogg Vorbis, etc.) and it may be that these become more widespread and therefore more suitable for us to accept as deposit and / or archival formats. FLAC (Free Lossless Audio Codec), as a file format that uses lossless compression (c. 40-50% reduction of file size) is the most likely of the Xiph.org formats to be of interest to us as a possible archival format for large audio files/collections. In terms of disseminations formats it is likely that MP3 will be superceded by the AAC/M4A developed by the MPEG group and currently used by Apple's iPod (see AHDS Moving Pic and Sound, p51 and Wikipedia: Advanced Audio coding).

Other formats#

If we receive formats other than those listed above we should contact the depositor and ask if they can supply the data in a format we support. If not need to inform them of our current practice. This is that we endeavour to transform the file(s) into an archive format if the software we have to hand can do this in a quick and automated fashion. If this is not the case we will archive the file(s) as is, but will be unable to migrate it to newer versions of that format.

How to transfer...#

Conversion of audio files can be a complicated process and this is why the best case scenario would be for the depositor to supply both compressed and uncompressed audio for web delivery and preservation.

When compressing audio for web delivery, we have to make decision about which codec (compressor/decompressor) to use. Compressing audio files will produce some loss of quality. Lossless codecs can be found (for example SHN (Shorten) and Apple Lossless) but they seem to only half the file size whereas MP3 can reduce a file to about a tenth of the original size. This inevitable loss of quality can be minimised by use of the correct codec. Different compressors can give very different results and choice of compressor may depend on the type of audio that has been recorded. MP3 may be a popular option for compressed digital audio but is designed primarily for music and is not designed to be streamed. Audio files deposited with the ADS are likely to be recordings of the human voice for oral history projects. As the human voice has a relatively small range, it is a good idea to compress it with a codec designed specifically for this purpose (for example the Quicktime codec Qualcomm Pure Voice), or the open source and free Xiph.org speex.

In actual fact the codec used will depend very heavily on the software available to us. In an ideal world, the ADS will not be required to do any file conversion, but if this is necessary we need to use free software to carry out the conversions. Unless expensive specialist software is purchased, we may not have a lot of choice as to the codecs available.

The easiest piece of software to use for the majority of straightforward file conversions is Audacity (http://audacity.sourceforge.net/). Alternatively, MediaCoder (http://mediacoder.sourceforge.net/) can be used though this is a more complex application.

If file conversions have to be carried out, follow the steps below:

  • All file conversions should be carried out on local versions of files.
  • The files in question should be copied from the server and a fastsum check carried out this file should then be compared with the checksum on the server.Before converting files

Check if there is any embedded metadata in the audio file. Many audio formats such as mp3 and those created by Quicktime and Windows Media Player have the facility to do this. Be aware of any metadata and remember to check the final version to see if it has been preserved. Metadata can be stored in an ASCII text file if all else fails.

Starting FormatProcedureEnd Format
.wav, .aif, .au1. Decide which presentation format to convert to (.ogg recommended though neither .ogg or .mp3 are ideal for the human voice!)
\2. open Audacity. Use 'File' => 'Preferences' then the 'File Formats' tab to adjust the settings for the export format.
\3. 'File' => 'Open' to open the file
\4. 'File' => 'Export as MP3' or 'File' => 'Export as Ogg Vorbis' to export files to desktop (need to download an encoder to export as MP3 or use the Lame option in Mediacoder)
\5. Listen to file, check length of file and carry out other checks as documented in the AHDS Audio Preservation Handbook
.ogg or .mp3
.au1. Open Audacity. Use 'File' => 'Preferences' then the 'File Formats' tab to adjust the settings for the export format.
\2. 'File' => 'Open' to open the file
\3. 'File' => 'Export as WAV' to export files to desktop
\4. Listen to file, check length of file and carry out other checks as documented in the AHDS Audio Preservation Handbook

Maximum (best) requirements for a deposited archive#

  • Both compressed and uncompressed audio files
  • All copyright issues clarified and documented
  • Full data documentation and transcriptions if appropriate
  • If depositor has used a file format that contains metadata, they should inform us of this so we can extract it and preserve, or ensure it's preserved in any future versions
  • Extract metadata from files if appropriate