Full name | Name of the format. Formal name, if the format has been established by a Standard Setting Organization (SSO), which include both Standards Developing Organizations (SDO) like ANSI and the various bodies it accredits in the US, or trade organizations, consortia, or other groups. For formats established by corporations, the common or colloquial full name is provided. Common names are also provided for standardized formats, when the formal name excludes colloquial elements. |
Description | Brief characterization of the format. |
Production phase | Indication of how the format is generally used during the content life cycle, e.g., by creators or authors (initial state), by distributors, publishers, or archives (middle state), or as delivered to endusers (final state). |
Relationship to other formats | Indications of the relationships between this and other formats, using statements of the types listed in the following rows. Intended to mesh with the work of the GDFR (Global Digital Format Registry). A handful of format descriptions include bracketed relationships that are not intended to be parseable, e.g., [Metadata specification from], found in EXIF_2_2. |
Has subtype | |
Subtype of | |
Contains | |
May contain | |
Used by | |
Based on | |
Defined via | |
Has earlier version | Preferred to Has Version |
Has later version | Preferred to Has Version |
Has version | Use when version is non-sequential (e.g., geographical) or when sequence is unknown |
Version of | Use when version is non-sequential (e.g., geographical) or when sequence is unknown |
Other | To be accompanied by an explanatory note |
Disclosure | Level of available technical information about the format, including documentation that requires purchase. Typical statements of level include open standard, fully documented, partially documented, and little documentation. The statement of level is followed by the identification of source or developer. More discussion: disclosure. |
Documentation | Citation of specifications or other documentation. For standardized formats, identification of relevant standard, generally by assigned number. A few individual documents are cited in this location; if the list is long (as it is for many multipart ISO/IEC standards), the complete list is provided in the Format specifications or Useful references sections at the bottom of the page. All documents cited in the table portion of the Format Description are cited again in Format specifications or Useful references below. |
Adoption | Assessment of the degree to which this format is implemented and employed. More discussion: adoption. |
Licensing and patent claims | Statement regarding patents and/or licensing. |
Transparency | Statement regarding the nature of the encoding and/or bitstream, suggestive of the ease with which rendering tools may be obtained or built. More discussion: transparency. |
Self-documentation | Statement regarding the degree to which the format supports the inclusion of metadata (descriptive, administrative, and structural). More discussion: self-documentation. |
External dependencies | Statement regarding the need for external software or hardware. More discussion: external dependencies. |
Technical protection considerations | Support by this format for elements that protect intellectual (or other) property. More discussion: technical protection. |
Normal rendering | Baseline for the behavior of content when presented to a user, e.g., images that permit zooming or sounds that can be played, stopped, and restarted. |
Clarity (support for high image resolution) | For still image and video formats. Does this format support the representation of pictures that would be deemed high resolution when viewed by experts or repurposed for a very high quality application? More discussion: still image clarity and video clarity. |
Fidelity (support for high audio resolution) | For sound and video formats. Does this format support the representation of sound that would be deemed high resolution when heard by experts or repurposed for a very high quality application? More discussion: sound fidelity and video fidelity. |
Support for multiple sound channels | For sound and video formats. Does this format support the representation of sound multi-channel audio, which is presented to the enduser at least two ways. The first is in terms of aural space or sound field, e.g., as stereo or surround sound. The second consists of two or more signal streams that provide alternate or supplemental content, e.g., narration in French and German, sound effects separate from music, or the like. More discussion: sound multiple channels and video multiple channels. |
Support for downloadable or user-defined sounds, samples, and patches | For sound and video formats. The degree to which this format permits references to or the inclusion of digital sound data and the articulation parameters needed to create one or more voices or instruments in a musical presentation. More discussion: downloadable samples and patches. |
Integrity of structure | For textual formats. The degree to which the navigation options and automated analysis made possible by the logical structure of a textual work is essential to its usability. More discussion: integrity of structure. |
Integrity of layout | For textual formats. The degree to which the look and feel, and exact choices of features such as font and column layout of a text document is essential to its meaning. More discussion: integrity of layout. |
Integrity of rendering of equations, etc. | For textual formats. The degree to which the accurate rendering of non-textual elements is key to the informational content of the document. More discussion: integrity of rendering equations, etc. |
Functionality beyond normal rendering | Support for features that serve users with special interests. For example, some users will prefer that vector-based images like those used for architectural drawings remain malleable (editable) so that they can be modified after being copied from a library collection, while other users may require that music notation formats, e.g., MIDI, permit the use of a variety of sounds or tone sets to mimic actual instruments or create new tones and timbres. Rich-data content, e.g., a still image with "extra bits per pixel," may be created to serve as a master, i.e., for use as a source for high quality repurposing, even though the full extent of the rich-data master cannot be seen on normal viewing devices. |
This table documents some of the signifiers that may be used by automated systems to identify a format or the data it contains. A more comprehensive listing of signifiers for a number of formats may be found at the JHOVE web site (http://hul.harvard.edu/jhove/). |
Tag type | Value | Note |
Filename Extension | | Name extensions generally used in Windows, UNIX, and other environments. From various sources. |
Internet Media Type |
| When possible, from the IANA MIME Media Types site; otherwise (and in addition) from other sources, e.g., Filext.com. |
Magic numbers | | The first bits in a file, used to identify the type of file, often associated with Unix and its derivatives. The most frequent sources for information are Gary Kessler's File Signatures Table and Filext.com. |
Microsoft FOURCC | | Four-character identifier for video codecs (and other elements) in Microsoft formats, from the Microsoft registry. |
Microsoft WAVE format registry | | Audio codec identifier in Microsoft formats, from the Microsoft registry. |
ASF GUID | | Globally Unique IDentifier for media types and other elements in Microsoft ASF files, from the Advanced Systems Format (ASF) Specification. |
Apple Video Sample Description | | Four-character codes for video codec identification in QuickTime files from The QuickTime File Format. |
Apple Sound Codec four-character codes | | Identifiers for audio codec identification in QuickTime files from The QuickTime File Format. |