Some MP3 no more have duration and can't be seeked

[Tolriq]

Version

Media3 main branch

More version details

Last commit from today.

Devices that reproduce the issue

All

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

Play attached media with Mp3Extractor(Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING) or Mp3Extractor(Mp3Extractor.FLAG_ENABLE_CONSTANT_BITRATE_SEEKING or Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING)

Removing FLAG_ENABLE_INDEX_SEEKING restore normal behavior (or use Mp3Extractor.FLAG_ENABLE_CONSTANT_BITRATE_SEEKING)

From the docs enabling FLAG_ENABLE_INDEX_SEEKING disable FLAG_ENABLE_CONSTANT_BITRATE_SEEKING so is maybe the cause ? I was hoping the last commits would allow to have all the cases working properly now.

Expected result

Media can be seek and report duration.

Actual result

Media can't be seek and no duration reported.

Media

Ed Sheeran - + - 01 - The A Team.mp3

Bug Report

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

[rohitjoins]

Hi @Tolriq,

The behavior you are observing with FLAG_ENABLE_INDEX_SEEKING is expected. This flag builds a seek map as the file is read, and the duration and seek map are only finalized once the entire file has been loaded. This is necessary to accurately determine the duration and allow for precise seeking, especially for files that do not have a constant bitrate.

To confirm this, you can allow the file to load completely. As a faster alternative, you can seek forward multiple times in the demo app to trigger the full loading of the file. Once loaded, the duration will be correctly reported, and seeking will be enabled.

As the documentation states, FLAG_ENABLE_INDEX_SEEKING should be used when:

- The file is small.
- The bitrate is variable (or it's unknown whether it's variable).

From the docs enabling FLAG_ENABLE_INDEX_SEEKING disable FLAG_ENABLE_CONSTANT_BITRATE_SEEKING so is maybe the cause ?

Yes, the flags FLAG_ENABLE_INDEX_SEEKING and FLAG_ENABLE_CONSTANT_BITRATE_SEEKING are mutually exclusive. You should set one of them based on your requirements (performance vs accuracy).

FLAG_ENABLE_INDEX_SEEKING is working as intended for your test media, but the duration is determined late in the process. For this reason, there is no fallback to FLAG_ENABLE_CONSTANT_BITRATE_SEEKING.

[Tolriq]

@rohitjoins this makes b32fa8c a lot less useful, we don't know before hand the details since it's the extractor job to provide them.

If that setting disable Mp3Extractor.FLAG_ENABLE_CONSTANT_BITRATE_SEEKING how can we properly handle all cases ?

Apps that plays random provided user files have no way to switch at runtime the flags.

[rohitjoins]

@rohitjoins this makes b32fa8c a lot less useful, we don't know before hand the details since it's the extractor job to provide them.

Previously, FLAG_ENABLE_INDEX_SEEKING would take precedence over any seeking metadata present in the file. This was problematic because many developers were using this flag as a fallback for files that lacked metadata, not as the primary seeking method. This change ensures that the extractor prioritizes existing metadata, which is generally the intended behavior.

If that setting disable Mp3Extractor.FLAG_ENABLE_CONSTANT_BITRATE_SEEKING how can we properly handle all cases ?

If you know that your users will not want to wait for the seek bar to become available, then setting FLAG_ENABLE_INDEX_SEEKING may not be the right choice for your application. The flags are designed to give you, the developer, control over the trade-off between performance and accuracy.

Instead, you can use FLAG_ENABLE_CONSTANT_BITRATE_SEEKING, which will provide immediate seeking and duration for most files, maybe with some potential inaccuracy for VBR files.

[rohitjoins]

Hi @Tolriq,

We discussed this internally (cc: @icbaker) and made some changes to how the flags are prioritized in f640c25. Hope that resolves the issue for you.