edfcore 0.5.30 → 0.5.32

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

package/docs/CHANGELOG.md

@@ -6,6 +6,54 @@ 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.32
+
+- **Added** a lattice check over the ten microvolt values `quick-start.md` prints. That page prints
+  two `Float64Array` blocks — five values from a window at `t = 0` in the browser example, five more
+  from `t = 60` in the Node one. They are the first numbers anyone sees from this library, and
+  `quick-start-page.test.ts` runs everything around them: the header listing, the sample count, the
+  byte count, the annotation lines, the three refusals. The values themselves it did not touch.
+- They cannot be reproduced from the page, which names its file's geometry and not its waveform.
+  What they can be checked against is the scale that geometry implies, and that turns out to be the
+  check worth having: a physical value is `bitValue * (offset + digital)` for an integer `digital`,
+  so on a given declaration the reachable values are a lattice, and a float that is not on it was
+  produced by a different expression or a different range.
+- That is not hypothetical. 0.5.6 found exactly that on `api-types.md` — two printed values belonged
+  to a file with a different digital range from the one the rest of the page's example used, and the
+  existing test checked five of seven lines and stopped before them. A lattice check catches it
+  without needing the waveform, and would have caught it there. The last test makes the point
+  concretely by converting the same digital sample on a 12-bit declaration and showing it lands
+  somewhere else.
+- Each of the ten is inverted through the declared scale, asserted to be a whole number inside the
+  declared range, and put back through `toPhysical` on a real signal, compared with `Object.is` —
+  `toBeCloseTo` would pass on a value from the wrong scale. The page's own argument for the array
+  type goes with them: every one of the ten changes under `Math.fround`, so "a sample scaled into
+  float32 loses about a quarter of a quantisation step" is true of the very values printed beneath
+  it. And the first value is asserted to be what digital zero converts to, which is not zero.
+
+## 0.5.31
+
+- **Added** the record-range contract at the five calls that take one. `RecordRange` is the other
+  half of the selection contract 0.5.29 covered, and it reaches three layers — `readRecordBytes` in
+  the I/O layer, `readRecords` and `readAnnotations` in the recording layer, `decodeDigital` and
+  `decodeAnnotations` in the decoders. Unlike the signal selections, they do not share a validator:
+  each asserts the range for itself.
+- That is the reason to check them together. `api-reading.md` documents one behaviour — an
+  `EdfRangeError` when the range is not inside `header.recordCount` — and a caller who tested against
+  `readRecords` has no way to know whether `decodeDigital` agrees. The error also carries `requested`
+  and `available` so a caller can clamp and retry, and those have to hold the same two ranges at
+  every site or the retry computes the wrong one; that is now asserted as one set rather than five
+  times over.
+- Six bad ranges run at all five: a start past the end, a count that runs past it, a negative start,
+  a negative count, a fractional start and a fractional count. The last two are the ones a caller
+  reaches without noticing — a `Math.floor` left off a division, a range built from `seconds * rate`
+  — and they are refused rather than truncated, because a range that silently became
+  `{ start: 0, count: 1 }` would return real samples for a question nobody asked.
+- `count: 0` is accepted at all five, including at the end of the file where a count of one is not,
+  which is the case the page singles out. The two decoders check something else as well — the buffer
+  they were handed against the range they were given — and that second check is exercised rather
+  than worked around, since it is the one that catches a caller pairing a range with the wrong bytes.
+
 ## 0.5.30
 
 - **Added** what `diagnostics.md` prints for one header, printed. The page introduces the two ways of

package/package.json

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