Fix crash when trying to load an invalid mp3 file

[DeleteSystem32]

This should fix #55457 by adding an additional check for mp3 file validity.
Additionally, minimp3 is updated to the newest version.

[akien-mga]

Looks good! Please also update the commit hash for minimp3 in thirdparty/README.md.

[akien-mga]

Maybe this can be given an explicit error message with the _MSG variant of the macro, as otherwise this might be a bit cryptic to users (especially as this often would happen in a chain reaction of failed loading errors).

[DeleteSystem32]

Good point! I've gone ahead and updated the commit; should hopefully be all good now.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 3.5.

I only cherry-picked the library update + the new error check, as the refactoring seemed not to be valid in 3.x, where the data is allocated via the AudioServer: 8a4c583.

For master, I've noticed some differences between the implementation of AudioStreamMP3 initially ported from 3.x and the one of other streams like AudioStreamOGGVorbis, might be worth giving it another check to further sync to the current design of audio streams (e.g. there's no set_data(), get_data() and clear_data(), I guess things are now done differently?).

[akien-mga]

Cherry-picked for 3.4.1.

[DeleteSystem32]

For master, I've noticed some differences between the implementation of AudioStreamMP3 initially ported from 3.x and the one of other streams like AudioStreamOGGVorbis, might be worth giving it another check to further sync to the current design of audio streams (e.g. there's no set_data(), get_data() and clear_data(), I guess things are now done differently?).

I was wondering about that as well at first, but I think it's just due to how the new implementation of AudioStreamOGGVorbis works. It stores its data as a OGGPacketSequence now, so the accessors are just named differently. AudioStreamSample still has the raw data accessors as well.