ok. prior to this, you seemed to be describing a situation where the iOS iNat app records lossy compressed audio, whereas your iOS VoiceMemo app is theoretically capable of recording lossless compressed audio. it wasn’t obvious in the information that you provioded previously that you were recording lossless compressed audio in VoiceMemo though, but your new information does suggest that you probably are recording lossless here.
but then on top of IOS iNat lossy vs VoiceMemo lossless difference, there’s probably a second thing related to processing on the iNat server when sound files are uploaded.
as of late 2019, it looks like uploaded sound files which are not WAV or MP3 are sent through a thing that converts them to a common (AAC?) format in a M4A container. in mid 2020, there were additional changes to reduce the amount of compreesion that is applied in this process (to the minimum compression).
so this is probably where potential problems could be introduced upon upload. however, the timing of the code changes doesn’t seem to fit the description of a reduction in sound quality starting “a year or so ago”.
i didn’t dig around deep enough to figure out exactly which version of ffmpeg and which codecs are being used for this conversion, but unless one of those changed within the “last year or so ago”, i don’t think there would be any other way something would have changed recently. if there is a problem, it likely would have been a problem for about 5 years now.
i don’t load many non-WAV/-MP3 files, but i did find a case from 2022 where i loaded an M4A file, and i do see that in the observation, the sound file was actually resaved as a higher bitrate file than the original (probably since the original file would have been somewhat heavily compressed, and the conversion during upload would have re-saved it with minimal compression). i reuploaded the original file again to the observation, and the resulting second audio file was similar to the file on the previous observation (though not exact), suggesting that no major changes in the way the system does that conversion had occurred since then.
your original recording is lossless compressed audio (ALAC in a M4A container). however, because it’s not WAV, the file gets converted to lossy compressed audio (AAC in M4A) when you upload it to iNat.
comparing the file in the observation vs your original file, i can see that probably the biggest difference is that you’ve lost most frequencies above about 16kHz, and then there are some compression / artifacts on top of that, i think.
i’m a little surprised that AAC with minimum compression would produce a file that is noticeably different, but maybe additional tweaking of settings or maybe a better codec could make the differences less noticeable. i’m not sure why there is that process to convert stuff into AAC. maybe because MPEG4 files could contain many different types of audio, some folks run into issues playing some MPEG4 files, and saving them all as AAC makes them (more) universally playable?
for non-WAV/-MP3 files, i think it should be possible to determine what the underlying audio codec is. so 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?