Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Allow opting into frame-index seeking for MP3s without reliable seek metadata

Aperta
  • Qualcosa non va?
#3,492 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

@icbaker ci sta già lavorando.

Dal 28/10/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, java
Ambito
backend

Direzione di ricerca

Read the MP3 extractor seeking logic around Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING and the ConstantBitrateSeeker, IndexSeeker, and VBR metadata seeker selection. Reproduce the known-length, headerless VBR case from the issue and inspect existing extractor tests. Done means an opt-in selects accurate frame-index seeking when reliable seek metadata is absent while still honoring reliable metadata when present.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Request

Provide an opt-in way to force frame-index seeking for MP3s whose bitrate is unknown and which lack usable Xing/Info/VBRI/MLLT seeking metadata, while still honoring reliable metadata when present. The application cannot always control or preinspect files hosted by third parties and needs accurate seek/resume behavior even if scanning is slower.

Reproduction and results

Media3 1.11.1, Mp3Extractor.FLAG_ENABLE_INDEX_SEEKING, a known-length variable-bitrate MP3 without a VBR seek header:

  • Public sample, 5,567,740 bytes, 16 kHz mono, varying frame bitrates, first audio frame 8 kbps at byte 15,424. Complete frame scan: 29:36.456.
  • With the known input length, the extractor chooses ConstantBitrateSeeker and reports 92:32.316. Seeking to 15:04 resolves to byte 919,564, approximately 4:49 in the audio. End-of-audio can consequently be followed by a long silent tail.
  • With the input length presented as unknown to the extractor in a local experiment, the same flag selects IndexSeeker and reports approximately 29:36 after the full scan. A lossless remux adding a Xing header selects XingSeeker and also reports the correct duration.

These results were reproduced against the real extractor in a Robolectric test and are consistent with the player duration captured on a Pixel 9a running Android 17. The code path is not limited to that device. They are not a claim that a complete standalone Media3 demo app has been tested.

Context

Issue #3017 describes the same class of headerless VBR media and discusses customizing computeSeeker. Issue #2848 and the 1.9.0 release notes explain why constant-bitrate seeking was made the default when no VBR metadata is present. An explicit opt-in would let applications choose accurate frame indexing for unknown files without maintaining an extractor fork or hiding input length from the parser; the performance tradeoff is acceptable for some use cases.

Agent: codex
Agent-Model: gpt-6

Lingua principale
Java
Stelle
3.1k
Fork
998
Merge medio
6g 8h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di androidx/media

Tutte le issue di androidx/media

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.