WMA fast forward not-quite-right for longer files

[OldSchool]

I wasn't sure whether to raise a bug report on this - a search of forums and bug reports yielded some similar issues.

For longer WMA files (> ~4 minutes @ 128 Kbps - common in "classical" music), a seek/FF that spans more than about 4-5 minutes seems to confuse the the RB software. When playback resumes, following the seek, it continues from the point where the seek started (as if the seek hadn't happened). The "Current Time in Song", "Remaining Time in Song" and progress bar are updated on the WPS during the seek, and continue to update following the resume.

If the track is allowed to continue playing, the "Current Time in Song" continues to increment past the "Total Track Time", at which point the "Remaining Time in Song" goes negative and continues to decrement. The progress bar stops at the right hand limit, but the track continues to play to the end.

So far I've only seen this with 128 Kbps WMA files longer than ~4 minutes. It doesn't seem to happen with MP3s or shorter WMA files.

I'm using today's current build on a Sansa E260.

[Llorean]

Just as an FYI, "today's current build" doesn't mean much. Usually there are several current builds made each day, and as we don't know what time zone you're in, we just know that "it came from sometime in the 24 hour period before this post."

When reporting anything, you should always include the actual revision number.

[saratoga]

Theres an overflow in the seeking code that kicks in at ~4.2MB IIRC.  I just haven't gotten around to fixing it.

[OldSchool]

It's version r15996-080104 - I'll do it right next time . Thanks for the information.

[saratoga]

I take that back, I fixed that issue a couple weeks ago.  I just tried a 30 minute seek with a 64 kbps file and it worked.  This is probably something else.

If the track is allowed to continue playing, the "Current Time in Song" continues to increment past the "Total Track Time", at which point the "Remaining Time in Song" goes negative and continues to decrement. The progress bar stops at the right hand limit, but the track continues to play to the end.

This means the parser encountered an error in the file and gave up trying to seek.  I'll fix it now so that it doesn't screw up the progress bar when this happens, but I'm not sure I can make your file seekable.  Does it happen every time single time you try and seek?  Even if you try to seek after having listened to half the file first?

[OldSchool]

It seems to depend mainly on the file length; anything more than 4 or 5 minutes long will cause trouble, but only with WMA files. It doesn't seem to matter how much of the file is played in real time before the seek.

These files were ripped from my CD collection, using either EAC or Audio Converter (E-soft), and are encoded at 128 Kbps. For shorter WMA files (< about 4 minutes), created using the same software, the seek works fine.

I'll try some different encoding rates. Please let me know if there's anything else I can do or try.

 

[ilikedirt]

Hi. I encountered the same problem. All my WMA files don't seek beyond ~3 Minutes (bitrate is 192kbps). Build r16060.

[ilikedirt]

I went through the recent daily builds to find out when the bug was introduced. The bug doesn't happen in builds up to Januar 5th r15998 but appears in r16002. I guess it has to do with this commit "If seek fails, don't insert nonsense for the current position. Also, make one of the error messages a bit more clear."

Beyond which time seeking fails also seems to be dependent on the overall lenght of the file. I can't seek beyond ~3minutes in a 5 minutes long files, but can seek up to ~5  minutes in a 10 minutes long file (and so on, e.g. 4 minutes in a 7 minutes long file).

r15998 Shows something else though... The time seems to be miscalculated on my files as the songs don't end when the seekbar is full, they rather play on above the calculated time (foobar2000 shows length of 5:44 for one of my songs, rockbox shows the same length but plays up to 9 minutes)

OldSchool reported something for r15996 so this might be something else... In build r15998 I can seek to what seems to be the end of a 10 minutes long WMA file but then is not as rockbox plays over the "end" of the file.

[saratoga]

I went through the recent daily builds to find out when the bug was introduced. The bug doesn't happen in builds up to Januar 5th r15998 but appears in r16002. I guess it has to do with this commit "If seek fails, don't insert nonsense for the current position. Also, make one of the error messages a bit more clear."

That commit makes rockbox tell you if the seek fails rather then pretending they worked while still playing from the original location.  Before then it would simply update the screen but not actually seek.  Did you confirm that you can actually seek before that commit?  If its playing past the end of the file, then it sounds like it did not manage to seek.

[ilikedirt]

No, you're right. It just looks as if it seeked to the end of the file, but then I'm somewhere in the middle of the file and then it looks as if it played past the end.