showspectrumpic is unreasonably RAM hungry

[ed]

Summary of the bug:
when creating a spectrogram of a large audio file, FFmpeg can easily consume 3+ GiB of RAM.

My current workaround is to replace FFmpeg with sox for this purpose, since that only needs 6 MiB for the same task -- but I prefer the output that FFmpeg produces, so looking forward to switching back.

How to reproduce:

# first produce an audio file with a long duration:
ffmpeg -f lavfi -i sine=f=140:d=12345 big.flac

# then create a spectrogram; this takes ~2.5G to process:
ffmpeg -i big.flac -filter_complex showspectrumpic=s=640x512 -frames:v 1 spec.png

[ed]

Just noticed something funkier -- attached is a song, 404 seconds long, which FFmpeg will probably play using libopenmpt once uncompressed. Curiously, this makes FFmpeg allocate 775 MiB on my systems (alpine3.19, fedora39 with FFmpeg from rpmfusion, fedora39 with one of BtbN's master builds, and a BtbN build on Windows10).

gzip -d megatune.xm.gz
/bin/time ffmpeg -i megatune.xm -filter_complex showspectrumpic=s=640x512 -frames:v 1 a.jpg
# "776228 KiB max resident memory"

Another song, ​https://a.ocv.me/pub/demo/music/chiptunes/jt_versi.xm (839 seconds) ends up allocating 1.5 GiB.

The curious part is, if you use FFmpeg to transcode these files (for example to opus), it won't go anywhere near that, instead peaking at 63 MiB.

So I tried the following workaround, but that still allocates the same excessive 770 MiB in the 2nd instance:

/bin/time ffmpeg -i megatune.xm -c:a pcm_s16le -f nut - | /bin/time ffmpeg -y -f nut -i - -filter_complex showspectrumpic=s=640x512 -frames:v 1 a.jpg

...but converting to a flac-file first, and then creating a spectrogram of that, keeps it to a more manageable 225 MiB.

Perhaps showspectrumpic isn't getting the estimated duration and it makes some unwise decisions?

Also tried using showwavespic instead of showspectrumpic; it climbs to 400 MiB with jt_versi.xm, far off from 1.5 GiB but still more than I would've expected.