edfcore 0.4.461 → 0.4.463

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.4.461";
+export declare const VERSION = "0.4.463";
 //# 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.4.461';
+export const VERSION = '0.4.463';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,41 @@ 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.4.463
+
+- **Added** the half-open edge cases for the branch `trimToWindow` takes when nothing in the chunk
+  advances in time — a zero record duration, or a signal with no samples per record. It decides
+  membership with its own comparison pair, and the existing test put the chunk at 0 and asked
+  about `[0, 1)` and `[1, 2)`, missing both boundaries by a whole second.
+- Relaxing the right-hand comparison to `<=` admitted a chunk that begins exactly where the window
+  ends, so two adjacent windows both returned it and a caller walking such a file got every sample
+  twice. Relaxing the left-hand one excluded a chunk that begins exactly where the window begins,
+  which is the ordinary way anyone asks for the first window of a file.
+- The `windowDurationTicks > 0n` clause guarding both survives mutation and is left as it is. It
+  is redundant with the pair below it — with a zero-length window, `chunkStartTicks <
+  windowStartTicks + 0n` is already false wherever the left comparison holds — so no input can
+  distinguish it, and the empty-window case is asserted for what it promises rather than to kill a
+  mutant it cannot reach.
+
+## 0.4.462
+
+- **Added** the edge cases for `countOutOfDigitalRange`, the third copy of a rule whose other two
+  copies were already pinned. `decodeInt16` and `decodeInt24` count a sample as out of range only
+  when it is strictly outside `[digitalMinimum, digitalMaximum]`; this copy runs when a trim
+  narrows a chunk that had one, and neither of its comparisons was pinned at the edge. Relaxing
+  either left the suite green.
+- A sample sitting exactly at the declared maximum is the common case, not the exotic one — a
+  saturating amplifier parks a channel at 32767 for the length of an artefact.
+  `outOfDigitalRangeCount` is documented as meaning the declared range is WRONG, so counting a
+  clipped sample says that about the one file where the declaration is exactly right. And only
+  for callers who trimmed: the same samples would be in range before the trim and out of range
+  after it.
+- The inverted declaration is pinned here too. `digitalMinimum > digitalMaximum` is a real writer
+  bug, the decoder compares against min/max of the pair rather than the pair as written, and this
+  copy has to agree — taking them as written makes every sample out of range, again only after a
+  trim.
+- Found by mutation, not by coverage: all three lines were reported as covered.
+
 ## 0.4.461
 
 - **Added** the exact-edge cases for `resolveTimeWindow` on a segmented index. The window is

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.461",
+  "version": "0.4.463",
   "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.4.461';
+export const VERSION = '0.4.463';