|Version 1||Breaklog 2||Language(s)||Release date||Group(s) 3|
April 25, 2015
A C library framework for manipulating and managing SEED data records. The library is known to work in most Unix/Linux environments (including Mac OSX) and in Win32 systems.
The Mini-SEED library provides a framework for manipulation of SEED data records including the unpacking and packing of data records. Functionality is also included for managing waveform data as continuous traces. All structures of SEED 2.4 data records are supported with the following exceptions: Blockette 2000 opaque data which has an unknown data structure by definition and Blockette 405 which depends on full SEED (SEED including full ASCII headers) for a full data description.
The primary purpose of the library is to hide the details of Mini-SEED in order to allow rapid development of Mini-SEED reading/writing software. The framework allows everything from manipulation of Mini-SEED on a record-by-record basis to reading of Mini-SEED into continuous trace segments to packing of large continuous traces using a record template.
Certain common tasks have, through library design, been streamlined, for example: reading Mini-SEED records from a file, adding data from unpacked records to a group of traces or packing a group of continuous traces into Mini-SEED records.
The following data encoding formats are supported for both unpacking and packing: ASCII, INT16, INT32, FLOAT32, FLOAT64, STEIM1 and STEIM2. The INT and FLOAT encodings each have two versions for quantities with a different number of bits of representation. The STEIM decompression produces 32-bit integers; likewise the compression routines require 32-bit integers as input. The following data encoding formats are supported for unpacking only: GEOSCOPE (24-bit, 16/3 and 16/4 gain ranged), CDSN, SRO and DWWSSN.
1 – Click the version release to view details about each package release including screenshots, manuals/how–to's, and revision histories. If more than one version is listed it means that a specific set of functionality was added or removed and legacy versions that preserve behaviors are archived.
2 – A list of changes that are not backwards compatible. More than one version of a package will be listed if this field has an entry.
3 – Development group(s) responsible. If IRIS and another group is listed, this usually means IRIS funded an external group for development.