edfcore 0.4.462 → 0.4.464

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

package/docs/CHANGELOG.md

@@ -6,6 +6,39 @@ 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.464
+
+- **Added** tests for the `maxMaterializeBytes` boundary in all three modules that check it —
+  `io/read.ts` before a record range, `decode/digital.ts` before the `Int32Array`, and
+  `envelope.ts` before the bucket accumulators. All three admit a requirement equal to the budget,
+  and every existing test set a budget far below what it asked for or far above it, so relaxing
+  any of the three to a strict comparison left the suite green.
+- Equality is the case the option is used in. The documented way to stay inside a budget is to
+  size the request to it — take `maxMaterializeBytes`, divide by `header.recordByteLength`, read
+  that many records — and done exactly that lands ON the number every time. A strict comparison
+  refuses the arithmetic the error message itself recommends, so "read fewer records per call"
+  would be advice a caller had already followed perfectly.
+- Both sides of each boundary, and the refusal is checked to carry the same two numbers on
+  `requiredBytes` and `budgetBytes`. Those are the fields `api-errors.md` documents so a caller can
+  compute the next request instead of guessing at it, and a boundary error that reported them
+  inconsistently would be worse than one that did not report them at all.
+
+## 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

package/package.json

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