• Status Unconfirmed
  • Percent Complete
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by andrewbeveridge - 2008-07-19
Last edited by saratoga - 2008-07-28

FS#9205 - WMA Decoder - Problematic Files (Gaps/Skipping) - Example included

Hello World :)
Attached is a VBR WMA music file, which fails to play correctly on my “RockPod” iPod Nano.
The same file decodes perfectly using the latest ffmpeg build.
Therefore I can only assume there is something about this file which triggers a bug in the Rockbox-specific WMA decoder.
Also attached is a microphone recording of the sound which comes out of my iPod when Rockbox attempts to play the faulty WMA.

I have over 3000 WMA tracks, all encoded using an identical method, all of which will not play correctly in rock box, so if you would like any more examples, or information, please ask.

Thanks for all your help :)
(If there is any way I can help debug/update the code for the wma decoder, please let me know where to start, I understand the C source code pretty well)


Hey, I don’t know if this helps much, but it seems pretty significant to me.
I don’t know if you remember, but I mentioned VLC having exactly the same problem as rockbox on my “faulty” files?
Anyway, I finally got somewhere on the VLC IRC channel, and it seems the version of VLC I was using was quite old, using FFmpeg build r12920.
I updated to the latest nightly build of VLC (FFmpeg build r14080) and all files played perfectly! :)

So. What does this mean for rockbox? I could attempt to narrow it down to a specific FFmpeg build which fixes playback of my files, but it would seem more sensible to just update Rockbox’s SoundCodecWMA with the latest FFmpeg anyway.

Is there any way I can help more?

Thanks all, Andrew

Hmmm. I’m sure I already ruled this out with saratoga on IRC, but my narrowing down has led to one conclusion - this FFmpeg revision change:

I was certain you said the build used with Rockbox was a later build than that, but I can’t find any way to explain it otherwise.
Using the command ‘ffmpeg -i test.wma test.wav’ with each of the FFmpeg revisions which showed a change in ‘wmadec.c’ seemed to show conclusively that after FFmpeg r11115, my “faulty” file is decoded correctly. Before that the output is as before mentioned, but not quite as severe as when decoded by rockbox on my iPod nano.

I’m really lost for what to do next - you said yourself that there isn’t much anyone can do unless the source/cause of the problem is figured out, and I’ve kinda hit a brick wall.

I did not commit that change, though testing it in Rockbox and in my test driver does not fix the problem with your sample. However, your problem sample reports differing sizes for “buf_size” and “block_align”, while your working version of the same file (and all my test files) do not, so this is probably related to whatever the underlying problem is.


Looking at the code, block_align is set by the ASF metadata parser based on the file header. buf_size is set for each packet based on the value read in asf_read_packet, where it is the sum of all the payload lengths. Any idea what it means when they’re not equal, or why this would be a problem? Or why simply setting them to be equal fixes the problem for ffmpeg but has no effect for us? The artifacts sound like multiple blocks being lost, probably a superframe or asf packet worth.

Not sure which bug report to attach this to (9205, 9536, 9776, 10027) as they seem similar to me.

I have more examples of WMA problems described above, all of the book chapters listed on this page stutter and pop:

Thanks for all your work!


Available keyboard shortcuts


Task Details

Task Editing