saving as lossless audio probably only makes sense if the original audio was losseless. in other words:
…
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.
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.)
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.
@tiwane – i think this should be revisited in light of the new “Evidence accurately depicts organism or scene” Data Quality Assessment metric. it really looks like simply installing a more up-to-date version of ffmpeg should fix the problem.
I learned my lesson last year never to record high frequency sounds with the iNat app, but to do so on a secondary recording app and upload the file later. I’m not sure if that problem still persists now for me (it did for a while), but I would like to put in my experience just for the record.
This means that if the problem still exists, it severely handicaps most recordings of Orthoptera, which is a group of cases that never seem to be considered (and are unique in how high frequency the sounds tend to be, compared to say birds or cicadas).
just to clarify a bit, the problem we were discussing in this thread has to do with the way the server converts all m4a files. the problem would arise regardless of whether you uploaded in the app or on a computer. if you recorded to wav or mp3 format, that would bypass this particular problem though, since the conversion of those formats seems to be cleaner, if it’s done at all. so maybe your workaround was really that you recorded to wav or mp3.
I uploaded a 147KBit/s .m4a file to an observation and when I downloaded that same audio from the observation, it was a smaller .m4a file encoded at 70KBit/s. That is good for mono voice dictation, but poor for stereo wildlife. Some audio uploaded through the app is barely recognizable and sounds like a poor cell connection. Sub-100KBit/s stereo .m4a files full of artifacts are pretty common on iNat. Why does it convert to such low bitrates? Why are they converted in the first place?
