edfcore 0.5.56 → 0.5.58

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.5.56";
+export declare const VERSION = "0.5.58";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.56';
+export const VERSION = '0.5.58';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,48 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.5.58
+
+- **Added** the composition rule for `trimToWindow`: trimming to A and then to B is trimming once to
+  their overlap. The call returns a `subarray` view rather than a copy — "so trimming allocates
+  nothing and the two share storage" — which makes its result a chunk signal like any other, and a
+  caller who has one narrows it again as a matter of course: a viewer that has read a minute and is
+  now drawing ten seconds of it does exactly that.
+- `trim-window.test.ts` covers the rule for one trim, against the closed form the source derives.
+  Composing two was not covered, and it is where a narrowing that treated its input's
+  `firstSampleIndex` as zero would show — the second trim measured from the wrong origin, coming
+  back with the right number of samples from the wrong place. The fixture's samples are a ramp over
+  the whole recording, so a sample's value names its position and a wrong origin is a different
+  number rather than a different length.
+- The property runs over 300 arbitrary window pairs with a constant seed, including pairs that do
+  not nest and pairs that miss each other entirely.
+- **Found while writing it,** and now stated rather than asserted away: an empty trim has no
+  position to agree about. The docblock promises a window that misses the chunk "yields a
+  zero-length result rather than an error" and says nothing about where that result sits, so two
+  routes to an empty answer report different `firstSampleIndex` and `startSeconds` — each being
+  where its own arithmetic stopped. `sampleCount` is the field to branch on, and the property
+  compares positions only where there are samples in them.
+
+## 0.5.57
+
+- **Added** the property that makes an envelope exhaustive: the buckets are a partition. `readEnvelope`
+  reduces a window to a min and a max per bucket, and the whole value of it is that nothing is lost —
+  a spike between two sampled points is what subsampling misses and an envelope does not.
+  `envelope.test.ts` states that as "equals an exhaustive reduction of the same samples", on one
+  fixture at one bucket count. The general form — the buckets cover every sample exactly once, in
+  order — was never written down.
+- It is checked against `counts`, the field that says how many samples each bucket reduced. Walking
+  the window's samples and taking `counts[b]` at a time, every bucket's `min` and `max` must be the
+  exact minimum and maximum of the slice it took: at six bucket counts from one to one-per-sample,
+  and over arbitrary windows and counts with a constant seed.
+- The last block is the case `readEnvelopeAtResolution` has and `readEnvelope` does not. Asked for a
+  bucket width finer than the sample interval it returns the grid its width implies and leaves the
+  columns with nothing in them empty rather than dropping them — 200 buckets over 32 samples, 168 of
+  them empty, and the ones that did take samples still bounding them exactly.
+- In the digital domain an empty bucket reads `min: 0, max: 0`, which is a perfectly ordinary
+  reading. So `counts` is the only field that tells it from a channel that really was flat at zero,
+  and that is asserted by building the flat channel and comparing the two.
+
 ## 0.5.56
 
 - **Added** the rule `precededByGap` carries, checked however the chunk was asked for. It is stated

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.5.56",
+  "version": "0.5.58",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.56';
+export const VERSION = '0.5.58';