Android Auto ExoPlayer seeking of the audio track creates error while seeking to the end of the track

[parkbrakereminder]

Version

Media3 pre-release (alpha, beta or RC not in this list)

More version details

I used v1.3.1 with experiencing the error while testing in the vehicle, then reproduced on the Desktop Head Unit simulator. Linking my finding to the issue #1376, #1376.
Reproduction is on the tracks with the non-MP3 data at the end of the file.
Issue is present w v1.4.1-rc01
Issue is disappers by downgrading to v1.2.1

Devices that reproduce the issue

Samsung
+Desktop Head Unit
or any vehicle system w Android Auto, since UI is part of the companion device, so the seeking bar.

ExoPlayer versions >1.2.1

Devices that do not reproduce the issue

ExoPlayer versions = 1.2.1

Reproducible in the demo app?

Yes

Reproduction steps

play song w non-MP3 data inside the file and seek to the end of the file, while playing

Expected result

turn over to the next song in the playlist

Actual result

Source Error, player stops playing and freezes, by pushing the button to jump to the next song on the controls outside the player and then push play button -> next song is playing. So, I came to the MP3 Exractor Issue, related to wrong calculation of the file lenght.

Media

Bug Report

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

[icbaker]

Please can you provide us with the MP3 file that causes this issue?
Please either upload it here or send it to android-media-github@google.com with the subject Issue #1563. Please also update this issue to indicate you’ve done this.

[parkbrakereminder]

Please can you provide us with the MP3 file that causes this issue? Please either upload it here or send it to android-media-github@google.com with the subject Issue #1563. Please also update this issue to indicate you’ve done this.

Hi Ian, I have sent the file via email.

[icbaker]

Thanks for providing the media, this looks like a duplicate of #1480

[parkbrakereminder]

Hi Ian, does it mean, the issue will be fixed in the 1.4.x version of ExoPlayer?

[parkbrakereminder]

Hi Ian, the fix in the #1480 needs to be written by myself inside the mp3-extractor, or will this be part of upgrades planned for 1.4.x release of ExoPlayer? greetings Am Mi., 31. Juli 2024 um 17:41 Uhr schrieb Ian Baker < ***@***.***>:

…

Thanks for providing the media, this looks like a duplicate of #1480 <#1480> — Reply to this email directly, view it on GitHub <#1563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMHDG3Z6EFCZAW7EQYRDTN3ZPEARLAVCNFSM6AAAAABLM3RT76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQHAZDAOJSHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[icbaker]

Please see #1480 (comment)

[parkbrakereminder]

Hi Ian,

I changed to 1,4,1 ExoPlayer as it shall fix the problem, but some song tracks are still producing the same error as before. I have written an email to you, w the MP3 attached, which leads to the failure again, while seeking to the end of the song, or if it is playing to the end by itself without seeking manually.

Could you please check again, what is wrong with the lenght calculation inside the MP3 Extactor?

Thx upfront!

[icbaker]

Thanks for sharing the media.

This file is CBR but contains non-MP3 data at the end of the file after byte 9268060 (the end of the last MP3 packet [1]). The file is 9428879 bytes long, so that's 9428879 - 9268060 = 160819 = 161kB of extra non-MP3 data.

It also contains non-audio data at the start of the file (but within an MP3 frame), so the audio doesn't start until byte 161775.

The file doesn't seem to contain any metadata at the start to indicate to a player how long the MP3 data is, so we have to assume it extends to the end. This means:

1. Since we derive the duration of the file from the number of audio bytes and bitrate (since the file is CBR), we calculate an incorrect duration
   • We calculate the audio length as fileLength - startOfAudio = 9428879 - 161775 = 9267104 bytes, which at 320kbps is 9267104 * 8 / 320000 = 231.68s = 3m51.68s
   • The timestamp of the end of the last frame (from ffprobe [1]) is 227.631020 + 0.026122 =
2. When we reach the end of the file, we crash because the data stops looking like MP3 data.

This error occurs on both 1.2.1 and 1.4.1 (unlike the file you originally shared in this issue), so this isn't a regression.

google/ExoPlayer#5718 tracks the similar case of non-MP3 data at the beginning of a file.

It's worth noting that VLC also can't handle this file correctly. It also says the duration is 3:51 but audio stops early and the progress bar suddenly jumps to the end.

I have modified Mp3Extractor locally to treat the case of "can't find the next MP3 header" as "end of file" rather than "fail playback". This changes the behaviour to be a bit more similar to VLC - playback no longer fails at the end, but it is silent until the position reaches 3:52 (rather than jumping to the end when the MP3 data is exhausted). I've sent this for review, and we will discuss as a team if this is a change we want to make to the library - possibly behind an extractor flag.

---

[1] From ffprobe:

$ ffprobe -show_packets ghi-1563-caliban.mp3
...
[PACKET]
codec_type=audio
stream_index=0
pts=3212328960
pts_time=227.631020
dts=3212328960
dts_time=227.631020
duration=368640
duration_time=0.026122
size=1045
pos=9267015
flags=K__
[/PACKET]

[icbaker]

The commit above resolves the crash, instead playback jumps suddenly to the end when it encounters enough non-MP3 data. This means the duration of files like this is still shown incorrectly (until the loading position reaches the end), but there's not really anything we can do about this because the file doesn't contain enough info to know in advance how long the MP3 data is (and therefore its duration).

[parkbrakereminder]

Ok, thanks for the clarification. Ian Baker ***@***.***> schrieb am Mo., 2. Sept. 2024, 11:22:

…

The commit above resolves the crash, instead playback jumps suddenly to the end when it encounters enough non-MP3 data. This means the duration of files like this is still shown incorrectly (until the loading position reaches the end), but there's not really anything we can do about this because the file doesn't contain enough info to know in advance how long the MP3 data is (and therefore its duration). — Reply to this email directly, view it on GitHub <#1563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMHDG36SZENMXJIL5KQVS43ZUQU6DAVCNFSM6AAAAABLM3RT76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRUGI2DOMZXGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>