edfcore 0.5.42 → 0.5.43

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
109
109
  readonly reserved: 224;
110
110
  };
111
111
  /** Published package version. Kept in sync with package.json by a test. */
112
- export declare const VERSION = "0.5.42";
112
+ export declare const VERSION = "0.5.43";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.5.42';
82
+ export const VERSION = '0.5.43';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,27 @@ alone does not tell you whether you were affected.
6
6
  edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
7
7
  defect; those are called out below.
8
8
 
9
+ ## 0.5.43
10
+
11
+ - **Added** the two halves of what a sample width decides, written side by side. EDF stores each
12
+ sample in two bytes and BDF in three; that is the whole difference between the families as far as
13
+ the data records go, and `decodeDigital` keeps it where it belongs. The suite tested each width
14
+ against expected values and never one against the other.
15
+ - For a value both widths can hold, the two files disagree about everything except the number: the
16
+ record is half again as long, the declared digital range is 256 times wider, `bitValue` differs by
17
+ the same factor — and the decoded samples are bit-identical. That is "the width is an encoding",
18
+ asserted where it could fail.
19
+ - For a value only BDF can hold, the EDF file does not hold it. Two bytes cannot carry −300,000, so
20
+ what is written is the low sixteen bits and what comes back is those bits sign-extended: 27,680.
21
+ edfcore reports it with no diagnostic and no `outOfDigitalRangeCount`, which is correct and worth
22
+ writing down — the file is well formed, 27,680 is inside its declared range, and the loss happened
23
+ before edfcore saw a byte. Nothing in an EDF header can record that a writer had a number it could
24
+ not store.
25
+ - The whole low-bits sequence is asserted rather than the first value, and the same waveform in the
26
+ two families is shown to be two different recordings carrying identical diagnostics — which is the
27
+ point. `out-of-range.test.ts` covers the other case, a sample outside the DECLARED range in a
28
+ width that can hold it; this is the case where the width itself is the limit.
29
+
9
30
  ## 0.5.42
10
31
 
11
32
  - **Added** the transformation that changes what the samples MEAN without changing the samples.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.5.42",
3
+ "version": "0.5.43",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.5.42';
96
+ export const VERSION = '0.5.43';