edfcore 0.5.20 → 0.5.21
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.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +21 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -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.
|
|
112
|
+
export declare const VERSION = "0.5.21";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,27 @@ 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.21
|
|
10
|
+
|
|
11
|
+
- **Added** the census `reading-signals.md` takes of the derived sample rate. `samplesPerRecord` is
|
|
12
|
+
authoritative and `sampleRateHz` is "provided for display"; the page argues that with one file —
|
|
13
|
+
256 samples in a 3-second record is 85.333… Hz, no float holds it, and the error grows with *t* —
|
|
14
|
+
and then counts how often the two ways of finding a sample disagree: "1,000 of the first 3,001"
|
|
15
|
+
integer second boundaries, "always by exactly one sample", with the float answer landing one
|
|
16
|
+
sample early.
|
|
17
|
+
- Nothing computed it. `sample-grid.test.ts` covers the grid functions and `trim-window.test.ts` the
|
|
18
|
+
window arithmetic, both against exact expectations; neither compares either against
|
|
19
|
+
`Math.round(t * sampleRateHz)`, which is the expression a reader would otherwise have written and
|
|
20
|
+
the one the whole section exists to talk them out of.
|
|
21
|
+
- The three printed values are checked first — `85.33333333333333`, `8534` from `trimToWindow`, and
|
|
22
|
+
`8533` from the float, whose sample really does start at 99.996 s — and then the census is run over
|
|
23
|
+
all 3,001 boundaries through `trimToWindow` rather than through a reimplementation of it. Each
|
|
24
|
+
clause of the Note is a separate assertion, because they fail separately: a count that is right
|
|
25
|
+
with the direction wrong would be a worse page than one with no number at all.
|
|
26
|
+
- The page shows `trimToWindow` twice, and the earlier example is on a 256 Hz file with its own
|
|
27
|
+
`exact.firstSampleIndex`. Every lookup is scoped to the fence that mentions the derived rate, so
|
|
28
|
+
the test cannot pass by reading the wrong example.
|
|
29
|
+
|
|
9
30
|
## 0.5.20
|
|
10
31
|
|
|
11
32
|
- **Added** the lifetime contract `api-sources.md` states in five words: of `close?()`, "edfcore
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED