edfcore 0.4.510 → 0.4.512

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.4.510";
112
+ export declare const VERSION = "0.4.512";
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.4.510';
82
+ export const VERSION = '0.4.512';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,45 @@ 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.4.512
10
+
11
+ - **Added** a read behind each of the four header-recovery diagnostics. When the header's numbers
12
+ disagree with the file, `parseHeader` recovers rather than refuses, and each recovery ends by
13
+ saying what a read will now do: which byte record 0 comes from, which records exist, which bytes
14
+ are never decoded. Every one of those is a claim about `decodeDigital` output, made in a module
15
+ that never calls it, and the existing tests stopped at the header fields the sentence mentions.
16
+ - The gap is not hypothetical for `HEADER_SIZE_MISMATCH`. A three-signal file declaring a 512-byte
17
+ header has the same `recordCount` under either size, because the arithmetic that produced it used
18
+ whichever size the reader used; what separates the two readings is which 1024 bytes come back as
19
+ record 0. The declared offset lands in the middle of the per-signal block and decodes to numbers
20
+ rather than to an error, so the test asserts the ramp the writer wrote — and asserts alongside it
21
+ that the declared offset would have given something else, or the first assertion proves nothing.
22
+ - `TRAILING_BYTES` and `PARTIAL_FINAL_RECORD` claim their bytes are never decoded and never padded
23
+ into existence. Both fixtures now write those bytes as `0x7F`, which decodes to 32639, a value
24
+ the sample ramp never produces — so "never decoded" is checked by looking for it in the output
25
+ rather than by trusting an offset. Reaching either by record number is refused, not returned.
26
+ - `TRUNCATED_FILE` says the missing records are not readable and will not be fabricated. The
27
+ surviving records read exactly as they do in the intact file, and the pair the header claimed is
28
+ an `EdfRangeError` rather than zeros.
29
+
30
+ ## 0.4.511
31
+
32
+ - **Fixed** `physical-values.md` documenting the limitation 0.4.509 removed. Its note said a fifth
33
+ refusal condition exists, that the header calls it `DEGENERATE_PHYSICAL_RANGE`, and that
34
+ `toPhysical` "can't re-derive this one" so it throws `SCALE_UNAVAILABLE`. The last clause stopped
35
+ being true one release ago.
36
+ - The page's table now lists five conditions rather than four, so the fifth is documented where a
37
+ reader looks for it rather than in an aside below. Five rows, four distinct codes: two conditions
38
+ reach `DEGENERATE_PHYSICAL_RANGE`, which is why the table is of conditions.
39
+ - The table is not prose. `scaling-page-arithmetic.test.ts` parses these rows out of the page and,
40
+ for each, builds the signal and asserts `toPhysical` refuses it with the code in that row — so
41
+ the new row is checked by the same mechanism as the other four, and the page cannot describe a
42
+ refusal the library does not make. The order it claims is checked too: a channel that is both
43
+ log-transformed and unusably scaled is refused as the log-transformed one, which is the answer
44
+ that says something about the data rather than about the map.
45
+ - The note is kept, rewritten as history: what the two sides used to report, and why looking up
46
+ `SCALE_UNAVAILABLE` in `header.diagnostics` used to find nothing.
47
+
9
48
  ## 0.4.510
10
49
 
11
50
  - **Added** the one claim every diagnostic makes at once, as a property test: `raw` quotes the
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.510",
3
+ "version": "0.4.512",
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.4.510';
96
+ export const VERSION = '0.4.512';