FS#13118 : Incorrect playback position when seeking AAC files downloaded by youtube-dl

Quick Actions

View Dependency Graph

Status Unconfirmed
Percent Complete
0%
Task Type Bugs
Category Music playback
Assigned To No-one
Operating System Sansa Clip+
Severity High
Priority Very Low
Reported Version Release 3.14
Due in Version Undecided
Due Date Undecided
Votes
1
- nasiu2 (2021-02-03)
Private

Attached to Project: Rockbox
Opened by cunt - 2017-05-31

FS#13118 - Incorrect playback position when seeking AAC files downloaded by youtube-dl

I downloaded this: https://www.youtube.com/watch?v=Lrb0dHKJBR4 using the youtube-dl python program. The file plays and seeks correctly in foobar2000 and MPC-HC. But, on my clip+, whether I seek 10 seconds or 10 minutes into the file, it ends up playing a position of the file previous to the one displayed. For example, if I seek 50 seconds forward from the beginning, it will play the file from the start, while the screen still displays as if it's playing from 50 seconds onwards. Seeking to the end of the file will have it play a section from about 2 minutes earlier than it should be, while the time display and music will continue until 1:14:20, with the file actually being 1:12:46.

I did not hear the files being played slower than they should be, so it seems it's only an issue when seeking.

I've confirmed this happens on every AAC file downloaded by youtube-dl, and that re-encoding the same file to AAC using NERO encoder makes the problem dissapear.

Comments (3)
Related Tasks (0/0)

nasiu2 commented on 2021-02-03 16:47

I seem to have a similar issue with my Sansa SanDisk Clip Zip with a m4a file with AAC.
While seeking I'm only able to hit/resume certain special seemingly random timestamps in the file.
If I fast forward only some seconds, I still resume on the same timestamp I started (with a wrong display of time).
Only if I forward far enough to 'hit' the next special timestamp, I land on the next one, but it is not possible to forward to a position between two seemingly arbitrary timestamps regardless of what I do.
Because the displayed time is incorrect and not matching the current listening position, the remaining time displayed can go negative then.
All in all, it makes it basically impossible to go to a desired position in a file, because firstly you can't trust position information displayed and secondly if the your desired position isn't near one of those special reachable 'timestamps', you have to go to the next special 'timestamp' and just resume normally from there.