/**
 * Byte decoding for the parser, written against `Uint8Array` rather than `Buffer`.
 *
 * The parser used to lean on `Buffer` methods, which put the `Buffer` type into the
 * published `.d.ts` files and forced every TypeScript consumer to have `@types/node`
 * installed to compile. Nothing here needs Node: these are the three operations the
 * EDF reader actually performed on raw bytes.
 */
/**
 * Decode bytes as latin1: each byte becomes the code point of the same value.
 *
 * Written as an explicit loop rather than `TextDecoder('latin1')` because the identity
 * mapping is the property this parser needs, and doing it directly guarantees it rather
 * than inheriting it. The WHATWG Encoding Standard lists `latin1` as a label for
 * windows-1252, which is not an identity map over 0x80-0x9F; Node resolves the label to
 * plain byte identity, so the two agree here, but that is a runtime's behaviour rather
 * than a guarantee to lean on for header bytes.
 *
 * Verified byte-for-byte against `Buffer.toString('latin1')` across all 256 values.
 */
export declare function decodeLatin1(bytes: Uint8Array, start?: number, end?: number): string;
/**
 * Decode free text out of a data record: UTF-8 where the bytes are UTF-8, latin1 where not.
 *
 * EDF+ says the annotation channel holds UTF-8, and this decoded it as UTF-8 and took what
 * came back. What comes back for bytes that are not UTF-8 is U+FFFD, one per malformed
 * sequence — so an event described `café` by a recorder writing latin1, which is most of the
 * older ones, was exported as `caf\uFFFD`. A character the file does not contain, in a text
 * column, with nothing said and exit 0.
 *
 * The same byte in a channel label comes out `é`, because header text is decoded by
 * `decodeLatin1` above, whose whole point is that every byte becomes the code point of the
 * same value. Two encodings for free text out of one file, and the difference only shows on
 * the side that can invent a character.
 *
 * Strict first, so the question is answered rather than guessed: bytes that decode as UTF-8
 * are UTF-8, and there is no ambiguity to resolve — a file may hold a genuine U+FFFD, written
 * `EF BF BD`, and that is valid UTF-8 and decodes to itself. Bytes that do not decode are not
 * UTF-8, and latin1 is what the rest of this parser reads them as. Neither path invents
 * anything: latin1 cannot fail, and it is the identity map this file already documents.
 */
export declare function decodeText(bytes: Uint8Array): string;
/**
 * Read a signed 16-bit little-endian sample.
 *
 * Plain arithmetic rather than a `DataView`: this runs once per sample, so hundreds of
 * millions of times on a long recording, and allocating or retaining a view per call
 * would show up in the conversion time. Shifting left 16 and back down arithmetically
 * is what sign-extends the result.
 */
export declare function readInt16LE(bytes: Uint8Array, position: number): number;