edfcore 0.5.20 → 0.5.22

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.22";
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.22';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,48 @@ 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.22
10
+
11
+ - **Added** the scrolling table on `large-files.md`, measured. `large-files-cost.test.ts` runs the
12
+ two tables above it — what opening costs, and what one ten-second window costs. This is the third,
13
+ and the one that carries an argument rather than a figure: thirty consecutive ten-second windows
14
+ over an 8-channel EDF+C cost 30 reads and 1,246,800 bytes from a bare source, and 1 read of
15
+ 1,048,576 bytes through `cachedSource`.
16
+ - The sentence under it is why the table is there. "Removing `cachedSource` changes the number of
17
+ reads and nothing else" is a debugging instruction — if a bug appears with the cache in place,
18
+ delete the wrapper; if it survives, the cache was not involved — and it is only as good as the
19
+ "nothing else". The two runs are now compared sample for sample, all 153,600 of them, with the
20
+ count of non-zero values asserted too: a fixture decoding to zeros throughout would make an exact
21
+ match mean nothing.
22
+ - The page also says which block the single read is — "the second 1 MiB block. The first was already
23
+ resident because the header read at open pulled it in, so the reads that come with opening a file
24
+ are not wasted." That is checked as an offset, because it is what a reader plans an HTTP range
25
+ budget around, and because a cache issuing one read of the right size at the wrong place would
26
+ satisfy every other assertion here.
27
+ - The neighbouring claim goes with it: thirty ten-second windows cost thirty reads, and one
28
+ 300-second window over the same records costs one, for the same 1,246,800 bytes.
29
+
30
+ ## 0.5.21
31
+
32
+ - **Added** the census `reading-signals.md` takes of the derived sample rate. `samplesPerRecord` is
33
+ authoritative and `sampleRateHz` is "provided for display"; the page argues that with one file —
34
+ 256 samples in a 3-second record is 85.333… Hz, no float holds it, and the error grows with *t* —
35
+ and then counts how often the two ways of finding a sample disagree: "1,000 of the first 3,001"
36
+ integer second boundaries, "always by exactly one sample", with the float answer landing one
37
+ sample early.
38
+ - Nothing computed it. `sample-grid.test.ts` covers the grid functions and `trim-window.test.ts` the
39
+ window arithmetic, both against exact expectations; neither compares either against
40
+ `Math.round(t * sampleRateHz)`, which is the expression a reader would otherwise have written and
41
+ the one the whole section exists to talk them out of.
42
+ - The three printed values are checked first — `85.33333333333333`, `8534` from `trimToWindow`, and
43
+ `8533` from the float, whose sample really does start at 99.996 s — and then the census is run over
44
+ all 3,001 boundaries through `trimToWindow` rather than through a reimplementation of it. Each
45
+ clause of the Note is a separate assertion, because they fail separately: a count that is right
46
+ with the direction wrong would be a worse page than one with no number at all.
47
+ - The page shows `trimToWindow` twice, and the earlier example is on a 256 Hz file with its own
48
+ `exact.firstSampleIndex`. Every lookup is scoped to the fence that mentions the derived rate, so
49
+ the test cannot pass by reading the wrong example.
50
+
9
51
  ## 0.5.20
10
52
 
11
53
  - **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.22",
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.22';