5.5 Multi-Segment Records

A multi-segment record consists of two or more concatenated segments. Each segment is an ordinary WFDB record, with its own header file and signal file(s). There are two types of multi-segment records: fixed-layout records, in which all signals must appear in the same order within each segment (signals may not be omitted, added, or swapped), and the gain and baseline of any given signal may not change from segment to segment; and variable-layout records, which are not bound by these constraints. If the first segment of a multi-segment record has a length of zero samples, that segment is a layout segment, and the record is a variable-layout record. Version 9.1 of the WFDB library is the first to support reading and writing fixed-layout multi-segment records, and version 10.3.17 is the first to support reading variable-layout multi-segment records.

In both types of multi-segment records, the sampling frequency of any given signal must be the same in each segment. Segments of multi-segment records must be ordinary records (it is not permitted to nest one multi-segment record within another, for example), and the length of each segment must be specified (the WFDB library does not impose this requirement on ordinary records that are not part of a multi-segment record). There are no other restrictions on segments; specifically, it is permitted to mix segments with different storage formats, and for any segment to appear more than once. A special header file (created either manually or by using setmsheader) specifies the record name for each segment in a multi-segment record. Once this special header exists, the multi-segment record can be read by any WFDB application. Note that only the signal files of the segments are “linked” by the multi-segment record’s header; annotation files associated with the individual segments are not readable as part of the multi-segment record (although an annotation file associated directly with the multi-segment record can be created and read just as for an ordinary record). From the point of view of a WFDB application, reading a multi-segment record is exactly like reading an ordinary record; specifically, isigsettime works as expected, permitting jumps forward and backward between as well as within segments.

Unlike ordinary segments, no signal file is associated with a layout segment; only the header file is needed. In the header file of a layout segment, all of the signals present in any of the other segments of the record are listed, in the desired order and with the desired gains and baselines. When the WFDB library reads the record, getframe assembles the frame, scaling and shifting each component as needed. If any signals are missing during a segment, the resulting gaps are filled with the sample value WFDB_INVALID_SAMPLE. In this way, WFDB applications do not need to be aware of signal changes; rather, they may read variable-layout records as if they were ordinary (fixed-layout) records.

WFDB applications generally assume fixed-layout records, i.e., that the number and types of available signals (and their sampling frequencies, gains, and baselines) are constant throughout the record. These conditions do not always apply in clinical settings, in which signals may be added, removed, or recalibrated to meet clinical needs, resulting in variable-layout recordings. A variable-layout recording may be divided into segments such that each segment is a fixed-layout WFDB record. The segments can then be reassembled into a multi-segment WFDB record. Version 10.3.17, and later versions, of the WFDB library contain code in signal.c to create a virtual fixed-layout record on the fly when reading a variable-layout record. This feature can also be used to transform ordinary records on the fly, if it is desirable to rearrange, delete, duplicate, scale, or shift signals.