In every comparison I have seen flac decodes faster than wavpack on the pc, yet on a coldfire cpu using rockbox wavpack seems to decode much faster. Is this due to better optimized wavpack code or does using the integer libraries hurt flac decoding speed more than I would have anticipated?

Anywho, I was just curious. Thanks in advance for any explanations.

Really?
http://www.foobar2000.net/lossless/decoding.htm
But difference is very marginal, and both are near identical.

I know that David Bryant worked to optimize WavPack for Rockbox (or is it ARM processor?), and it might explain the difference you've mentionned.

WavPack provides a little better compression (especially in extra mode, although this causes a massive increase in encode time), but for simple playback decode speed shouldn't be an issue.

And keep in mind WavPack is NOT yet assembly-optimized for the x86 platform. FLAC is. With ASM, even WavPack normal might decode faster than FLAC.



It indeed explains the difference. That also explains why WavPack is the only lossy or lossless codec currently also encoding in the RockBox.

BTW: The iHP CPU is a Motorola/Freescale ColdFire, based on the venerable M68k architecture.

Hadn't seen that test. All the ones I had seen were also done using wavpack 4.0. Man, when David claimed faster encode/decode speeds for 4.2 he really meant it.

ive recently transcoded many single file flacs/cues that were encoded at various levels to wavpack multiple files and almost all the wavpack albums are smaller using -mx (m = calculate md5, x = extra encode process 0.5% better compresionish) x makes encoding very slow but slightly smaller file with no additional decode time. good for h1xx.

i do not recommend high compression -h on the h1xx as i have experienced some problems on playback (sometimes)

imo wavpack is more responsive than flac on the h1xx, i cant see an advantage of using flac on a H1xx as wavpack just does it all better. tos me

flac however is excellet and my 2nd choice

I'd take those results with a grain of salt. It indicates that using the -x4 command increases decode time, when both the WavPack documentation and my own testing indicates this is not the case. In fact, on every sample I have tested using the -x6 argument actually decreases decode time by as much as 15%.

Keep in mind that those results are indicating decode speed, not decode time, so they actually do match what you see.

I don't think I understand you. Is not decode speed over the entire track directly proportional to the decode time?

Eg:
If sample A decodes at 1400 samples per second, and takes time x, assuming sample B decodes at 1300 samples per second time x should be less than time y.

No, it's inversely proportional. When one goes up the other goes down.

Ah yes, my mistake. But there is still a relationship between them, agreed? Is it not odd that two values stay the same (decode time) while the other two differ (decode speed)?

Now I'm not sure what you are refering to. I just meant that the results that Guruboolez was showing actually did match what you saw (that -x4 makes decoding faster). It seemed like you thought his results showed that -x4 decoded slower, but they don't.

I just rechecked the results and realised I'd read them wrong.
Carry on.