Description
openedon Jun 1, 2017
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)
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
