UnrecognizedInputFormatException only on Android

Hi,
When trying to run the attached mp3 Exoplayer is unable to find an extractor to play it.

2020-12-04 16:54:42.544 30591-30591/com.google.android.exoplayer2.demo E/EventLogger: playerFailed [eventTime=1.06, mediaPos=0.00, window=0, period=0
      com.google.android.exoplayer2.ExoPlaybackException: Source error
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:554)
        at android.os.Handler.dispatchMessage(Handler.java:103)
        at android.os.Looper.loop(Looper.java:237)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: com.google.android.exoplayer2.source.UnrecognizedInputFormatException: None of the available extractors (Mp3Extractor, FlvExtractor, FlacExtractor, WavExtractor, FragmentedMp4Extractor, Mp4Extractor, AmrExtractor, PsExtractor, OggExtractor, TsExtractor, MatroskaExtractor, AdtsExtractor, Ac3Extractor, Ac4Extractor) could read the stream.

I Have already tried to add ffmpeg

2020-12-04 16:54:41.460 30591-30591/com.google.android.exoplayer2.demo I/DefaultRenderersFactory: Loaded FfmpegAudioRenderer. But it fails before playing…

iOS SMPlayer and Browser audio tag are playing fine the file. Other Mobile players as VLC also manage to play fine.

Is there something i can enable to add more extractors or anything i can do to play said file?

03 Gasolina loudcds.mp3.zip

Describe how the issue can be reproduced, ideally using the ExoPlayer demo app or a small sample app that you’re able to share as source code on GitHub. To increase the chance of your issue getting attention, please also include:

• ExoPlayer 2.12.2
• Android 10,9,8
• Android Galaxy S10 (but tested in others also)

Thanks!

[ojw28]

The file seems to be prefixed with a random string:

----dio-boundary-1450039431
content-disposition: form-data; name="file"; filename="03 Gasolina @loudcds.mp3"
content-type: audio/mpeg

The actual valid part of the file starts at byte offset 139. It’s almost as if some response headers from a web server have been incorrectly prefixed onto the front of the file.

@kim-vde - Mp3Extractor sniffs up to 32KB looking for valid MP3 data, after the ID3 header has been skipped if one is present. However, sniffing does not allow for any uncertainty in the location of the ID3 header itself. It’s either found at byte offset 0, or it’s considered not present. Do you think it’s worth searching a certain number of bytes to try and locate the ID3 header? In this case it would be found at byte offset 139, skipped, and then the regular 32KB sniffing for valid MP3 data would work successfully. Note that this also allows successful parsing of the ID3 header, where-as just increasing MAX_SNIFF_BYTES does not (although it would allow for successful playback if increased by a sufficiently large value!).

It’s pretty clear that the file itself is not a valid MP3 file, so this is about deciding how robust/tolerant we want to be, rather than about correctness.

[kim-vde]

I will close this issue as it is a duplicate. Improving handling of non-MP3 and non-ID3 bytes at the start of an MP3 file is in our list of improvements, but it is low priority for now because this type of files is uncommon.