FS#8389 - wv error

Attached to Project: Rockbox
Opened by gamering (gamering) - Sunday, 30 December 2007, 14:56 GMT
Last edited by Thom Johansen (preglow) - Wednesday, 02 April 2008, 21:11 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System iAudio X5
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I have this message when i try to play an *.wv file: Div X0 AT31F00356, with my iaudio x5
Thanks in advance
This task depends upon

Closed by  Thom Johansen (preglow)
Wednesday, 02 April 2008, 21:11 GMT
Reason for closing:  Fixed
Comment by Thom Johansen (preglow) - Wednesday, 13 February 2008, 14:39 GMT
Does this still happen? Does it happen every time you try to play the same file? If so, posting a file that makes it happen consistently would be most helpful.
Comment by gamering (gamering) - Thursday, 14 February 2008, 16:19 GMT
Yes this still happens with every *.wv file.
I update regularly rockbox
Comment by Thom Johansen (preglow) - Thursday, 14 February 2008, 18:24 GMT
Could you test this file on your unit: I have had an X5 owner test it, and it works fine. If this file does not work on your unit, you probably have a faulty Rockbox install. If it works fine, could you submit another Wavpack file (preferably a small one, of course) that crashes on your unit so we can investigate it?
Comment by Thom Johansen (preglow) - Friday, 29 February 2008, 17:49 GMT
I have heard of no other X5 owners complaining about Wavpack files not working. If you do not reply with any new info soon, I'll assume this is due to user error and close the task.
Comment by gamering (gamering) - Saturday, 01 March 2008, 23:58 GMT
The file that you gave me works perfectly. It's for me very difficult to upload a little file so you can understand my problem. Probably it's only a configuration problem
Thanks for your answers.
Comment by Thom Johansen (preglow) - Tuesday, 11 March 2008, 15:00 GMT
I seriously doubt it's a configuration problem. It would be most illuminating to have a copy of one of these files that do not work to figure out why we crash. If you can't upload one, please send one (as small as possible) to
Comment by gamering (gamering) - Wednesday, 12 March 2008, 18:33 GMT
I posted you a file. I hope he isn't to big
Comment by Thom Johansen (preglow) - Thursday, 13 March 2008, 12:05 GMT
This file also crashes for me. Will investigate.
Comment by David Bryant (bryant) - Sunday, 30 March 2008, 19:50 GMT
This file has the length missing from the header of the first block. The standard WavPack decoder seeks out to the end of the file in this case to determine the exact length, but that is a little more difficult in this implementation because it must be handled outside the WavPack decoder (in the metadata handling functions).

As an interim fix I have checked in code (SVN 16893) that allows these files to be played by making a high-side guess at the length based on the file size and the mode. This works pretty well (the files even play gapless) but the progress bar is off and seeking is a little weird (but usable).

I would be interested in how exactly these file were generated because I can't imagine a situation where the command-line encoder would do this. The most common source is a 3rd party application that fails to seek back to the beginning of the file and rewrite the header once the actual length is known, or the case of a real time recording being interrupted.

Thanks for letting me know about this problem.
Comment by Thom Johansen (preglow) - Monday, 31 March 2008, 09:09 GMT
Would you say this warrants closing this bug?
Comment by gamering (gamering) - Monday, 31 March 2008, 16:12 GMT
If i remember well,but i amn't shure, this file like other was generated by splitting by cue splitter.
How do you determine this error? Please if do you have any time post me a breaf explanation.
Close this post and thanks for your kind and patient competence.