Match MediaPlayer behavior of skipping unexpected data the start of an MP3

I'm trying to play the following file with EXOPlayer 2.9.6 and it fails with the following exception:
UnrecognizedInputFormatException

http://podcastdownload.faithcomesbyhearing.com/mp3.php/ENGKJVC2DA/A01___01_Genesis_____ENGKJVC2DA.mp3

I experienced the same thing on every test devices, while the device MediaPlayer was able to play the file without any issue (Tested on Android 8, 9, Q on Pixel 2, 3 and Samsung S8)

It fails both trying to stream the file or play a local copy

I checked the file encoding and didn't see anything specific
Audio

Stack

com.google.android.exoplayer2.source.UnrecognizedInputFormatException: None of the available extractors (MatroskaExtractor, FragmentedMp4Extractor, Mp4Extractor, Mp3Extractor, AdtsExtractor, Ac3Extractor, TsExtractor, FlvExtractor, OggExtractor, PsExtractor, WavExtractor, AmrExtractor) could read the stream.
    at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractorHolder.selectExtractor(ExtractorMediaPeriod.java:973)
    at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:891)
    at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:381)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
    at java.lang.Thread.run(Thread.java:914)

This issue does not seem to follow the issue template. Make sure you provide all the required information.

It looks like the stream is prefixed with some text data before the ID3 header appears at offset 0x125.

This should be ignored by the Mp3Extractor as the MediaPlayer seems to already do this

I'll tentatively mark this as a low priority enhancement. Identifying media prefixed by arbitrary other data doesn't seem particularly useful, nor is it possible to do it efficiently in general, but getting the same behavior as the platform player is reasonable.

In the short term I think the best options are to fix the media, or write a custom data source that identifies the actual start of ID3 data (assuming that's always expected) and throws away anything before that.

Fixing the media isn't a possibility for apps playing 3rd party content such as podcast apps for example. Maybe this workaround could be done right after UnrecognizedInputFormatException has been thrown a 1st time

…

On Thu, Apr 4, 2019 at 6:21 AM Andrew Lewis ***@***.***> wrote: I'll tentatively mark this as a low priority enhancement. Identifying media prefixed by arbitrary other data doesn't seem particularly useful, nor is it possible to do it efficiently in general, but getting the same behavior as the platform player is reasonable. In the short term I think the best options are to fix the media, or write a custom data source that identifies the actual start of ID3 data (assuming that's always expected) and throws away anything before that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5718 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_0fmW2VKUpQcxcvNCFM9wwyGzfT0Qoks5vdfw9gaJpZM4cYLs6> .

But Exoplayer should at least handle the files supported by the mediaplayer, otherwise either developers won't switch to ExoPlayer or they will keep both options in their app like I'm doing right now (which is a mess)

…

On Fri, Apr 5, 2019 at 6:54 AM Oliver Woodman ***@***.***> wrote: I agree with @andrewlewis <https://github.com/andrewlewis> this is low priority. A decision on how far to look into a file for valid media content before giving up is very arbitrary. I don't think we're obligated to support such streams. For what it's worth I tried to play the stream using whatever the default player is on my MacBook, and it didn't work there either. Aside/Opinion: Podcast apps have a hard time of it currently because a significant percentage of podcast streams today are malformed. In particular the way many podcast streams just have advert audio "shoved on the front" in a way that doesn't properly adhere to any kind of specification. This kind of thing subtly breaks features like accurate seeking within streams. It's inevitable that this kind of thing leads to a lower quality user experience. Client players can try and mitigate things to some extent, but it's not possible to do so fully. In my view, this means that the podcast industry has a problem that the relevant industry players should be trying harder to address. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5718 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_0frtBj3G6tnsThVDI6OnEJKsTWiPwks5vd1WNgaJpZM4cYLs6> .

That argument only really stacks up if there are a significant number of problematic files in the wild. If you've come across a single file that has this problem, which doesn't even play properly on some other platforms, then it really doesn't justify the extra engineering effort of keeping two players around in your app, and neither does it justify effort on our side to accommodate this single file. If the problem is more widespread, it would be good to know what the source of these files and some idea of how many streams are affected. Else this remains a low priority issue.

Looks like the issue still exists with 2.10.7
I can reproduce it with the following stream: http://rogers-hls.leanstream.co/rogers/gra977.stream/playlist.m3u8

Maybe this ffmpeg commit and the description can help:
FFmpeg/FFmpeg@2b3e9bb

avformat/mp3: skip junk at the beginning of mp3 files

Apparently it can happen that a mp3 file has junk data between id3 tag
and actual mp3 data. Skip this to avoid outputting nonsense timestamps.
(Two packets had the same timestamps, because the mp3 parser failed to
compute a frame duration.)
In this case, the junk consisted of 1044 bytes of zero, which
incidentally is the same size as normal mp3 frames in this stream. I
suspect the mp3 was edited with some tool which wiped the Xing/LAME
headers. Data near the end of the file suggests it was encoded with
"LAME3.97", but the normal Xing/LAME headers are missing. So this could
be "normal". mpg123 also attempts to skip at least 64KB of junk data by
scanning for headers.

@kim-vde

@kim-vde It may be interesting to consider this in the context of the sniffing improvements you are working on. I guess if MP3 ends up at the end of the list of extractors we can read ahead further during sniffing before giving up.

As mentioned in #8317 (comment), we should consider supporting parsing of ID3 data that is not at the start of the file.

Add some fuzziness to Mp3Extractor's ID3 tag searching

I think this should be handled by the commit linked above.

Add some fuzziness to Mp3Extractor's ID3 tag searching

Navigation Menu

Repository navigation

Match MediaPlayer behavior of skipping unexpected data the start of an MP3 #5718

I checked the file encoding and didn't see anything specific
Audio

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Match MediaPlayer behavior of skipping unexpected data the start of an MP3 #5718

Description

I checked the file encoding and didn't see anything specific Audio

Activity

google-oss-bot commented on Apr 2, 2019

andrewlewis commented on Apr 2, 2019

theboubougne commented on Apr 2, 2019

andrewlewis commented on Apr 4, 2019

theboubougne commented on Apr 4, 2019

1 remaining item

theboubougne commented on Apr 5, 2019

ojw28 commented on Apr 7, 2019

theboubougne commented on Nov 13, 2019

halaei commented on Apr 4, 2020

andrewlewis commented on Apr 6, 2020

kim-vde commented on Dec 8, 2020

icbaker commented on Jul 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

I checked the file encoding and didn't see anything specific
Audio