Can not play mp3 file

[gemiren]

[REQUIRED] Issue description

The ExoPlayer demo app fails to play this mp3 file: http://traffic.libsyn.com/bigbrains/Bobby_Kasthuri_9.10.18.mp3.

The same file plays fine with Android MediaPlayer class on Pixel 3.

[REQUIRED] Link to test content

http://traffic.libsyn.com/bigbrains/Bobby_Kasthuri_9.10.18.mp3

[REQUIRED] A full bug report captured from the device

7030-7030/com.google.android.exoplayer2.demo E/EventLogger: internalError [0.52, 0.00, window=0, period=0, loadError]
    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:764)

[REQUIRED] Version of ExoPlayer being used

2.10.1

[REQUIRED] Device(s) and version(s) of Android being used

Pixel 3. Android P.

[ojw28]

Playback works if we increase Mp3Extractor.MAX_SNIFF_BYTES to 128 * 1024. We should figure out why though. @gemiren - Are you aware of any non-mp3 data prefixed onto the front of the file?

[gemiren]

@ojw28, I don't know how to check whether there are any non-mp3 data prefixed on the front of the file. Below is the metadata I got from MediaInfo program:

General
Format                                   : MPEG Audio
File size                                : 22.3 MiB
Duration                                 : 24 min 15 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 128 kb/s
Track name                               : Bobby Kasthuri 9.10.18
Encoded by                               : Hindenburg Journalist Pro 1.80.2238
Recorded date                            : 2018

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Format settings                          : Joint stereo / MS Stereo
Duration                                 : 24 min 15 s
Bit rate mode                            : Constant
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Frame rate                               : 38.281 FPS (1152 SPF)
Compression mode                         : Lossy
Stream size                              : 22.2 MiB (100%)

Anyway, is it possible to allow to customize the Mp3Extractor.MAX_SNIFF_BYTES instead of a fixed value? Thanks.

[ojw28]

Anyway, is it possible to allow to customize the Mp3Extractor.MAX_SNIFF_BYTES instead of a fixed value? Thanks.

This isn't really the right solution, given there's probably something else going on. Looking at the start of the file:

$ hexdump test.mp3 | head
0000000 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70
0000010 70 6c 69 63 61 74 69 6f 6e 2f 6f 63 74 65 74 2d
0000020 73 74 72 65 61 6d 0d 0a 0d 0a 49 44 33 03 00 00

49 44 33 is the start of the ID3 header (i.e. valid data for an MP3 file to contain). If I remove the preceding 42 bytes then the file plays fine. The obvious next thing to figure out is what the first 42 bytes are. I tried putting them through this hex to ascii converter, and got:

Content-Type: application/octet-stream

Is it possible that the server is misconfigured, and is for some reason putting the content type response header into the response body by mistake? Or is this a valid thing that servers are allowed to do? I've not seen it before, in any case. Is the content and/or the server under your control?

[ojw28]

I think it's much more likely that the content type is actually prefixed onto the file on the server, rather than the server putting it there when it constructs the response. This is probably just a case of malformed media.

[ojw28]

Note: We will probably dupe this onto #5718.

[ojw28]

Marking as a duplicate of #5718.