liamtoney / sonify Goto Github PK

I'm welcome to be excited about this 'sonify' project. But when it comes to seismic networks in the world, the problem is mainly with the EC network ie EC.VCES..HHZ and Its location is --.

As you can see the screen should measure in color based on dB power, but it looks like the background is blue.

I'm getting a message like this:
WARNING (norm_resp): computed and reported sensitivities differ by more than 5 percent. Execution continuing.

Here's the initial response from the station.

URL: click here.

The code:

from sonify import sonify
from obspy import UTCDateTime

sonify(
    network='EC',
    station='VCES',
    channel='HHZ',
    starttime=UTCDateTime('2022-02-10T14:40:40.430304Z'),
    endtime=UTCDateTime('2022-02-10T16:40:40.430304Z'),
    location='--',
    freqmin=1,
    freqmax=23,
    speed_up_factor=200,
    fps=1,  # Use fps=60 to ~recreate the JHEPC entry (slow to save!)
    spec_win_dur=8,
    db_lim=(-180, -130),
)

It's sensitivity is of 3.14195E8 @ 1.0 Hz (SEED Stage 0)

Some seismic or infrasound signals have a large dynamic range, which is not ideal for playback at low volumes or on small systems. The default Alaska avalanche signal is a good example of this, where the large-amplitude failure is much, much louder than the precursory seismicity. While applying audio compression (side note — in the field of seismology, automatic gain control does sort of the same thing) to "smooth" the loudness variations would make the mapping from physical amplitude to loudness less clear, it could help make some sonifications easier to hear.

Here's some Python source code for audio compression: https://github.com/jiaaro/pydub/blob/master/pydub/effects.py#L115-L187 — might be overkill?

This line

However, for higher data sampling rates (even, say, 100 Hz) and larger speed_up_factor values (say, 500), the above line is actually downsampling (44100 Hz / 500 = 88.2 Hz < 100 Hz). Therefore, we need to apply an anti-aliasing filter.

Also, we should use a more advanced interpolation method, like lanczos (docs for the interpolate() method of the Trace object are here).

Use a monospace font, such as JetBrains Mono, for the tr.id title of the spectrogram. This will make certain elements of the ID, such as "0" vs. "O", easier to differentiate.

Leveraging saul as a dependency would simplify this package and reduce redundancy. saul is not versioned, though, and likely never will be... so we'd have to pin to a certain commit.

Currently we specify a RESOLUTION (e.g. (3840, 2160) for 4K) and DPI (e.g. 500) and use

Figure(figsize=np.array(RESOLUTION) / DPI)

to ensure that the output RESOLUTION is achieved.

A better solution would be to have the user specify the RESOLUTION only and have the DPI be a variable quantity that is altered such that RESOLUTION is achieved for a fixed figsize. In other words, we should ensure that altering the RESOLUTION does not change the size of figure elements — it should only change how pixelated the frames are.

This would open up the door to providing users with a 2K and/or 1080p option along with 4K. This would be useful, since when combined with 60fps, 4K can sometimes produce videos with bitrates high enough to cause playback issues.