- Status Closed
- Percent Complete
- Task Type Bugs
- Category Battery/Charging
- Assigned To No-one
- Operating System SW-codec
- Severity Low
- Priority Very Low
- Reported Version Release 3.12
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#12826 - Mini-sound burp between track skips with WMA
On both the Clip+ and the Fuze V2 playing WMA VBR 50 to 95Kbps encoded files, I get a short sound-blip between tracks when skipping forward or backward. (Incidentally, that’s the only endoding I use, so not sure whether it’s encoding related or not.) Sounds like leftovers in buffer or somesuch? Been hoping it would disappear with new revs, but still have it in Release 3.12. I’m new here, so hope this report’s OK, and didn’t see any similar tasks.
Edit by MikeS: Should apply to all SWCODEC targets
Closed by MikeS
2013-02-18 20:56
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
2013-02-18 20:56
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Reporter reports that it's fixed.
66acb39
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
As far as I know I fixed this last year in bc41926. If you have a sample where it still happens, post a link.
Not sure what you mean by a link to a sample. I haven’t come across any of my CD albums ripped with this encoding in both my Clip+ and Fuze V2, with both running Release 3.12, which don’t exhibit this problem. (I don’t download any music, so can’t steer you to a link, if that’s what you meant.) Both units do have plug-in SD cards, one a 16 and the other a 32GB, but am pretty sure that I’d experienced same problem when music files were installed within internal memory on both units. Could recheck if it would help. I suppose could upload a few songs or an album to you if you know where I can put them.
I mean a sample of a file that causes this problem.
Seems you didn’t read all my previous comment? All my music is locally ripped, so no link available, I could send you a couple of tracks, which, when skipping forward or backward will exhibit the problem. In fact, as I stated previously, I haven’t found any of my several-gig music collection which DON’T exhibit the problem. You’ll need to let me know where I can upload a couple of them.
I’ll verify that WMA has this problem on any device whatsoever. The filters/buffers are not reset between tracks when skipping/seeking. I still currently experience it. I’ve never encoded WMA myself but I could provide files that I’ve acquired here and there.
Which buffers do you mean? I reset the mdct overlap buffers on seek. Off hand I can’t think of anything else to reset. Testing with my files I can’t generate any glitches seeking either.
There’s a blip of the previously decoding track upon resuming after skipping tracks. Seeking seems alright now.
ETA: Build on player I just grabbed to check is a6409c8-121219, so I think that’s recent enough.
I noticed that wma.c is written to clear these buffers on seek but NOT on a forced stop (CODEC_ACTION_HALT), which is what it gets when doing a manual skip.
Made a patch to take care of fault when skipping manually:
http://gerrit.rockbox.org/406
I’m not familiar with the codec actions, but the basic idea seems sound. If it solves your problem, commit.
It solves my problem. Does it solve reporter’s problem? Likely but I’ll wait just a few moments.
Key FYI:
CODEC_ACTION_NULL = default, keep decoding normally
CODEC_ACTION_SEEK_TIME = seek to the time returned in the paramter
CODEC_ACTION_HALT = return from decoding now
(no others at this time)
66acb39
Pushed it. Will leave this open for comment.
Sorry, Michael(s), I don’t know how to apply to try the patch. Suspect it will wind up in future release anyway, or can you steer me how to try the patch?
It’s in the current build. No patch required.
Not knowing quite how to install the current build, downloaded them for both the Clip + and for the Fuze v2, and took the .rockbox\codecs folder from each and copied them to appropriate devices’ .rockbox directory, overwriting old codec folders in each. Both are fixed! Thanks so much, Michael(s)!