edfcore 0.4.371 → 0.4.373

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

package/docs/CHANGELOG.md

@@ -6,6 +6,40 @@ 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.373
+
+- **Added** a cross-check between the two tables of the four onset fields — `annotations.md` lists
+  them by axis, `api-helpers.md` under "Which onset field to compare" — so the two agree about
+  which four exist, which axis each is measured from, and which two are exact. Two tables of one
+  fact is the shape this repository keeps finding wrong; their orders differ by design, so the sets
+  are what have to match.
+- The "exact" column is a claim about arithmetic rather than a label, and it is now executed: it is
+  why `filterAnnotationsByTime` compares ticks, and the page warns that comparing the seconds
+  fields means "an onset and a bound that should be equal need not compare equal". Three tenths is
+  three times one tenth to the tick and not in seconds, on the rebased axis a window is measured
+  on.
+- The worked example's four values are produced from a file built to its description, and the two
+  axes are checked to differ by exactly `timeline.startOffsetSeconds` — which is the whole reason
+  there are two of them.
+
+## 0.4.372
+
+- **Added** checks for the sample-grid section of `api-helpers.md`. The page opens by naming what a
+  reader would otherwise write — `Math.round(seconds * signal.sampleRateHz)` — and tabulating three
+  ways it fails silently. Two of them are now demonstrated: an undefined rate on a zero-duration
+  file makes the expression `NaN` where the grid functions throw a `RangeError`, and rounding
+  rather than flooring reaches the next sample before its boundary.
+- The rounding rule is checked as the property the page states it as: rounding a sample's start up
+  to a whole tick keeps `gridSampleStartTicks` and `gridSampleIndexAt` inverse for every index,
+  because a truncated tick lands inside the previous sample. Verified across every sample of six
+  records at 128 samples over 0.3 s — the geometry whose boundaries are half ticks — and with the
+  truncating alternative shown to land early.
+- The third row, the index drifting by one over a long recording, is deliberately NOT asserted, and
+  the test says so. Fed the tick this package publishes, the naive expression agrees with the
+  integer arithmetic for every index of every geometry tried; the two roundings cancel. The drift
+  belongs to times a caller arrives at some other way, and a fixture manufacturing one would be
+  asserting about its own construction rather than about the library.
+
 ## 0.4.371
 
 - **Added** a check on where the type tests are actually verified. `tests/types/` holds five

package/package.json

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