edfcore 0.5.1 → 0.5.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
109
109
  readonly reserved: 224;
110
110
  };
111
111
  /** Published package version. Kept in sync with package.json by a test. */
112
- export declare const VERSION = "0.5.1";
112
+ export declare const VERSION = "0.5.3";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.5.1';
82
+ export const VERSION = '0.5.3';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,45 @@ alone does not tell you whether you were affected.
6
6
  edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
7
7
  defect; those are called out below.
8
8
 
9
+ ## 0.5.3
10
+
11
+ - **Added** the claim `api-reading.md` makes in one clause: "that makes `startSeconds` trustworthy
12
+ on an EDF+D file even when the index is only probed". A chunk decodes its start from the
13
+ timekeeping TALs in its own bytes, so an index that has read two records cannot make it wrong.
14
+ - It is worth checking because the cheap answer is available and wrong. Every record has a nominal
15
+ position, `start + r * recordDuration`, that a reader can compute without touching the file — and
16
+ on a contiguous file it is right. On an EDF+D file it is short by every gap before it, which is
17
+ the number nobody notices: the samples are fine, the record numbers are fine, and only the clock
18
+ has moved.
19
+ - The fixture puts a seven-second hole after record 3 and reads a chunk on each side of it through
20
+ an index that has never looked. The far chunk is asserted not to report the nominal position, to
21
+ report the true one in ticks, and to report the same value the scanned index does — which is what
22
+ "trustworthy" has to mean. The near chunk reports a position where the two answers coincide,
23
+ which is why testing only that half would conclude the nominal grid was fine.
24
+ - `precededByGap` is asserted `undefined` on the same chunk, deliberately. It is the field a probed
25
+ index genuinely cannot fill, and the one `mergeChunks` stopped keying its refusal on in 0.2.19 —
26
+ before that, two chunks a minute apart on an EDF+D file joined in silence.
27
+
28
+ ## 0.5.2
29
+
30
+ - **Added** the map of how far `strict` reaches on a read, which has three cells rather than the
31
+ two a reader assumes. `openEdf` probes exactly two records for their timekeeping onsets, so a
32
+ malformed TAL in record 0 or the last record throws under `strict` and one in a middle record
33
+ does not — the file opens, and every sample reads back either way.
34
+ - The middle cell is not a defect. A probed index has read two records, so `strict` can only reject
35
+ what it saw; rejecting a file for a defect nobody looked for would be a claim the probe cannot
36
+ make, and `validateRecording` is the call that reads every record. It is written down because
37
+ "strict rejects a file with any defect" is what a reader assumes, and it is wrong in a way no
38
+ error message will correct.
39
+ - The reason a read is never strict is checked as the structural fact it is rather than as
40
+ carefulness: `ReadOptions` declares no `strict` member, so a read cannot be asked for it even by
41
+ a caller who wants it. `recording.ts` says exactly that at the call site — "not because the flag
42
+ was lost" — and a member added later would compile, be ignored, and leave `api-reading.md`
43
+ describing an option that exists.
44
+ - In all three cells the samples come back and `TAL_MALFORMED` lands on `chunk.diagnostics` naming
45
+ the record it was found in. That is what the read path exists to protect: a malformed TAL in the
46
+ annotations channel is not a reason to return no EEG.
47
+
9
48
  ## 0.5.1
10
49
 
11
50
  - **Added** the `out` contract as one check over every primitive that takes one.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.5.1",
3
+ "version": "0.5.3",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.5.1';
96
+ export const VERSION = '0.5.3';