The following chapter is from the official SEED manual.
Download the SEED Manual (pdf)
What is SEED?
The Standard for the Exchange of Earthquake Data (SEED) is an international standard format for the exchange of digital seismological data. SEED was designed for use by the earthquake research community, primarily for the exchange between institutions of unprocessed earth motion data. It is a format for digital data measured at one point in space and at equal intervals of time.
SEED helps seismologists who record, share, and use seismological data. By providing a standard, SEED makes transmitting, receiving, and processing earthquake data easier and more accurate. Before the introduction of SEED, ease and accuracy had been goals, but not really attained.
Before the 1970's, analog media (usually paper or film) were the sole means of recording seismic data. When researchers wanted to exchange this recorded data, they had to deliver the original seismogram recordings or copies. When they needed to describe important associated information about a recording, they would write the information such as the station code, starting and ending date and time, time corrections, instrument orientation, dominant frequency pass band, and magnification by hand on a seismogram. To extract information from such data, researchers had to measure a seismogram's parameters by hand. Interpretation relied on additional information (including station coordinates, instrument types, and operating organization) derived from the station operator or from standard sources such as the National Earthquake Information Service (NEIS) Seismograph Station Codes and Coordinates (see Presgrave (1985)).
Seismologists have used digital recording methods since about 1970.
While these methods have increased data quality, they have also
meant new challenges. Data exchange has been
Many researchers collect digital earthquake data to perform computationally intensive waveform analyses. These analyses require much more auxiliary information information such as detailed instrument responses. This auxiliary information is needed in computer-readable form and is sometimes distributed on the same electronic media as the raw seismic data. Some institutions collect and distribute data in various formats, and whoever receives that data may have to do substantial work to read it. Sometimes the required auxiliary information is incomplete or not even available in computer-readable form.
Seismologists around the world are aware of these problems, and have recognized the need for a seismic data exchange standard to solve them. Many have created exchange formats, but none has succeeded in creating a de facto standard. In 1976, the International Deployment of Accelerometers (IDA) format was introduced. Perhaps because of its wide distribution, the most successful format before SEED may be the United States Geological Survey (USGS), Global Digital Seismograph Network (GDSN), Network-Day Tape format. This format became the only significantly used format within the United States until 1987, when the Federation of Digital Seismographic Networks (FDSN) formally adopted SEED. While the GDSN format has been adopted or emulated for some networks, it has not worked as an exchange standard because: 1) the cost to reformat data for it is often too high, 2) it is too limited for other seismic applications because of its orientation toward continuously-recorded global observatory data, and 3) it is not flexible enough to encompass changes in seismic instrumentation and computer media technologies.
In 1985, the International Association for Seismology and Physics of the Earth's Interior (IASPEI), Commission on Practice, formed a Working Group on Digital Data Exchange to propose a standard for international digital seismic data exchange. Soon afterward, the FDSN formed and assumed the responsibility for developing an exchange format. At their first meeting in August, 1987, the Federation working group reviewed a number of existing formats including SEED, a new format proposed as a starting point for discussion by the USGS for the working group. At a follow-up meeting in December, 1987, intensive discussion and numerous clarifications and modifications led to the new format's adoption as a Federation draft standard. Other groups are also considering adopting SEED as their standard. We have prepared this manual to help you discover SEED's benefits.
A Description of SEED Format Versions
The SEED format is presently quite stable. During the first several years of its existence several changes were incorporated into the format. This section briefly summarizes the various versions of SEED and what the major changes and additions are between the format versions.
Items that are new since the last SEED manual was published in March 1990 are labeled either v2.2, v2.3 or v2.4. New blockettes in versions 2.2, 2.3 or 2.4 are indicated in the blockette descriptions. New fields in blockettes in versions 2.2, 2.3 and 2.4 are identified to the left of the box summarizing the field names for each blockette.
Version 2.0, February 25, 1988
Version 2.1, March, 1990
Version 2.3, December, 1992
The FDSN met in Seattle, Washington, USA in December of 1992. At that time SEED version 2.3 was adopted. Some new blockettes were added and several additional fields were added to existing blockettes.
The following blockettes have been added with SEED version 2.3:
SEED allows for the modification of existing blockettes by appending new fields to the end of existing blockettes. This is always done in a fashion that maintains compatibility with older format versions. SEED readers that do not support the newer version simply ignore the added fields. With SEED version 2.3, two of the existing blockettes were modified.
The following blockettes have been modified with SEED version 2.3.
Version 2.4 [date]
The following change was introduced in version v2.4.
What This Manual Covers
SEED's design goals, implementation strategy, and recommended usage are the subjects of the remainder of this first chapter. Chapter 2 provides an overview of SEED's format structure, and introduces blockettes. Chapter 3 presents some conventions important information that you will need to use SEED effectively. Chapters 4 through 7 describe the format standard for control headers. Chapter 8 details the data records. A series of appendices follow; each contains information that may help you.
This manual has been designed for easy and quick retrieval of detail
information. Besides the organization of chapters, the page format
has certain key elements:
Figure 1: Sample Page
In preparing this manual, we wanted to specify the structure and organization of the format, as well as the placement, value range, and coding of every defined parameter. While many readers may be interested in which parameters are included in the specification, how they are encoded, and how they are organized, we recognize that only a few readers will find the details of the format immediately interesting. However, we wanted to document the format as completely as possible so that you can learn about SEED's features, use it, benefit from its usefulness and evaluate it thoroughly.
At a Federation meeting held in Blanes, Spain, on June 19, 1988, the Federation working group adopted the SEED format as an international standard for the exchange of Federation seismic data. Beginning on January 1, 1988, GDSN data has been available in SEED format. The Data Management Center (DMC) at the Incorporated Research Institutions for Seismology (IRIS) has adopted SEED, and uses it as the principal format for its IRIS/DMC datasets. IRIS has also developed a SEED reading program to help researchers convert these datasets into trace formats for which analysis tools already exist. By distributing this document now, we want to make the entire seismological community aware of the format, and we want to solicit your comments.
This manual represents the combined effort of many individuals within the Federation of Digital Seismographic Networks (FDSN) and could not have been produced without the cooperation of its members. The SEED format was reviewed and modified at a number of meetings from 1987 to 1992, the first was hosted by the USGS in Albuquerque, New Mexico, December 3-4, 1987. The next meeting was the SEED Programmers' Interest Group in Golden, Colorado, December 14, 1988. May 10-11 of 1989 the Federation working group met in Baltimore, Maryland, where the SEED format was further developed and significant support for the format was shown by both the United States and international attendees. The result of these efforts is evident in the first edition of the SEED Manual version 2.1.
After the publication of the first edition of the SEED Manual there
was a meeting in August, 1990 in Golden, Colorado at which the SEED
format underwent some modification. The next meeting was held in
Vienna in August of 1991 at which time more revisions were discussed
to improve the SEED format. This resulted in Version 2.2. The last
meeting was held in Seattle, Washington, at which enhancements were
made resulting in the present version of SEED 2.3. The following
is a list of the institutions with representatives in attendance
at one or more of the above mentioned meetings.
The SEED Format is maintained by a working group from within the
Federation. Its present members are as follows
Introduction to the Format
The SEED format may be used in successive steps. For example, the format might be used to transfer data from a station processor to a data collection center, then to a data management center and, finally, to an end user. (The SEED databases may be augmented or modified at stages along the way.) Additionally, data collection centers and data management centers are using features of the format for archival storage and data retrieval.
Although SEED has evolved primarily for institutions that exchange data, some seismologists have already proposed other uses for the format. Some IRIS seismic station processors will generate SEED data in the field. This will facilitate the collection and distribution efforts required, and the possibility of error introduction should diminish. Seismologists are also using the format to transmit seismic data by electronic means, such as a packet switching network. The Yellowknife array of the Geological Survey of Canada is transmitting SEED data via satellite. Finally, researchers working with other ground based geophysical observations unrelated to earthquakes (e.g., strain, tilt, or magnetic field) may find SEED suitable.
The SEED format was not designed for use with non-time series data, nor with time series data sampled at unequal intervals in time (nevertheless, mechanisms for including console logs were easily accommodated). These types of data are rare enough that complicating the format to include them does not seem worthwhile. We also did not design SEED for the exchange of processed (e.g., filtered) data or synthetic data (i.e., created by computer modeling). While such use is possible, we will not support it.
Design Goals and Strategies
The SEED format results from the design contributions of many seismologists and computer professionals. Their experience includes constructing other special seismic data distribution formats; in coordinating computer, operating system, and mass storage device compatibilities, behaviors, and peculiarities across a wide range of manufacturers; and in working with the International Standards Organization (ISO), American National Standards Institute (ANSI), and other industry standards. The result: a format that can meet the needs of many individuals and institutions that collect, record, transmit, and read seismological data.
The SEED format relies on a few assumptions that are common to all digital seismic data exchange formats currently in use for network data. First, computer architectures commonly use the 8-bit byte, so this has become a de facto basis for the format. Second, data from several sources many field stations, each containing different channels, recorded over a few discrete time spans might make up a typical logical SEED volume. (Note that these assumptions do not prohibit less demanding uses, such as the recording of data from a single geophysical observatory.) Several logical volumes together could fit on a single physical volume, such as a reel of magnetic tape or an optical disk. Each logical volume should begin with auxiliary, or parametric, information organized into one or more control headers, followed by a stream of raw, time series data.
Based on those assumptions, the SEED designers applied their experience to create a format with certain goals in mind. As they worked, they realized that they needed to implement certain strategies in order to reach those goals. They created SEED to meet these criteria:
General. SEED works for continuous, station oriented and
event oriented waveform data from single field stations, observatories,
networks, or arrays. (SEED can also work with other geophysical
time series data of potential seismological interest.) However,
generality sufficient to support both station and event oriented
data requires considerable format complexity.
Self defining. The data from each channel includes all the needed information. This self defining feature makes automatic processing easier. A series of control headers defines the auxiliary information as global to the entire volume, as well as specific to each channel. At a minimum, information about the volume, about station-channel characteristics, and about the data's time span appears in separate control headers that precede the time series data. Station control headers include station location and channel response (transfer function) information. The time span control headers allow for hypocenter and phase reading information. Additional auxiliary information, specific to a particular station-channel at a particular time, is embedded in the data stream.
Robust. SEED data include enough embedded information to allow recovery from recording and transmission errors. Logical records divide each volume. Each logical record begins with information on the record type and its absolute sequence within the volume. Logical control header records are encoded entirely in printable American Standard Code for Information Interchange (ASCII) characters conforming with the ANSI standard. They are therefore directly readable by people, so control header records that have been damaged or incorrectly written can be interpreted. In addition, each logical data record has header information embedded between the record identification information and the data. This embedded information permits unambiguous identification of the data, should all the control headers be missing or destroyed.
Efficient. SEED minimizes wasted space for storage and distribution. As digital seismic data become available in increasing quantities, wasted space becomes too costly. SEED's storage efficiency creates an additional benefit: you can access the data with fewer input requests. SEED uses variable length and optional fields within the control headers to conserve space. You can abbreviate lengthy, repeated ASCII data items: an abbreviation dictionary control header defines those abbreviations. After the control headers, all subsequent data records (with embedded information) are coded as binary, and can be variable in their total length. A system of indices (cross references) to logical records make for efficient access: the volume header refers to the station-channel and time span headers; the time span headers refer to the data records.
Portable. The SEED format is suitable for easy and effective reading by any commercially available computer, using any commercially available operating system and any commercially available dismountable mass storage media. At the time of this manual's preparation, several SEED reading and writing programs exist for platforms by Digital Equipment Corporation, Sun Microsystems, and some personal computers. Operating systems that work with SEED now are VMS, UNIX, and some UNIX derivatives. Also, the lengths (in 8-bit bytes) of SEED logical records are always a fixed power of two. This means efficient data storage and rapid random access on the widest possible variety of computer equipment. Exchange volumes can have logical record sizes of 256 8-bit bytes or larger. Formatted data structures and unformatted data types are appropriately aligned, conforming with high level computer language standards.
Computer readable. Humans do not usually read comment information associated with data, despite the apparent advantages of including such comments. Nevertheless, a computer can extract a summary of relevant comment information for the user from SEED data. For example, the IRIS SEED reader software currently provides summary listings of comments for station and channel data. The SEED control headers are coded in a computer readable hierarchy of blockettes. These blockettes contain fixed and variable length data fields. The blockettes are self identifying sequences of data fields that assist computer readability, storage efficiency, and flexibility. Comment information is contained in a brief, computer readable form; the actual comment is defined in the abbreviation dictionary control header.
Referencing fields within blockettes relate important information. For example, fields 8 and 9 of blockette  refer to blockette . For more information about cross-referencing fields, see Appendix F.
Figure 2: Blockettes with Cross-Referencing Fields
Computer usable. By not having to transcribe large amounts of information to prepare SEED data an awkward activity at best fewer human errors are introduced. You do not have to use text editing software because SEED supports the automatic writing and reading of auxiliary data. You can write all parametric information using any computer language for any computer. Since auxiliary information is binary and is embedded in the data records, you cannot easily read or write it without a computer. This keeps data safe from accidental editing.
Flexible. SEED supports currently unforeseen future usage by including extensible auxiliary information with the time series data. If desired, you can define new field digitization formats without modifying the format standard. Each blockette and its trailing data fields are optional. Blockettes that are represented always identify themselves and measure their lengths. This allows you to append new data fields to blockettes that are already defined (or new blockettes to be defined), all without altering the existing control header structures in any way. This overcomes a significant failing of other, older formats a failing that quickly made them obsolete.
Self correcting. Even though errors will find their way
into distributed station-channel descriptive information and other
data, SEED provides a means of distributing corrections for preceding
volumes within a subsequent logical volume. You can distribute the
corrected station control header, flagging it to supersede the previously
distributed information that needs updating for a given effective
time period. You can specify that the correction information should
apply to the new data on the same distribution volume, or not. If
you do not want the correction information to apply to that new
data, just create more than one station control header for the same
station on the SEED volume one for the older data, and one for the
new data. You will also need more than one station control header
for the same station if station or channel characteristics were
changed during the time span of the volume for example, after a
maintenance site visit. (In this case, do not set the update flag.)
Can access any sequential or random access media. Although seismologists will continue to use sequential media such as magnetic tapes for the foreseeable future, SEED also supports more efficient data access on randomly accessible media, such as magnetic and optical disks. SEED uses fixed length logical records. These allow efficient random access on any media available to any computer. SEED provides indices to allow efficient random access of logical records when available. And, for sequential media, these indices facilitate the use of skip rather than read operations.
Usable as a field recording format. SEED allows you to use a modified subset of the format for data recording at a field station, but several constraints are imposed by the real-time nature of station processors. The entire time span control header and some fields in the other control headers cannot be created because the relevant information will not be available when the headers are written. Also, station processor memory constraints may require smaller logical records and block multiplexing of data channels (each logical record contains data from one channel, but successive logical records are interspersed with logical records from other channels). In addition, state-of-health, console log, and calibration information of direct interest only to the institution collecting the data can be included. Summaries of such data may appear in appropriate station control header fields when the exchange volume is created. Finally, a special telemetry volume format is available.
Efficient at merging data. Data collection and data management centers can merge data from several standard format volumes onto a new volume, with minimal changes to the auxiliary information and with no changes to the logical block structure for the data and for most of the control headers. SEED supports different logical record sizes. However, to simplify the merging of volumes, the lengths (in bytes) of logical records will always be a power of two. This means that any logical record size is a multiple or sub-multiple of any other, ensuring compact storage and rapid access on most computer devices. You can efficiently string together many smaller logical records into one larger logical record, without changing any data item except the logical record identification information.
Although the SEED format is flexible, we recommend limiting its use in some cases. As you use this format, keep the following in mind:
Multiplexing. Whenever possible, demultiplex all data. We discourage the multiplexing of data channels with a common sample rate, and from one station, even though SEED supports it. The format can become very complicated and convoluted, and data compression can become difficult when using multiplexing. We support block multiplexing of channels from one station for field tapes, but not for data exchange. SEED permits the multiplexing of array data if absolutely necessary.
Special Considerations for Multiplexed Data in Data Records.
The following blockettes must be properly specified. Blockette 30:
Read Appendix D carefully, paying attention to the section on Integer
Format - Family 0. Key 1 should specify the number of channels being
multiplexed. Blockette 52: A blockette 52 should be written for
each multiplexed channel. Field 5 will specify which subchannel
is being described. Sub channel numbering starts with one.
Logical record size. Each volume establishes a logical record size for itself. We strongly recommend a logical record size of 4096 bytes for volumes created by data collection and data management centers. At the time of this writing (2004), logical record sizes in excess of 4096 bytes have not been written. Logical record sizes as small as 256 bytes are supported. While all logical records on a SEED volume are usually the same size, the format can make exceptions for data records written in the field. We recommend using data records as large as 4096, and using the variable size feature only when absolutely necessary — and then only after coordination with the appropriate data collection center to ensure readable data. In practice, smaller record lengths are better for real-time data, as this reduces latencies.
Channel response. You can define each station-channel's transfer function in a variety of ways. These include a concatenation, or "cascade" of formal mathematical descriptions of analogue and digital filter sections, tables of amplitude and phase, or simple approximations. As a minimum, give the most complete and mathematically correct description of each station-channel transfer function available. In addition, you can give alternate descriptions that may have more intuitive appeal.
Hypocenters and phase data. For event oriented data, you can assume that the phase arrival times or readings given in a time span control header are associated with the hypocenter(s) given in that same control header. For station oriented data, the hypocenters are optional and may be taken from a catalog. The readings are also optional, and they may be unassociated estimates made automatically in the field by the station processors. In either case, the readings refer to positions in the time series data that immediately follow.
Dataless SEED Volumes. It is legal to produce a SEED volume that contains only header information and no data. This may prove to be an expedient way for various data centers to insure that they have current information from various networks. In this case one would include volume, abbreviation and station control header but omit time span control headers and data records.
Dataonly SEED Volumes. Just as the SEED format encompasses Dataless SEED volumes, it also defines the use of Dataonly or MiniSEED volumes. Dataonly SEED volumes contain only SEED data records and blockettes in data records as defined in this manual (see Appendix G). For individuals that feel sure that they know station characteristics and do not need to repeatedly receive SEED volume control header information, Dataonly SEED volumes may be an appropriate method of data transfer. Other than fixed section of data header information, these volumes contain nothing but time series. In fact this subset of SEED looks very similar to other trace analysis formats. If possible use the MiniSEED blockette (blockette 1000) to insure the information is totally self-defining.
Console logs. Data written at a field station may include console logs. The log information appears as a separate data channel with the appropriate data family code. Printable ASCII, standard forms control characters, and other special characters such as the ASCII bell (BEL) are acceptable. Alternate character sets (such as Kanji) are acceptable for languages that do not use the U.S. ASCII character set. We suggest formatting console log information in a way that permits automatic parsing at a data collection center reducing manual labor and human error. These same comments apply to nominal data such as telemetry flag status words, or door opened/closed flags, except that this information should appear as if it were an equally sampled time series.
Besides the recommended uses described above, SEED supports the following features:
End-of-file marks. Occasionally, some types of media need end-of-file marks added to the data stream (or they may be convenient for some purpose beyond the scope of normal SEED usage). SEED makes no use of single end-of-file marks and will ignore any present. The logical record sequence numbers must continue to increment after the embedded end-of-file mark. SEED interprets multiple end-of-file marks in sequence as the end-of-information for the physical volume. We require four end-of-file marks in sequence at the end of physical magnetic tape volumes to ensure that the reading program unambiguously interprets that point as the end of the volume.
Noise records. SEED writing programs can write blank or noise records at any time; SEED readers ignore such records. (These records are typically used to avoid a bad place on magnetic tape.) Use a correct logical record sequence number, ensure that the noise record has the correct logical record length, and set the remainder of the record (particularly the record type code) to spaces (ASCII 32). Noise records are particularly useful for field recording and for the starting points of 9-track magnetic tapes that have been used before.
Blank fields. Verify that all auxiliary information is as complete and correct as possible. If the current value of a particular field is not available, leave the field blank or set it to zero, as appropriate.
Field recording termination. Flush all data buffers before terminating a local field station recording. This ensures that data records for all channels will begin at about the same time on the following physical volume.
Header flushing. Sometimes it is useful to flush all data buffers and repeat all control header information periodically (e.g., each day at midnight). When flushing buffers, continue data recording after the repeated control headers. This strategy guarantees that low data rate channels are saved periodically and synchronizes the start times of data records for all channels. Control headers should contain current information if it has changed since the beginning of the volume. SEED supports, but does not require, header flushing as needed. Flush headers that have changed as a result of a site maintenance visit as soon as possible after making the change. SEED requires this, but only for the control headers that have changed.
Calibration. When performing calibration, testing, or repairs, field stations should always flag that maintenance operations are in progress. This notifies data collection personnel and end users of potential difficulties with the data from those field stations at those times.
Standards. Wherever practical, the SEED format follows existing
internationally agreed-upon standards. SEED codes all character
data according to the ANSI standard ASCII format (we recommend using
uppercase alphabetic characters whenever possible). Where possible,
we try to give physical units for transfer functions in uppercase
SI units (Le Système International d'Unités, the international
standard metric system). SEED uses other de facto standards
such as 8-bit bytes and the two's complement binary integer data