When signals of different types are recorded simultaneously and for
lengthy periods, it may be appropriate to choose different sampling
frequencies in order to reduce the storage requirements for signals of
limited bandwidth. The support for multi-frequency records provided in
DB library version 9.0 (and later versions) allows application programs
to read and write records containing signals digitized at multiple
sampling frequencies. In a multi-frequency record, a frame of
samples contains one or more samples from each signal. The
frame rate (base sampling frequency) of the record, as recorded in the
header file and as normally returned by sampfreq, is defined as
the number of frames per second. Signals sampled at multiples of the
frame rate are referred to as oversampled signals. For each signal, a
frequency multiplier specifies how many samples are included in each
frame. The frequency multiplier (1 by default) is an integer, encoded
within the format field in the header file, and specified in the
spf field of the DB_Siginfo structure for the signal.
A frame can be read as it was written
(see section getframe)
by an application that has been written to make use of multi-frequency
records. Applications that are not "multi-frequency aware" can still
read signals using the standard getvec interface, which returns
(as always) one sample per signal on each invocation. By default,
getvec reads multi-frequency records in low-resolution mode.
In this mode, each oversampled signal is resampled at the frame rate by
averaging all of its samples in each frame.
The function setgvmode can be used to select high-resolution mode,
in which getvec replicates samples of signals digitized at less than the
maximum sampling frequency (i.e., using zero-order interpolation) so that each
sample of an oversampled signal appears in at least one sample vector returned
by getvec. In this mode, sampfreq returns the number of samples
per signal returned by getvec per second of the record. Furthermore
(when using DB library version 9.6 and later versions), all time quantities
passed to and from the DB library functions are understood to be in units of
these shorter sampling intervals; thus, for example, getann converts
times in frame numbers (as recorded in annotation files) into times in sample
numbers before filling in the caller's annotation structure, and putann
converts times in sample numbers into times in frame numbers before writing
annotations into annotation files. This permits applications that are not
"multi-frequency aware" to read multi-frequency records with the highest
possible resolution, with only a one-line change in the source.
Go to the first, previous, next, last section, table of contents.