Exoplayer: Seeking not available on some MP3 files (INFO used for CBR , XING for all others)

Created on 1 Jun 2017 · 2Comments · Source: google/ExoPlayer

Issue description

MP3 Files opened for ondemand playback are usually seekable except in certain cases where the INFO header is present but does not contain also a TOC (Table of contents).

MP3 File With NO INFO header --> Exoplayer Assumes CBR FILE and enables SEEKABLE (expected)
MP3 FILE WITH INFO HEADER + TOC --> Exoplayer enables SEEKABLE (expected)
MP3 FILE WITH INFO Header , But Without TOC --> Exoplayer disables SEEKABLE (Unexpected)

"XING" Headers do require that TOC be present.
"INFO" header do Not; since it declares file a CBR

Essentially, by observation, Exoplayer parses both INFO and XING headers exactly the same; but they are NOT, because "INFO" essentially declares file as CBR and extra TOC and other info is no longer required.

Unfortunately many encoders like LAME, FFMPEG will always produce INFO header without TOC (unneeded for CBR)

REF1 : http://www.multiweb.cz/twoinches/mp3inside.htm
REF 2 (FFMPEG LibavFormat Lines 397 to 409) : https://github.com/FFmpeg/FFmpeg/blob/ee5f0f1d355fa0fd9194ac97a2c8598c93ed328b/libavformat/mp3enc.c#L397

More information on XING here : https://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header (Section 2.3.1)

Reproduction steps

Example File :
Contains INFO header (Not XING)
Does NOT Contain TOC (Not needed with INFO header)

https://omnystudio.com/d/clips/4b5f9d6d-9214-48cb-8455-a73200038129/3cbd8058-2b03-42e8-bd31-a7460050b45a/2c58ee44-8693-47e9-aef2-a746005c28c0/audio.mp3?utm_source=Podcast&in_playlist=53a88408-39f1-47b3-8948-a7460050b45e

Expected to SEEK as it is a CBR file

Current Behaviour tested in version 2.0.4 of Exoplayer until 2.4.1 version of Exoplayer : Does not enable Seek.

Link to test content

Version of ExoPlayer being used

Tested in 2.04 and 2.4.1
Behavior observed in both.

Device(s) and version(s) of Android being used

Unrelated.
But as context, Native players on many Android devices handle this correctly and this "bad behaviour" is not observed. Tested on Google Pixel

A full bug report captured from the device

Not capturable behaviour problem

bug

Source

samysousa

All 2 comments

Until this is fixed, I think you can call defaultExtractorsFactory.setMp3ExtractorFlags(Mp3Extractor.FLAG_ENABLE_CONSTANT_BITRATE_SEEKING) to work around the issue.