I first noticed this some 2 years ago. I've got a HP Jornada 568 PocketPC with a 256MB CF card which i use as MP3/OGG/MPC player, i know this is hardly the best way to listen to music, but it's better to use the hardware i have than shell out for something new.

The problem is, i hear noticeable artifacts when playing OGG's with certain types of music, most notably continous low tones. A good example where this happens is the start of Radiohead - Lucky. It sounds like there is some weird higher harmonic in it, i can't really describe it, but it's very audible to me.

Mac explained to me this is what you can hear when you reduce bit depth without dithering. Since PocketPC's as far as i'm aware don't have any floating point units and therefore can't use the normal Vorbis decoder, it would appear this is a bug in Tremor. I've tried two different programs to play OGG's on the PocketPC, PocketDiVX (later renamed to PocketMVP) and BetaPlayer, it makes no difference.

Because the issue might also be something other than Tremor and i can't decode to a wav file on my PocketPC, i have no way of verifying this and putting some samples online for everone to listen to. Is there a Tremor compile for windows i can use to confirm this?

I think I'm right in saying that there has never been a formal release of Tremor. The library code was, IIRC, intended to be little more than a 'starting point' for the creation of environment specific implementations. I seem to recall having to tweak it slightly to get it to fly in the win32 environment; an environment that is hardly its intended target!!

I believe there have been few, if any, changes to the reference libs since initial availability.

None of this really answers your questions, but sets a little background, hopefully!!

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

I think I'm right in saying that there has never been a formal release of Tremor. The library code was, IIRC, intended to be little more than a 'starting point' for the creation of environment specific implementations. I seem to recall having to tweak it slightly to get it to fly in the win32 environment; an environment that is hardly its intended target!!

I believe there have been few, if any, changes to the reference libs since initial availability.

None of this really answers your questions, but sets a little background, hopefully!!

If anything, Tremor has seen quite a lot more development than the 'standard' Vorbis decoding code, including IIRC the first implementation of a libogg2-style demuxer with zero-copy. The development, however, has mostly been tucked away on a side-branch of CVS, and, as you say, doesn't see formal releases.

As a side-point to the side-point, Tremor is actually very easy to build almost anywhere; I'm shipping win32 and Linux/x86 software using Tremor as the preferred decoder, for footprint reasons. Back on topic somewhat, Tremor in low-precision mode often demonstrates an unpleasant sort of mechanical buzzing edge to the output, but normal-precision Tremor was 'good enough' for me. I hope no-one is shipping player products using low-precision Tremor mode, but...

Low precision mode you say.. that might be it. A quick benchmark on my 206Mhz StrongARM PocketPC gives a maximum playback rate of ~450%, and this is with the actual sound playing like an overspeeding tape recorder, so it's spending some CPU cycles on resampling as well. Could these sort of speeds indicate low precision mode being used?

I hope no-one is shipping player products using low-precision Tremor mode, but...

Both PocketMVP and BetaPlayer uses low-precision mode Using EVC (no ARM inlines) the none low-precition mode is much slower and these two player are mainly focus on video playback so speed does make a big difference. Later I will try to use GCC for tremor compiling...

I hope no-one is shipping player products using low-precision Tremor mode, but...

Both PocketMVP and BetaPlayer uses low-precision mode Using EVC (no ARM inlines) the none low-precition mode is much slower and these two player are mainly focus on video playback so speed does make a big difference. Later I will try to use GCC for tremor compiling...

Hi all,I'm searching for a new algorithm for mdct_backward function of Tremor lowmem and I found that Johannes Sandvall, Erik Montnemery implemented it before (http://lists.xiph.org/pipermail/tremor/2003-November/000905.html). The lowmem tremor with a new mdct backward function was available. I goto the link: http://www.sandvall.nu/patch but this link was dead .

I hope no-one is shipping player products using low-precision Tremor mode, but...

Well, too bad someone still does. I bought a Cowon iAudio 7 today and most of my Vorbis files sound horrible. According to some other people with the same problem it is because of the low precision tremor.

Is by inferring or by actually seeing the code? At least they fixed the issue on the D2. But in my opinion this is unacceptable. My ancient Samsung YP-MT6, a measly 512MB player, does not have this issue.

Search I7_FW.BIN from latest firmware update for plain 0x69F80E9A => "9A 0E F8 69" - nothing.Search for ((0x69f80e9a >> 8) + 1) >> 1) => 0x0034FC07 => "07 FC 34 00" - you end up in this table, it's at the very end of the file.

I don't know what the issue with iAUDIO D2 was and how it was solved, but at least the situation with I7 is a bit complicated by the fact that COWON is using only a highly-customized version of Telechips's SDK provided with the main chip, and Telechips distribute Vorbis decoder as a precompiled library. I'm not sure if it's caused by some kind of one-time licencing policy or large amount of customizations by COWON, but they aren't even using the latest SDK. Combined with short commercial lifetime such products, I wouldn't expect them to address this. (It's on my TODO list immediately behind gapless playback, though.)

I'm not sure iAudio themselves even touch that part of the firmware, I suspect they just use what the chipsets manufacturer puts out and adds their "OS" onto it. At least, that's what my impression was when reading up on the Rockbox / D2 porting stuff.

Whoops, Yirkha posted basically the same thing while I was typing that.

I see. The D2, U3, and 7 use the same ARM946-ES core, with the D2 also using an ARM926EJS core most likely for video. If they all use the same core for audio playback, all should be just as easily fixed.

Here's to looking to Aug 29 when Cowon at IFA in Berlin reveals perhaps new stuff.

I did some checking, and found the D2 firmware has the right hex values you mentioned, while the U3 has like you said, the low precision values. When I checked the oldest firmware, 2.20 for the D2, it had the low precision hex value.

Wait, if I were to take the firmware, change the hex code to the non low accuracy value, would that fix the issue?

As have been already stated by others, it's not about the one value I randomly chose for easy demonstration.Although the biggest problem IMHO aren't the inline calls (one SMULL should be shorter than some fixed-point shifting), but rather overall decoder size. In a normal-precision build, there are ~40 kB of various look-up tables, one 32-bit word per value. In a low-precision version, these are stripped down to one quarter of the size by using only 8-bit values. Good luck searching for such space in the firmware...(No, it's not possible to just append it to the end, the firmware is copied from flash to SDRAM at runtime and code/data/bss segments are laid one after another with no space, so one would have to rebase everything. I'll just cut off all the silly JANUS DRM and MTP stuff, probably.)

In other words, after being compiled with the different options, a lot of different pieces of code get changed. Or, more likely as you all say, they took the tremor code, edited what they needed, and then compiled it with --low-precision. Well, this problem pisses me off so much that I want to do whatever to change it.

Out of curiosity, Yirkha, are you doing work on rockbox for Cowon's flash players? Or doing the work on Cowon's own firmware?

Or, what other forums are you posting on? Due to the nature of this issue, I've been scouring the iaudiophile, anythingbutipod, and cowonamerica forums.