Issues with quality of sound recordings

[pisum]

@dan_johnson

compression in the sound recordings be turned off

saving as lossless audio probably only makes sense if the original audio was losseless. in other words:

@pisum

if a file was recorded as ALAC, and if ALAC isn’t considered acceptable for universal playability, maybe it could be converted to WAV instead of AAC?

…

@dan_johnson

until a more appropriate level of compression is determined

just reading through some of the ffmpeg’s AAC encoding documentation, it seeems like the quality of the encoded audio might be the best you can already get out of the native codec. so improving quality might involve using a different codec, but using other codecs might be possible for other reasons.

it’s not clear to me why any MP4 file encoded in either AAC or ALAC might get re-encoded as AAC (rather than just copied as is). maybe the initial hurdle to be solved is to find a way to determiine which codec was used to encode an MP4 file.

[pisum]

revisiting this, i think it’s possible to greatly improve the quality of the M4A compressed audio files simply by updating ffmpeg on the server to a newer version. (@tiwane – i think this sort of thing would be relatively low effort and low risk from a development perspective, although you might still need to devote some time to test it robustly.)

see the screenshot below:

i took dan_johnson’s audio file (spectrogram in the bottom left) and encoded it on my own machine using the same settings as the server uses (spectrogram in the top left, command in the bottom right). comparing it to the file from iNat (spectrogram in the top right), you can see that although both the file i encoded and the file from iNat cut off a lot of stuff above 16kHz or so, the iNat file has a lot more black holes in the lower range of the audio that i think is what makes that audio file sound bad. the file i encoded looks much more clean (and sounds much better, too).

my encoded file ended up a tiny bit smaller, too: 95358 bytes vs 95665 bytes.

using ffmpeg to show which codec was used to encode the files (bottom right), it looks like my file was encoded using a codec that corresponds to ffmpeg v6.1 (Nov 2023), and iNat’s file was encoded using a code that corresponds to ffmpeg v4.1 (Nov 2018). just to make sure iNat hasn’t already updated ffmpeg since we last discussed the problem, i uploaded dan_johnson’s original file this morning, and analyzed the result, and it still shows that the file was encoded using the old codec.

so bottom line, i think ffmpeg on the server just needs to be updated.