|Version 1||Breaklog 2||Language(s)||Release date||Group(s) 3|
Oct. 12, 2016
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 project is hosted in GitHub:
The miniSEED 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 miniSEED in order to allow rapid development of miniSEED reading/writing software. The framework allows everything from manipulation of miniSEED on a record-by-record basis to reading of miniSEED 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 miniSEED records from a file, adding data from unpacked records to a group of traces or packing a group of continuous traces into miniSEED 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.