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.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +21 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -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.
|
|
112
|
+
export declare const VERSION = "0.5.43";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
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
package/src/constants.ts
CHANGED