Frequency range data

Is your feature request related to a problem? Please describe.

I often find myself needing to look up frequency ranges (fmin, fmax in Hz) for various sources, e.g., human voice or piano, etc. These values get used in a variety of contexts throughout librosa, such as setting the parameters of a pitch tracker (yin/pyin), or the frequency range of a spectrogram (cqt).

Describe the solution you'd like

A basic utility function to look up fmin and fmax for common audio sources. This can live in core.time_frequency, and be called as

>>> librosa.frequency_range('piano')
array([27.5, 4186])

or thereabouts. We may want to provide a units= parameter to automatically convert from hz to, say, notes or midi, but this might make things more confusing than is strictly necessary.

We'll also need a helper function to enumerate the valid queries to this function, similar to our list_thaat helper.

Additional context The wikipedia reference on musical range is a good starting point for much of what I'd like to include, but we should go to primary sources where possible. https://en.wikipedia.org/wiki/Range_(music)

I'd like this to be reasonably comprehensive, but there is a lot of room for this to get messy. For example, human voice is one option, but we could also provide specifiers for vocal bass vocal tenor etc. We should avoid gendered language here, and not include things like male vocal favoring instead to aim for register (which is more observable). Similarly, speech and singing might not have identical range values, so it could be helpful to provide separate keys for these in general.

There's a question of what exactly is meant by "fmax" that we'll need to grapple with. For pitched sources, we can reasonably say this corresponds to the highest fundamental frequency. However, we might want to include non-pitched sources as well (eg cymbals) which have no "f0" to speak of. In that case, we're talking more about the range of partials, which is quite a different thing. Similarly, we might want to include ranges for things like "human hearing", "telephone", etc.; which also correspond more to (observable) partials than to fundamentals. I think there are compelling use cases for both of these, and I'm not sure what the best API solution would be; perhaps a flag fundamental=[True,False]? If fundamental=True then some queries are allowed to fail (cymbal, telephone). If fundamental=False, then pitched sources should be multiplied up to capture some maximum partial (or Nyquist, if a sampling rate is also provided).

I'm not married to any of the ideas here, and there's plenty of room for discussion.