Fix reading formats 8, 310, and 311 #327

Mark Python source files as "diff=python" to show the correct function names, and mark various types of binary files as binary to avoid attempting to diff/merge them.

In each branch, the calls to _rd_dat_signals with and without 'no_file=True, sig_data=sig_data' were otherwise identical. sig_data is ignored if no_file is false, so this is equivalent to simply passing 'no_file=no_file, sig_data=sig_data'. Furthermore, since _rd_dat_signals takes a huge number of arguments, convert all of them to keyword style to avoid confusion.

All four of the calls to _rd_segment were identical apart from the 'no_file' and 'sig_data' arguments. Rearrange the code so there is only one call to _rd_segment, to avoid redundancy. Furthermore, since _rd_segment takes a huge number of arguments, convert all of them to keyword style to avoid confusion.

This should be a list containing the initial sample value for each signal; this is required in order to correctly read format-8 dat files.

In signal format 8, each sample is stored as an 8-bit signed difference from the previous sample. This means that after reading the raw byte values, they must be translated to absolute sample values by calling cumsum() and adding the initial value.

In formats 310 and 311, each block of three samples is written as four bytes. _rd_dat_signals will retrieve the minimum range of bytes (as determined by _dat_read_params and _required_byte_num) that are needed in order to decode the desired samples; thus, the data passed to _blocks_to_samples may include an incomplete block at the end. The previous implementation of _blocks_to_samples was meant to pad the input data to a multiple of four bytes. However, this logic was wrong: added_samps was always set to zero, so the intended extra bytes were not appended, and (if the lack of extra bytes didn't cause an error) the wrong number of samples was returned to the caller. In fact, the subsequent statements for decoding blocks into samples already worked correctly for an unpadded input array (since each input slice is correctly truncated to the length of the output slice.) So remove the padding logic entirely.

The record "binformats" contains one signal in each of the ten WFDB binary formats (8, 16, 61, 80, 160, 212, 310, 311, 24, and 32.) In this record, sample j of signal i is equal to: (i + 16843019 * j) % ((1 << adcres) - 1) + 1 - (1 << (adcres - 1))) Note that the length of the record is 499 samples, so each of the bit-packed data files ends with an incomplete data block. Use this record to test that it is possible to read all of the formats correctly, including when we skip one or two samples from the start and/or end of the record. (Skipping samples is expected to give incorrect results for format 8, so that signal is not required to match.) We do not test writing, since not all formats are currently supported by wr_dat_file.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix reading formats 8, 310, and 311 #327

Fix reading formats 8, 310, and 311 #327

Commits on Sep 24, 2021