Rockbox

I don't notice anything wrong in r30740 SIM. See if you can still reproduce the bug in the current build.

Yes, it's definitely still present in build r31036 but I'd say it seems less severe than in 3.9.1. Could be my ears playing tricks on me, though. During your testing was the codec correctly identified as Musepack by Rockbox? It remains "Unknown" in the current build.

I've attached a vorbis sample (encoded from the same source PCM file) for comparison with the sv8.mpc upload, and 2 "short" samples of the section where the distortion is most noticeable (the ~20'' mark in the original upload).

Meanwhile, I think I've identified another bug in X5, whenever I call the quickscreen the player crashes. Shall I file another bug report or is there any reason to believe this might due to a hardware/configuration fault on my side?

The %fc tag works fine for my nano 2G sim (r31031). Do you use a WPS with predefined bmp's for the codecs? Such WPS will need an update as there were relevant changes made to metadata.h.

As you report the distortions with your X5 only I kindly ask you to make the following tests:
1) Decode short.mpc file to wav with the test_codec plugin on your X5 (You will need to build this by your own, if you cannot do this give the precise revision of your build and I can provide the plugin.). Then test if the resulting wav file sounds fine. If the distortions are still audible go to step 2.
2) Do the same on your Clip+. Then copy both decoded wav files to your PC and compare them, or upload both wav files to a fileshare place and place links here.

Here are my custom wps, the X5 one worked fine with build 28437. The Clip+ I don't know about since I never tried anything other than 3.9.1 on it. I'm in a hurry right now so I can't experiment more, but the LightDT wps reports "MPCv8" correctly: http://themes.rockbox.org/index.php?target=sansaclipplus

I don't know how to build the test_codec plugin as I've never compiled anything, I suppose I'll have to read this first: http://www.rockbox.org/wiki/HowToCompile

I'd appreciate if you could supply the plugins for both my Clip+ (rel 3.9.1) and X5 (r31036-111120) because otherwise it might take a few days until I figure out the process.

Your custom WPS is out of date. You'll need to update it to show the correct format. Why don't you simply use "%fc" instead of the long command line in your custom WPS (I suggest you might ask some of the GUI guys about support in the forums if you want to display some speciality...)?

Clip+ build (r31040 + test plugins): http://www.sendspace.com/file/20ay30
X5V build (r31040 + test plugins): http://www.sendspace.com/file/qgwyz8 (this is my first Coldfire build, I cross fingers it works as it should)

Edit: Btw, is this bug reproducible in v3.8 as well?

I'm sorry if I'm being dense but I don't know how to use the test_codec plugin... I thought I had to do as instructed here: http://www.rockbox.org/wiki/CodecPerformanceComparison#Method but there's no test_codec option in my "Open with..." menu. What am I missing?

I tried 3.8 and 3.9 and the distortion was already present in those releases. I think it is easier to spot using headphones, if anyone has an X5 please compare the first 2 seconds of the left channel of short.mpc against short.flac; in the simulator both files sound identical to me.

BTW, the X5 quickscreen freeze does not happen with any of the release versions (3.8, 3.9, 3.9.1), only with the later builds (r31036 and r31040).

Yes, test_codec is used via "Open with..." on your mpc file. It was my fault, I did not compile the test plugins...

Now with test plugins:
clipplus -> http://www.sendspace.com/file/movvam
x5 -> http://www.sendspace.com/file/onjm51

If the distortion occurs in 3.8 as well, there are only a few relevant changes.5 of them only impact ARM target, 3 of them impact all targets but do not seem to change anything which might result in distortion (r28561, r28563, r28627) -- especially nothing that might be limited to Coldfire architecture. Are you sure this distortion is not happening when playing the file with v3.7?

Thanks for the new builds. I didn't test 3.7, only 3.8 (what you requested) and beyond. Once again I need to go to work now but later today I will test all releases back until r28437 which is the last working build I know of.

Regarding the quicksreen freeze, that one IS reproducible on a sim. Like I said it doesn't happen in 3.9 or 3.9.1, but if you the download daily sim (at the time of writing r31036) and hold the REC button to call the quickscreen, you'll notice that only the L/R options are displayed, the top and bottom (by default "Show Files") are not. In real hardware, this freezes the X5V, but in the sim it doesn't. Do you want me to submit a new bug report for this separate issue?

Yes, please add a seperate bug report for the quickscreen freeze.

There you go, files have different audio data and are very, very easy to ABX.

mpc playback in 3.7.1 seems fine, 3.7 was from before  FS#1170  so it is broken for other reasons.

Wow, there definately are quite some differences. The X5-file seems to miss (or downscale the amplitude of) the 2nd or 3rd subband at several time positions. At those time position the signal is broken and overflows...

I have build a set of mpc.codec files (just replace them in your .rockbox/codecs folder). Please test each them and report which is the last proper working version.

None of them work, .mpc files are ignored. When using 3.7.1 as base "Codec failure" flashes on the screen regardless of what mpc.codec is present; using 3.9.1 the only difference is that the failure message isn't displayed. 28563, 28626 and 28627 are all the same binary, so I tested only 1 of those 3.

Abel, it would be great if you could join irc in the evening. This will bring down the turnaround times for test builds and test runs.

All codecs should only work against svn (r31045) or the X5 build I have linked in one of my former comments. They won't work against 3.7.x or 3.9.x.

I have recompiled the codecs in question and removed identical ones (there was one change only relevant for ARM): http://www.sendspace.com/file/e6vjoy

Distortion is present in all 4 codec versions.

If I compile r28437 in the current build environment it is identical to one build with r28560.

I have recompiled r28437 with the current build environment: http://www.sendspace.com/file/ba6xy4

Distortion confirmed with current build environment.

r28437 original build with old GCC -> works
r28437 built with GCC -> does not work

r31045 compiled with old GCC: http://www.sendspace.com/file/dsirje

r31045 built with old GCC works.

I managed to recompile r25056 with the new GCC. This is the first version with the new musepack sv8 decoder. I only needed to change some IRAM configuration for MPC which will slow down decoding but should impact the output itself. Can you please crosscheck if this version works for you?

http://www.sendspace.com/file/mq2cjr

New GCC r26013: http://www.sendspace.com/file/bx1pi9

New GCC r25056 - doesn't work.

New GCC r26013 - works.

Root cause is r26592 which causes the distortion when using GCC4.5.2

r26591 with new GCC - works
r26591 with new GCC -doesn't work

The attached patch fixes the issue.

Confirmed working with r31053.