Seeking to 0 makes it impossible to read until end of file

[Biohazard90]

I'm using SFML https://github.com/SFML/SFML which in turn uses minimp3. Certain mp3 files fail to continue looping after the first loop.

It looks like minimp3 stops returning the expected data until EOF after using mp3dec_ex_seek(dec, 0). This only happens on specific files. Due to never reaching the expected end, SFML inconveniently just stops playing audio altogether.

Looking through the debugger, the "offset" member of the decoder object is incorrect after seeking to 0 vs when playing a new file from scratch. I've made a blind guess and moved position += dec->start_delay; after the if (0 == position) block and that seemed to have fixed it. But I practically have no understanding of what's going on and no time to dive more into it, so I'm not comfortable with making a pull request since I might be totally off the mark here.

minimp3/minimp3_ex.h

Line 736 in afb604c

position += dec->start_delay;

I've attached an audio file from my users that experience this issue for repro:

Feeling - Tung Wasabi (mp3cut.net).mp3.zip

[Biohazard90]

There is another issue where certain files never reach the end of the expected sample count even before looping. The expected sample count (detected_samples) does not appear to match the available data in this case (cur_sample never reaches detected_samples) - minimp3 attempts to continue reading data although EOF is reached, this again causes SFML to malfunction and stop playing instead of looping.

I'm attaching a file exhibiting this behavior again. In this case I will likely change SFMLs behavior now to be more robust against this unexpected EOF issue and just loop the file instead of erroring out, but it seems the underlying issue is in minimp3 too.

SIERRA - UNBROKEN (mp3cut.net).mp3.zip

[eXpl0it3r]

Any update on this, @lieff?

[eXpl0it3r]

Looks like this was fixed in dr_mp3 implementation that uses minimp3's decoding. If anyone is looking for an alternative, I can recommend switching to dr_mp3.