edfcore 0.5.20 → 0.5.21

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.20";
112
+ export declare const VERSION = "0.5.21";
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.20';
82
+ export const VERSION = '0.5.21';
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.21
10
+
11
+ - **Added** the census `reading-signals.md` takes of the derived sample rate. `samplesPerRecord` is
12
+ authoritative and `sampleRateHz` is "provided for display"; the page argues that with one file —
13
+ 256 samples in a 3-second record is 85.333… Hz, no float holds it, and the error grows with *t* —
14
+ and then counts how often the two ways of finding a sample disagree: "1,000 of the first 3,001"
15
+ integer second boundaries, "always by exactly one sample", with the float answer landing one
16
+ sample early.
17
+ - Nothing computed it. `sample-grid.test.ts` covers the grid functions and `trim-window.test.ts` the
18
+ window arithmetic, both against exact expectations; neither compares either against
19
+ `Math.round(t * sampleRateHz)`, which is the expression a reader would otherwise have written and
20
+ the one the whole section exists to talk them out of.
21
+ - The three printed values are checked first — `85.33333333333333`, `8534` from `trimToWindow`, and
22
+ `8533` from the float, whose sample really does start at 99.996 s — and then the census is run over
23
+ all 3,001 boundaries through `trimToWindow` rather than through a reimplementation of it. Each
24
+ clause of the Note is a separate assertion, because they fail separately: a count that is right
25
+ with the direction wrong would be a worse page than one with no number at all.
26
+ - The page shows `trimToWindow` twice, and the earlier example is on a 256 Hz file with its own
27
+ `exact.firstSampleIndex`. Every lookup is scoped to the fence that mentions the derived rate, so
28
+ the test cannot pass by reading the wrong example.
29
+
9
30
  ## 0.5.20
10
31
 
11
32
  - **Added** the lifetime contract `api-sources.md` states in five words: of `close?()`, "edfcore
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.5.20",
3
+ "version": "0.5.21",
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.20';
96
+ export const VERSION = '0.5.21';