edfcore 0.2.31 → 0.2.32
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/CHANGELOG.md +15 -0
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/dist/sample-grid.d.ts +18 -0
- package/dist/sample-grid.d.ts.map +1 -1
- package/dist/sample-grid.js +18 -0
- package/dist/sample-grid.js.map +1 -1
- package/package.json +1 -1
- package/src/constants.ts +1 -1
- package/src/sample-grid.ts +18 -0
package/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,21 @@ 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.2.32
|
|
10
|
+
|
|
11
|
+
- **Documented, not fixed**, and the distinction is the point: `sampleIndexAt`, `sampleStartTicks`
|
|
12
|
+
and `sampleStartSeconds` measure the signal's own SAMPLE GRID, which equals elapsed recording
|
|
13
|
+
time only when the recording is contiguous. On a file with a seven-second hole,
|
|
14
|
+
`sampleStartSeconds(signal, 12, d)` answers 3 s for a sample whose record truly begins at 10 s,
|
|
15
|
+
and `sampleIndexAt(signal, 10, d)` names record 10 of a six-record file. This is the fifth
|
|
16
|
+
instance the 0.2.25 property test found, and the one that cannot be fixed by arithmetic: the
|
|
17
|
+
three take a signal, a number and a record duration — no index, no timeline — so a gap is not in
|
|
18
|
+
their arguments and nothing inside them could find it. Changing that would mean changing their
|
|
19
|
+
signatures, which is a 0.3 decision, not a patch. Until then the contract is stated in the source,
|
|
20
|
+
in the docs and in the property test, which now pins both regimes: exact agreement with
|
|
21
|
+
`readRecords` on a contiguous file, and the grid behaviour on a discontinuous one. `index.locate`,
|
|
22
|
+
`segmentAt`/`gapAt` and `chunk.firstSampleIndex` are the recording-axis answers.
|
|
23
|
+
|
|
9
24
|
## 0.2.31
|
|
10
25
|
|
|
11
26
|
- **Fixed** `readEnvelopeAtResolution` not delivering the resolution it was asked for. A chunk
|
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.2.
|
|
112
|
+
export declare const VERSION = "0.2.32";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/dist/sample-grid.d.ts
CHANGED
|
@@ -14,6 +14,24 @@
|
|
|
14
14
|
*
|
|
15
15
|
* These do the arithmetic in integers on `(record, sampleWithinRecord)` instead, which is the
|
|
16
16
|
* same rule `trimToWindow` follows.
|
|
17
|
+
*
|
|
18
|
+
* WHAT THEY MEASURE, PRECISELY: position on the SIGNAL'S OWN SAMPLE GRID. Sample `n` is the `n`th
|
|
19
|
+
* sample the file stores for that signal, and its time is `n * recordDuration / samplesPerRecord`.
|
|
20
|
+
* On a CONTIGUOUS recording that is also elapsed recording time, and the two ideas are the same
|
|
21
|
+
* number — which is why the distinction is easy to miss.
|
|
22
|
+
*
|
|
23
|
+
* ON A DISCONTINUOUS FILE THEY ARE NOT THE SAME. Samples are adjacent in the array across a gap
|
|
24
|
+
* while their times are not, so `sampleStartSeconds(signal, 12, d)` answers 3 s for a sample whose
|
|
25
|
+
* record truly begins at 10 s, and `sampleIndexAt(signal, 10, d)` answers with a record index past
|
|
26
|
+
* the end of a six-record file. These functions receive a signal, a number and a record duration —
|
|
27
|
+
* no index, no timeline — so they CANNOT detect a gap, cannot bound the answer by the record
|
|
28
|
+
* count, and are not being modest about it: the information is not in their arguments.
|
|
29
|
+
*
|
|
30
|
+
* So the contract is stated rather than guessed at. For a file that may be discontinuous, use
|
|
31
|
+
* `index.locate(seconds)` for time to record, `segmentAt`/`gapAt` to find out whether an instant
|
|
32
|
+
* has data at all, and `chunk.firstSampleIndex` for the sample index a read actually produced.
|
|
33
|
+
* `contiguityOf(index)` answers which regime you are in. On a contiguous file — the common case,
|
|
34
|
+
* and every plain EDF or EDF+C — these are exact and are what you want.
|
|
17
35
|
*/
|
|
18
36
|
import type { EdfSampleLocation, EdfSignal } from './types.js';
|
|
19
37
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"sample-grid.d.ts","sourceRoot":"","sources":["../src/sample-grid.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"sample-grid.d.ts","sourceRoot":"","sources":["../src/sample-grid.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAIH,OAAO,KAAK,EAAE,iBAAiB,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AA0B/D;;;;;;GAMG;AACH,wBAAgB,aAAa,CAC3B,MAAM,EAAE,SAAS,EACjB,OAAO,EAAE,MAAM,EACf,mBAAmB,EAAE,MAAM,GAC1B,iBAAiB,CAoBnB;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAC9B,MAAM,EAAE,SAAS,EACjB,WAAW,EAAE,MAAM,EACnB,mBAAmB,EAAE,MAAM,GAC1B,MAAM,CAcR;AAED,2EAA2E;AAC3E,wBAAgB,kBAAkB,CAChC,MAAM,EAAE,SAAS,EACjB,WAAW,EAAE,MAAM,EACnB,mBAAmB,EAAE,MAAM,GAC1B,MAAM,CAKR"}
|
package/dist/sample-grid.js
CHANGED
|
@@ -14,6 +14,24 @@
|
|
|
14
14
|
*
|
|
15
15
|
* These do the arithmetic in integers on `(record, sampleWithinRecord)` instead, which is the
|
|
16
16
|
* same rule `trimToWindow` follows.
|
|
17
|
+
*
|
|
18
|
+
* WHAT THEY MEASURE, PRECISELY: position on the SIGNAL'S OWN SAMPLE GRID. Sample `n` is the `n`th
|
|
19
|
+
* sample the file stores for that signal, and its time is `n * recordDuration / samplesPerRecord`.
|
|
20
|
+
* On a CONTIGUOUS recording that is also elapsed recording time, and the two ideas are the same
|
|
21
|
+
* number — which is why the distinction is easy to miss.
|
|
22
|
+
*
|
|
23
|
+
* ON A DISCONTINUOUS FILE THEY ARE NOT THE SAME. Samples are adjacent in the array across a gap
|
|
24
|
+
* while their times are not, so `sampleStartSeconds(signal, 12, d)` answers 3 s for a sample whose
|
|
25
|
+
* record truly begins at 10 s, and `sampleIndexAt(signal, 10, d)` answers with a record index past
|
|
26
|
+
* the end of a six-record file. These functions receive a signal, a number and a record duration —
|
|
27
|
+
* no index, no timeline — so they CANNOT detect a gap, cannot bound the answer by the record
|
|
28
|
+
* count, and are not being modest about it: the information is not in their arguments.
|
|
29
|
+
*
|
|
30
|
+
* So the contract is stated rather than guessed at. For a file that may be discontinuous, use
|
|
31
|
+
* `index.locate(seconds)` for time to record, `segmentAt`/`gapAt` to find out whether an instant
|
|
32
|
+
* has data at all, and `chunk.firstSampleIndex` for the sample index a read actually produced.
|
|
33
|
+
* `contiguityOf(index)` answers which regime you are in. On a contiguous file — the common case,
|
|
34
|
+
* and every plain EDF or EDF+C — these are exact and are what you want.
|
|
17
35
|
*/
|
|
18
36
|
import { TICKS_PER_SECOND } from './constants.js';
|
|
19
37
|
import { secondsToTicks } from './tal/ticks.js';
|
package/dist/sample-grid.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"sample-grid.js","sourceRoot":"","sources":["../src/sample-grid.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"sample-grid.js","sourceRoot":"","sources":["../src/sample-grid.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAEH,OAAO,EAAE,gBAAgB,EAAE,MAAM,gBAAgB,CAAC;AAClD,OAAO,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAGhD,SAAS,UAAU,CAAC,MAAiB,EAAE,mBAA2B;IAChE,IAAI,MAAM,CAAC,IAAI,KAAK,aAAa,EAAE,CAAC;QAClC,MAAM,IAAI,UAAU,CAClB,UAAU,MAAM,CAAC,KAAK,KAAK,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,KAAK,CAAC,+BAA+B;YACpF,uFAAuF;YACvF,2CAA2C,CAC9C,CAAC;IACJ,CAAC;IACD,IAAI,MAAM,CAAC,gBAAgB,IAAI,CAAC,EAAE,CAAC;QACjC,MAAM,IAAI,UAAU,CAClB,UAAU,MAAM,CAAC,KAAK,KAAK,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,KAAK,CAAC,aAAa;YAClE,GAAG,MAAM,CAAC,gBAAgB,0DAA0D;YACpF,6DAA6D,CAChE,CAAC;IACJ,CAAC;IACD,IAAI,mBAAmB,IAAI,EAAE,EAAE,CAAC;QAC9B,MAAM,IAAI,UAAU,CAClB,yFAAyF;YACvF,oFAAoF;YACpF,2CAA2C,CAC9C,CAAC;IACJ,CAAC;AACH,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,aAAa,CAC3B,MAAiB,EACjB,OAAe,EACf,mBAA2B;IAE3B,UAAU,CAAC,MAAM,EAAE,mBAAmB,CAAC,CAAC;IAExC,MAAM,KAAK,GAAG,cAAc,CAAC,OAAO,CAAC,CAAC;IACtC,MAAM,SAAS,GAAG,MAAM,CAAC,MAAM,CAAC,gBAAgB,CAAC,CAAC;IAClD,+FAA+F;IAC/F,0FAA0F;IAC1F,sDAAsD;IACtD,MAAM,SAAS,GAAG,KAAK,GAAG,SAAS,CAAC;IACpC,IAAI,KAAK,GAAG,SAAS,GAAG,mBAAmB,CAAC;IAC5C,IAAI,SAAS,GAAG,mBAAmB,KAAK,EAAE,IAAI,SAAS,GAAG,EAAE;QAAE,KAAK,IAAI,EAAE,CAAC;IAE1E,MAAM,WAAW,GAAG,KAAK,IAAI,EAAE,CAAC,CAAC,CAAC,KAAK,GAAG,SAAS,CAAC,CAAC,CAAC,CAAC,KAAK,GAAG,SAAS,GAAG,EAAE,CAAC,GAAG,SAAS,CAAC;IAC3F,MAAM,kBAAkB,GAAG,KAAK,GAAG,WAAW,GAAG,SAAS,CAAC;IAE3D,OAAO;QACL,WAAW,EAAE,MAAM,CAAC,KAAK,CAAC;QAC1B,WAAW,EAAE,MAAM,CAAC,WAAW,CAAC;QAChC,kBAAkB,EAAE,MAAM,CAAC,kBAAkB,CAAC;KAC/C,CAAC;AACJ,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,gBAAgB,CAC9B,MAAiB,EACjB,WAAmB,EACnB,mBAA2B;IAE3B,UAAU,CAAC,MAAM,EAAE,mBAAmB,CAAC,CAAC;IACxC,IAAI,CAAC,MAAM,CAAC,aAAa,CAAC,WAAW,CAAC,EAAE,CAAC;QACvC,MAAM,IAAI,UAAU,CAClB,oEAAoE,WAAW,GAAG,CACnF,CAAC;IACJ,CAAC;IACD,MAAM,SAAS,GAAG,MAAM,CAAC,MAAM,CAAC,gBAAgB,CAAC,CAAC;IAClD,MAAM,SAAS,GAAG,MAAM,CAAC,WAAW,CAAC,GAAG,mBAAmB,CAAC;IAC5D,MAAM,QAAQ,GAAG,SAAS,GAAG,SAAS,CAAC;IACvC,6FAA6F;IAC7F,6DAA6D;IAC7D,IAAI,SAAS,GAAG,SAAS,KAAK,EAAE;QAAE,OAAO,QAAQ,CAAC;IAClD,OAAO,SAAS,GAAG,EAAE,CAAC,CAAC,CAAC,QAAQ,GAAG,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC;AACnD,CAAC;AAED,2EAA2E;AAC3E,MAAM,UAAU,kBAAkB,CAChC,MAAiB,EACjB,WAAmB,EACnB,mBAA2B;IAE3B,MAAM,KAAK,GAAG,gBAAgB,CAAC,MAAM,EAAE,WAAW,EAAE,mBAAmB,CAAC,CAAC;IACzE,MAAM,KAAK,GAAG,KAAK,GAAG,gBAAgB,CAAC;IACvC,MAAM,SAAS,GAAG,KAAK,GAAG,gBAAgB,CAAC;IAC3C,OAAO,MAAM,CAAC,KAAK,CAAC,GAAG,MAAM,CAAC,SAAS,CAAC,GAAG,MAAM,CAAC,gBAAgB,CAAC,CAAC;AACtE,CAAC"}
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED
package/src/sample-grid.ts
CHANGED
|
@@ -14,6 +14,24 @@
|
|
|
14
14
|
*
|
|
15
15
|
* These do the arithmetic in integers on `(record, sampleWithinRecord)` instead, which is the
|
|
16
16
|
* same rule `trimToWindow` follows.
|
|
17
|
+
*
|
|
18
|
+
* WHAT THEY MEASURE, PRECISELY: position on the SIGNAL'S OWN SAMPLE GRID. Sample `n` is the `n`th
|
|
19
|
+
* sample the file stores for that signal, and its time is `n * recordDuration / samplesPerRecord`.
|
|
20
|
+
* On a CONTIGUOUS recording that is also elapsed recording time, and the two ideas are the same
|
|
21
|
+
* number — which is why the distinction is easy to miss.
|
|
22
|
+
*
|
|
23
|
+
* ON A DISCONTINUOUS FILE THEY ARE NOT THE SAME. Samples are adjacent in the array across a gap
|
|
24
|
+
* while their times are not, so `sampleStartSeconds(signal, 12, d)` answers 3 s for a sample whose
|
|
25
|
+
* record truly begins at 10 s, and `sampleIndexAt(signal, 10, d)` answers with a record index past
|
|
26
|
+
* the end of a six-record file. These functions receive a signal, a number and a record duration —
|
|
27
|
+
* no index, no timeline — so they CANNOT detect a gap, cannot bound the answer by the record
|
|
28
|
+
* count, and are not being modest about it: the information is not in their arguments.
|
|
29
|
+
*
|
|
30
|
+
* So the contract is stated rather than guessed at. For a file that may be discontinuous, use
|
|
31
|
+
* `index.locate(seconds)` for time to record, `segmentAt`/`gapAt` to find out whether an instant
|
|
32
|
+
* has data at all, and `chunk.firstSampleIndex` for the sample index a read actually produced.
|
|
33
|
+
* `contiguityOf(index)` answers which regime you are in. On a contiguous file — the common case,
|
|
34
|
+
* and every plain EDF or EDF+C — these are exact and are what you want.
|
|
17
35
|
*/
|
|
18
36
|
|
|
19
37
|
import { TICKS_PER_SECOND } from './constants.js';
|