MP3 file cannot be played by ExoPlayer, but can be played by Android MediaPlayer

[hexise]

Version

Media3 main branch

More version details

ExoPlayer 1.8.0

Devices that reproduce the issue

Galaxy S25 running Android 15

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

Dependencies:

implementation 'androidx.media3:media3-exoplayer:1.8.0'
implementation 'androidx.media3:media3-exoplayer-midi:1.8.0'
implementation files("libs/lib-decoder-ffmpeg-release.aar")

Play this mp3 music:

Use exoplayer to play the mp3 file.

Expected result

Play the music successfully.

The Android media player can play the music without problem.

Actual result

Error happens:

androidx.media3.exoplayer.ExoPlaybackException: Source error
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:927)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:897)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loopOnce(Looper.java:257)
at android.os.Looper.loop(Looper.java:342)
at android.os.HandlerThread.run(HandlerThread.java:85)
Caused by: androidx.media3.exoplayer.source.UnrecognizedInputFormatException: None of the available extractors (Mp3Extractor, FlvExtractor, FlacExtractor, WavExtractor, FragmentedMp4Extractor, Mp4Extractor, AmrExtractor, PsExtractor, OggExtractor, TsExtractor, MatroskaExtractor, AdtsExtractor, Ac3Extractor, Ac4Extractor, AviExtractor, MidiExtractor, JpegExtractor, PngExtractor, WebpExtractor, BmpExtractor, HeifExtractor, AvifExtractor) could read the stream. {contentIsMalformed=false, dataType=1}
at androidx.media3.exoplayer.source.BundledExtractorsAdapter.init(BundledExtractorsAdapter.java:108)
at androidx.media3.exoplayer.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1124)
at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:453)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at java.lang.Thread.run(Thread.java:1012)

Media

https://drive.google.com/file/d/171LGos4SKalByISXKalm07wDaG1EOAqO/view?usp=drive_link

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[icbaker]

The provided file starts with 2048 bytes of ID3 data, which ExoPlayer skips over so it can look for an MP3 sync pattern. The file then contains some ITAG data at byte 2048.

This ITAG data seems to include an image. ffprobe then reports that the first MP3 packet starts at byte 54515:

$ ffprobe ghi-2713.mp3  -show_packets
[PACKET]
codec_type=audio
stream_index=0
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
duration=368640
duration_time=0.026122
size=1045
pos=54515
flags=K__
[/PACKET]

This is outside the MP3 extractor's sniffing limit of 32kB:

media/libraries/extractor/src/main/java/androidx/media3/extractor/mp3/Mp3Extractor.java

Lines 141 to 144 in b7bbc6e

	/**
	* The maximum number of bytes to peek when sniffing, excluding the ID3 header, before giving up.
	*/
	private static final int MAX_SNIFF_BYTES = 32 * 1024;

This is why you are seeing the None of the available extractors could read the stream error - because Mp3Extractor gives up sniffing at 32kB before it gets past this ITAG data that it doesn't recognize.

I couldn't find any documentation online about what this ITAG data is, how it is structured, how we can determine its length in order to skip over it (like we do for ID3 data), etc.

Do you have more information about this? How was this file produced (i.e. what software inserted this ITAG data)?

It seems possible that the ITAG data is meant to be inside the ID3 data, and the ID3 data length is declared wrong, leading to this failure.

[hexise]

The MP3 file was provided by one of my app users. I asked him where the music file was from, he said it was from online tool y2mate: https://en.y2mate.is/

If MAX_SNIFF_BYTES is 32k and cannot handle this file, will enlarge the buffer size solve this problem? The Android media player can play this file without issue.

[icbaker]

If MAX_SNIFF_BYTES is 32k and cannot handle this file, will enlarge the buffer size solve this problem?

Yes, for the given file it would need to be increased to at least 54515 - 2048 = 52467. Of course, this value will change for a different file with a different amount of unrecognized data between the ID3 data and the start of the MP3 data. We don't plan to make this change in the library - because it will slow down playback start for many non-MP3 file formats, because it takes longer for Mp3Extractor to reach a negative sniff verdict (i.e. be sure the file is not MP3). You can make this change in a local fork if you think this trade-off is worth it.

If the ITAG data has a declared length that we can read and skip, we would consider adding that parsing to the library (but we'd need to understand the spec of this data in order to know how to parse it).

My working theory is that this ITAG data is meant to be inside the ID3 data, and therefore this file is badly formed because the length of the ID3 data is declared incorrectly. If this is the case then I suggest your app user reports this issue to the maintainers of y2mate.is.

[hexise]

Just a quick update, I changed the sniff bytes to 64K and the music can be played successfully.

[izyspania]

I have the same problem , i have a big library and some mp3s have some "garbage" at the start but they are playing fine in all other players.

EDIT:
I’m using Expo with the latest version of expo-audio (which uses Media3 v1.8.0).
I managed to fix the issue by doing this , posting here in case it helps anyone else. (not sure if its the best approach but its convenient)

CustomMp3Extractor.kt

package expo.modules.audio

import android.util.Log
import androidx.media3.common.util.UnstableApi
import androidx.media3.extractor.Extractor
import androidx.media3.extractor.ExtractorsFactory
import androidx.media3.extractor.mp3.Mp3Extractor

@UnstableApi
class CustomMp3ExtractorsFactory : ExtractorsFactory {

  override fun createExtractors(): Array<Extractor> {
    try {
      // Create Mp3Extractor instance
      val extractor = Mp3Extractor()

      // Use reflection to override MAX_SNIFF_BYTES
      val field = Mp3Extractor::class.java.getDeclaredField("MAX_SNIFF_BYTES")
      field.isAccessible = true
      field.setInt(null, 128 * 1024) // increase value
      Log.d("CustomMp3ExtractorsFactory", "MAX_SNIFF_BYTES updated")

      return arrayOf(extractor)
    } catch (e: Exception) {
      Log.e("CustomMp3ExtractorsFactory", "Failed to modify Mp3Extractor", e)
      // fallback
      return arrayOf(Mp3Extractor())
    }
  }
}

And in AudioModule.kt:

CONTENT_TYPE_OTHER ->  ProgressiveMediaSource.Factory(factory, CustomMp3ExtractorsFactory())  

[icbaker]

(not sure if its the best approach but its convenient)

Reflectively changing a private field is of course quite brittle - because the field may change name or type, or be deleted completely, in a new version of the library.

Based on your code snippet, you are only trying to play MP3 files (since your ExtractorsFactory doesn't provide any other extractor impls). Since sniff is only used to decide which extractor impl to delegate to, you could just change sniff() to always return true using the decorator pattern:

private static class NoSniffMp3Extractor extends ForwardingExtractor {

  public NoSniffMp3Extractor() {
    super(new Mp3Extractor());
  }

  @Override
  public boolean sniff(ExtractorInput input) {
    return true;
  }
}

[icbaker]

The commit linked above increases Mp3Extractor sniffing limit to match its "sync search" limit of 128kB.