Switch out minimp3 with the dr_mp3 implementation

[eXpl0it3r]

Description

Since @lieff seems to have stopped working on minimp3, it might be wise to switch to dr_mp3, which simplifies our implementation and might potentially have fixes for certain issues (tbd).

This also fixes #2215

Tasks

• Tested on Linux
• Tested on Windows
• Tested on macOS
• Tested on iOS
• Tested on Android

How to test this PR?

#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

int main()
{
    sf::Music music;
    music.setLoop(true);
    music.setVolume(10);

    if (music.openFromFile("file.mp3"))
        music.play();

    auto window = sf::RenderWindow{ {200, 200}, "MP3 Test" };
    window.setFramerateLimit(30);

    while (window.isOpen())
    {
        for(auto event = sf::Event{}; window.pollEvent(event);)
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
        }
    }
}

[ChrisThrasher]

I'm open to this change. It's certainly a liability to use abandoned dependencies. I believe in the past we may have hit sanitizer failures in minimp3 but I could be misremembering.

[eXpl0it3r]

Tested the implementation with various MP3 of different bitrates, mono, stereo, ID3 tags, APEv2 tags, large files, small files. So far everything played back correctly. As such for me the PR is ready for review.

[ChrisThrasher]

Are we sure this isn't too big to put into v2?

I got master caught up with 2.6.x (see #3002), merged this branch into that PR branch, fixed the new merge conflicts, then ran the tests and am seeing some test failures. Can you make sense of what is going on here? The lack of tests in v2 makes it harder to land a change like this in v2 versus v3.

https://github.com/SFML/SFML/actions/runs/9073215514

[eXpl0it3r]

In the test you've just hard coded the returned samples. There's of course no guarantee that two different decoder implementation return the exact same four samples values at the beginning of a file.

Not sure what the "correct" values should be. Looking at the files in Audacity fully zoomed in, it seems like the first few samples would equal to zero, yet on FLAC it's the same and it too does report values to start with:

Either way, I don't think this is too big. We've added audio tests in master only some months ago, so it's not like SFML didn't work before that. And of course the tests need to be adapted. minimp3 is pretty broken in a few ways and there's no fix in sight.

[eXpl0it3r]

The author of dr_mp3 mentioned to me that there is one known issue with LAME tags: mackron/dr_libs#263

Not if this warrants a mention somewhere or if we just hope for a fix before the 2.6.2 release 😄

[binary1248]

Just in case nobody noticed yet, the author of dr_libs is also the author of miniaudio and all the decoders (mp3, FLAC, wav) are also integrated into miniaudio. This PR wouldn't make sense targeting master since we would just use miniaudio for decoding instead.

[eXpl0it3r]

Cherry picking the commit onto master with the tests, we seem to run into the linked issue. The test MP3 has been encoded with LAME and the tags aren't parsed, so the timing and sample count are wrongly reported.

  CHECK( inputSoundFile.getSampleCount() == 87'798 )
with expansion:
  91008 (0x16380) == 87798 (0x156f6)

  CHECK( inputSoundFile.getDuration() == sf::microseconds(1'990'884) )
with expansion:
  2063673us == 1990884us