FS#12826 - Mini-sound burp between track skips with WMA

Attached to Project: Rockbox
Opened by David Miessler (DGM) - Thursday, 14 February 2013, 17:10 GMT
Last edited by Michael Sevakis (MikeS) - Monday, 18 February 2013, 20:56 GMT
Task Type Bugs
Category Battery/Charging
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Release 3.12
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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
This task depends upon

Closed by  Michael Sevakis (MikeS)
Monday, 18 February 2013, 20:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  Reporter reports that it's fixed. 66acb39
Comment by MichaelGiacomelli (saratoga) - Thursday, 14 February 2013, 20:55 GMT
As far as I know I fixed this last year in bc41926. If you have a sample where it still happens, post a link.
Comment by David Miessler (DGM) - Friday, 15 February 2013, 15:00 GMT
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.
Comment by MichaelGiacomelli (saratoga) - Friday, 15 February 2013, 17:30 GMT
I mean a sample of a file that causes this problem.
Comment by David Miessler (DGM) - Friday, 15 February 2013, 23:15 GMT
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.
Comment by Michael Sevakis (MikeS) - Saturday, 16 February 2013, 03:19 GMT
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.
Comment by MichaelGiacomelli (saratoga) - Saturday, 16 February 2013, 19:20 GMT
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.
Comment by Michael Sevakis (MikeS) - Saturday, 16 February 2013, 19:34 GMT
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.
Comment by Michael Sevakis (MikeS) - Saturday, 16 February 2013, 19:52 GMT
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.
Comment by Michael Sevakis (MikeS) - Sunday, 17 February 2013, 21:35 GMT
Made a patch to take care of fault when skipping manually:
Comment by MichaelGiacomelli (saratoga) - Sunday, 17 February 2013, 21:39 GMT
I'm not familiar with the codec actions, but the basic idea seems sound. If it solves your problem, commit.
Comment by Michael Sevakis (MikeS) - Sunday, 17 February 2013, 21:50 GMT
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)
Comment by Michael Sevakis (MikeS) - Monday, 18 February 2013, 01:45 GMT

Pushed it. Will leave this open for comment.
Comment by David Miessler (DGM) - Monday, 18 February 2013, 14:36 GMT
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?
Comment by MichaelGiacomelli (saratoga) - Monday, 18 February 2013, 14:44 GMT
It's in the current build. No patch required.
Comment by David Miessler (DGM) - Monday, 18 February 2013, 15:41 GMT
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)!