Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to add new terms ac:filterLowPass and ac:filterHighPass (from GUANO) #264

Open
danstowell opened this issue Feb 21, 2024 · 4 comments

Comments

@danstowell
Copy link
Contributor

danstowell commented Feb 21, 2024

Term Name: ac:filterLowPass
Term Name: ac:filterHighPass

Type: rdf:Property

Label: Low-pass filter frequency
Label: High-pass filter frequency

Required: No

Repeatable: No

Definition: Low-pass filter frequency used in the recording/preprocessing of the multimedia item.
Definition: High-pass filter frequency used in the recording/preprocessing of the multimedia item.

Usage: Numeric value in hertz (Hz)

Justification for the term addition: High-pass and low-pass filtering is common in the recording and/or preprocessing of sound recordings, and these filter settings can be important information relevant to which phenomena might be represented in a given media item, e.g. searching for ultrasonic signals. In search queries, it can be desirable to target (or exclude) animal sounds that occur within specific frequency ranges. The current proposal intends to adopt the terms "Filter HP" and "Filter LP" terms from GUANO (originally discussed in #247), which currently have no corresponding terms in avcore.

Note: filterLowPass and filterHighPass can be used independently or together.

Note: GUANO uses kHz as units, whereas Audiovisual Core uses Hz in ac:freqLow and ac:freqHigh. Hz is proposed here for self-consistency, though it would make the mapping to GUANO slightly more complex than a pure identity mapping.

Note: This is proposed as a new term rather than an import because GUANO is not a namespaced standard. The correspondence is expressed textually in the definition.

Proposed by myself and @edwbaker

@edwbaker
Copy link
Member

I am happy to stick with Hz for consistency.

It might also be worth discussing whether we use filterLP for easier matching to GUANO or filterLowPass for clarity - AC is relatively verbose with term names. I'm not particularly persuaded either way, filterLP will be understandable to those who regularly deal with audio.

@danstowell
Copy link
Contributor Author

On reflection, I agree that the term list should not be full of cryptic initialisms, so the more self-explanatory/verbose term names would be a good idea: filterLowPass and filterHighPass.

@danstowell danstowell changed the title Proposal to add new terms ac:filterLP and ac:filterHP (from GUANO) Proposal to add new terms ac:filterLowPass and ac:filterHighPass (from GUANO) Mar 20, 2024
@danstowell
Copy link
Contributor Author

I wonder if a GUANO maintainer such as @riggsd might have a comment

@riggsd
Copy link

riggsd commented Apr 18, 2024

Greetings TDWG!

The GUANO top-level fields Filter HP and Filter LP are defined as a float value in kHz, so Filter HP: 17.5 would represent a high-pass filter at 17500 Hz. While the GUANO spec was designed to target ultrasonic bat recordings, you could represent an audible-range recorder set to remove low-frequency wind noise, for example, with Filter HP: 0.5 for 500 Hz.

I'm not familiar with your TDWG metadata, so I can't say whether you'd have any issues with unit conversion or whether it matters.

Personally, I agree that cryptic abbreviated terms do a disservice to users. However, in the case of GUANO, the metadata itself is intended to be human readable, so we felt fine with some domain-specific terminology and opted not to be overly verbose. In the context of audio processing, a "filter" is commonly known to be of type "HP", "LP", or "BP".

We didn't feel it necessary to overcomplicate by specifying more detail about the filter design, eg. slope 12 "dB/oct" or class "Butterworth", assuming it to be either unimportant, or - if important - implementation specific to the particular hardware or software which could document it with namespaced values. For example, Sonobat doesn't specify its digital filter implementation details to end users, but does persist its specific filter information in a way meaningful to that software: SB|Filter: 20kHz Anti-Katydid (its "anti-katydid" HPF variant uses a steep slope, but not as steep as its "cutoff" HPF variant).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants