I’ve noticed a consistent and distracting "audio bleed" whenever the Repeat Ayah and Range setting is active. Instead of terminating cleanly at the end of the selected Ayah, the playback engine triggers 1-2 letters (approximately 200-500ms) of the subsequent Ayah before the loop reset or the range stop kicks in.

This happens across almost all recitations (Mishar Al-Afasy WBW, etc.) and across different styles like Mujawwad and Murattal. It breaks the flow of memorization and tajweed practice and is very ditracting. To be really honest, I am facing this issue since 3 years but now I want this issue to be fixed more than ever.

Steps to Reproduce:

1. Open Surah Al-Baqarah.

2. Set Range/Repeat to Ayah 5 only (Ayah 5 to Ayah 5).

3. Listen to the end of the Ayah ("...muflihoon").

Observed Behavior:

The audio plays "...muflihoon," followed by a brief 0.5s pause, then you clearly hear the start of Ayah 6 ("In-") before the player suddenly snaps back to the start of Ayah 5.

Case 2 Example:

If playing a range of Ayah 5 to 6, it will play Ayah 5, pause, bleed into the start of Ayah 6, stops and snaps again to play Ayah 5, pause, play Ayah 6, and then bleed into the start of Ayah 7 ("Khatam-"), stops and snaps again to play Ayah 6, bleed into the start of Ayah 7 ("Khatam-") before stopping.

Technical Hypotheses for Development Team:

Hypothesis 1: Race Condition

It seems the "Repeat" check logic is being evaluated post-buffer initialization for the next track. If the method to trigger the next audio segment is called before the switch-case or conditional check for the 'repeat' variable, the playback engine has already begun streaming the next file/segment before the UI or logic layer interrupts it to loop back. The "Play Next" method is dominating the "Check Repeat" logic.

Hypothesis 2: Inaccurate Metadata

The issue might be at the data level. If the audio files were segmented using an automated VAD (Voice Activity Detection) or batch-chopping software without manual padding adjustment, the "End of File" (EOF) or timestamp markers likely include a trailing buffer. This would mean the actual audio data for "Ayah 5" physically contains the first few milliseconds of "Ayah 6," making it a content-level splicing error rather than a code logic error. This is more visible in Regular recitation of Fatih Seferagic where the chops are somewhere mid-ayah suggesting that there was no manual intervention to review ayah-by-ayah audio.

Hypothesis 3: Latency in Stop Command

The playback engine might be utilizing a look-ahead buffer. If the stop/loop command isn't sent with enough lead time to the audio hardware abstraction layer, the "tail" of the buffer (which already contains the start of the next Ayah) is flushed through the speakers before the stop command is processed.

Environment:

App: GTAF Quran (Android)

Reciters tested: Mishary Al-Afasy WBW, Fatih Seferagic, Various Murattal/Mujawwad.

Would love to get some dev eyes on this—fixing this would make the repeat functionality much more seamless for hifz!