edfcore 0.5.2 → 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.2";
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.2';
82
+ export const VERSION = '0.5.3';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,25 @@ 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
+
9
28
  ## 0.5.2
10
29
 
11
30
  - **Added** the map of how far `strict` reaches on a read, which has three cells rather than the
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.5.2",
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.2';
96
+ export const VERSION = '0.5.3';