As a concrete example, handling an unusual channel label like 2A-M1 that is known to be left EOG, you might be tempted to use a custom labels spec like
["eog"] => ["left" => ["2a-m1"]]
but this silently fails, sicne the correct specification is
["eog"] => ["left" => ["2a"]]
One way to catch things like this would be to check for whether the channel name is unchanged after passing through _normalize_reference, and raise an error/warning if not. another, trickier approach would be to somehow ALSO handle the "with reference" version so that both "2a" and "2a-m1" would match "2A-M1". but that may introduce subtly breaking changes since we use a greedy approach to matching (return the first thing that matches).
A common failure mode of creating custom labels is to specify the labels including references (e.g., just copying and pasting the labels seen in the EDF signal headers), whereas
match_edf_labelpasses the EDF label through_normalize_referenceswhich extracts and compares the first part (without reference) with the custom label: https://github.com/beacon-biosignals/OndaEDF.jl/blob/735c285e7212d28ba697b37cf4cb584fbca0f64f/src/import_edf.jl#L155-L156As a concrete example, handling an unusual channel label like
2A-M1that is known to be left EOG, you might be tempted to use a custom labels spec likebut this silently fails, sicne the correct specification is
One way to catch things like this would be to check for whether the channel name is unchanged after passing through
_normalize_reference, and raise an error/warning if not. another, trickier approach would be to somehow ALSO handle the "with reference" version so that both"2a"and"2a-m1"would match"2A-M1". but that may introduce subtly breaking changes since we use a greedy approach to matching (return the first thing that matches).