- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category Music playback
- Assigned To No-one
- Operating System Sansa AMSv2
- Severity Low
- Priority Very Low
- Reported Version Release 3.11
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#12678 - Unable to play WMA Pro (possibly VBR)
The player (Sansa Clip Zip) appears to refuse or unable to play some of my WMA tracks; as far as I can tell, the problem is specific to my WMA Pro files only as it plays none of them (but works with WMA2 successfully). I have attached one of the examples.
I understand that a similar issue was reported recently (in FS#12619 ) although, in my case, the player doesn’t start playing and skips to the next immediately, rather than playing part of the track.
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
For some reason, my attempts to attach a 1.5mb file (1,464,457 bytes) are unsuccessful. Trying again.
As far as I can tell the ASF parser doesn’t understand that file’s bitstream. I’m not sure how to fix it, I don’t understand the ASF file format very well.
Other users have made a point of referring to VLC… so, VLC plays these files on the Mac without any problem.
Also, I have two types of WMAP-encoded files, one which it plays (or, at least, starts playing) and the other doesn’t. According to VLC, the difference between the two is the latter (which doesn’t play) has 16 bits per sample and bitrate of 192kb/s, and the good one is 24 bits and 256 kb/s, respectively.
Strictly speaking, transform codecs like WMA/AAC/MP3 do not have any number of bits per sample (since they do not store audio as time domain samples), so that field is probably just a random place holder value.
The problem here is that our ASF parser isn’t very good, and it only supports some of the ASF features. If you have a file that uses some feature it doesn’t support, you won’t be able to play it. MS makes a tool called “ASF View” on Windows that can show you some of the structure of a given ASF file, but its not too much use unless you want to dig into how our code works and figure out whats missing that ffmpeg/VLC have.
No I’m wrong. I had logging in one file disabled so I misinterpreted the error. The actual problem is that quantization steps in the decoder appear to be much too small. Removing the out of bounds check, I get very nearly silent (but just audible) music.
I suspect its probably this issue:
https://roundup.libav.org/issue2536
I fixed that issue and it didn’t fix the file. For whatever reason the decoded quantization values are much too low. I’m not sure why and don’t have time to dive into the ffmpeg decoder right now and figure out where we mess up.
Edit: actually it looks like the quatization values are fine and that the rest of the data is scaled wrong somehow. Not really sure whats going on here.
I am guessing simply bringing wmaprodec/wmaprodata files in sync with what’s in ffmpeg repo will not help, since it hasn’t been done… Since more than half my collection is not playable by Rockbox, I wish I could help – but I don’t know anything about your codebase nor how to debug problems (on the mac). [By the way, the player works with wmapro files for which it reports bitrate of 128 or 256, but not 96 or 192.]