specshow's xticklabels do not print hour/minutes for short signals with offset

Describe the bug I am using librosa.specshow with x_axis="time" to display spectrograms. I think i’ve found a bug in the xticklabels. If the signal is less than one minute long (e.g., Brahms), it all goes well. If it is more than one minute long and i’m showing all of it, it also goes well. But if the signal is 90 seconds long and i want to show the last 40 seconds of it, librosa does not print xticklabels in mm:ss format but in scientific notation. (see below)

To Reproduce

Example:

import librosa
from matplotlib import pyplot as plt

def specshow_with_offset(y, sr, offset):
    S = librosa.power_to_db(np.abs(librosa.stft(y)))
    times = librosa.times_like(S, sr=sr)
    librosa.display.specshow(
        S, sr=sr, x_coords=times+offset, x_axis="time",
        y_axis="hz")
    
plt.figure(figsize=(6, 6))
y, sr = librosa.load(librosa.ex("brahms"))
for fig_id, offset in enumerate([0, 60, 120]):
    plt.subplot(3, 1, 1+fig_id)
    specshow_with_offset(y, sr, offset)

Expected behavior Use mm:ss or hh:mm:ss notations depending on the values taken by x_coords rather than depending on the duration of the input.

Screenshots

Software versions*

macOS-10.15.7-x86_64-i386-64bit
Python 3.8.10 (default, May 19 2021, 11:01:55) 
[Clang 10.0.0 ]
NumPy 1.21.0
SciPy 1.4.1
librosa 0.8.1
INSTALLED VERSIONS
------------------
python: 3.8.10 (default, May 19 2021, 11:01:55) 
[Clang 10.0.0 ]

librosa: 0.8.1

audioread: 2.1.9
numpy: 1.21.0
scipy: 1.4.1
sklearn: 0.22.1
joblib: 1.0.1
decorator: 5.0.9
soundfile: 0.9.0
resampy: 0.2.2
numba: 0.48.0

Additional context Related: #737 #760

[lostanlen]

Looking at this issue again today. While chatting with @bmcfee i offered the following solution:

what if our TimeFormatter’s spoke datetime.strftime ? https://docs.python.org/3.6/library/datetime.html#strftime-and-strptime-behavior

i imagine it would just be an if "%" in unit: branch

As a more long-term goal, there is also the prospect that our x_coords and y_coords could accept numpy arrays of np.datetime64 and np.timedelta64 objects. Him and i had the idea (at the same time) of providing a utility function librosa.datetime_like(X, sr, hop_length, offset)

Proof of concept

>>> offset = np.datetime64('2021-08-22T04:58')
>>> np.array([offset + np.timedelta64(n, "h") for n in range(7)])
array(['2021-08-22T04:58', '2021-08-22T05:58', '2021-08-22T06:58',
       '2021-08-22T07:58', '2021-08-22T08:58', '2021-08-22T09:58',
       '2021-08-22T10:58'], dtype='datetime64[m]')

I am copying over these thoughts to this issue because right now they’re living on a Slack chat and i don’t want to lose them because of the 10k message limit …

I can volunteer to work on the short-term plan (allow strptime strings in our TimeFormatter) right now, which should suffice to close this issue.

[lostanlen]

long-term plan after #1485:

1. support two new types in x_coords and y_coords: numpy array of datetime64 and timedelta64

2. support strftime formats in specshow (if “%” in x_axis: branch)

3. write one utility function: timedelta_like(X, sr, hop_length) (i don’t think datetime_like(X, sr, hop_length, offset) is necessary because it’s just offset + timedelta_like(X, sr, hop_length) ) the one problem i see right now is that timedelta doesn’t speak strftime. it works well up from 0:00:00 to 23:59:59 but getting it to work for negative values and for durations above one day requires custom code https://stackoverflow.com/a/63198084