edfcore 0.4.418 → 0.4.420

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.418";
+export declare const VERSION = "0.4.420";
 //# 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.418';
+export const VERSION = '0.4.420';
 //# 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.420
+
+- **Added** tests for how long a TAL timestamp field may be. An onset and a duration are digits
+  with no declared length — the grammar ends them with a structural byte, so their size is whatever
+  the writer put between two markers, in a region that is 30 bytes on one file and 60 kilobytes on
+  another.
+- `MAX_TIMESTAMP_FIELD_CHARS` is that bound. Both fields carry the check; the onset's was
+  exercised and the duration's was not, and they matter differently. An over-long onset is a
+  malformed TAL from the first byte. An over-long duration arrives after a perfectly good onset,
+  which is the shape that gets past a reader's attention.
+- The guard sits before the decode, which is the property worth having: past it, a region full of
+  digits between two markers is a bigint the size of the region, parsed on every record of every
+  read that touches annotations.
+- A skipped TAL is skipped alone — the parser resumes at the terminator, so the events after a
+  hostile one are still read, and the bound is checked from both sides so it is where the message
+  says it is.
+
+## 0.4.419
+
+- **Added** tests for the two ways `mergeChunks` can be handed an input whose numbers look right.
+  It concatenates by position — signal `i` of the second chunk continues signal `i` of the first —
+  and the refusal for a different NUMBER of channels was pinned. The same channels in a different
+  ORDER was not.
+- A caller reaches that without doing anything strange: `signalIndices` built from a `Set`, from
+  `Object.keys`, from a checkbox list re-rendered between reads, or from `getSignal` calls made in
+  whatever order the labels came back. Merging those splices one electrode's samples onto another's
+  and returns a chunk that looks entirely normal — right length, right record range, right
+  timestamps — with two channels swapped halfway through. Nothing downstream would catch it,
+  because there is nothing wrong with the numbers, only with which channel they belong to. On a
+  montage that is the difference between a left-temporal seizure and a right-temporal one.
+- The second is the array itself. `mergeChunks` addresses its input by index, so a hole left by a
+  `filter` or a splice would read as `undefined` and be dereferenced; it is refused by name
+  instead, pointing at the array `readWindow` returned.
+
 ## 0.4.418
 
 - **Fixed** the rest of what 0.4.417 was about. Memoising the diagnostic sweep cut

package/package.json

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