Tremor issues. Options

[HbG]

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?

[john33]

http://www.rarewares.org/files/ogg/oggdecT.zip

[HbG]

Thanks for the link.

Seems the issue is with the PocketPC, tremor decoded files seem to sound fine on my PC even with no dithering. Are there perhaps older versions of Tremor that behave differently?

[john33]

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!!

[HbG]

Even if it doesn't answer my question, it still makes tremor being bugged on my PocketPC entirely plausible even if it's fine on my PC i guess.

Also explains why Vorbis is relatively hard to find on hardware players, shame really as such a thing would be an important factor in ensuring your codec's success and broad acceptation...

[aspifox]

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...

[HbG]

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?

Edit: That's for a Q5 file encoded at 161Kbps.

This post has been edited by HbG: May 6 2005, 22:23

[picard]

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...

[HbG]

It'd be nice if it were possible to use normal precision when playing audio only even if it sacrifices some battery life. Does anyone know the developers?

EDIT: Nevermind

This post has been edited by HbG: May 23 2005, 13:17

[rt87]

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...

You missed a good player for PocketPC
It is GSPlayer. It supports mp3/ogg and plugins.
http://hp.vector.co.jp/authors/VA032810/

[picard]

You missed a good player for PocketPC

I was just stating which players use low-precision for sure.
Btw there is another good open-source audio player for PocketPC called MortPlayer...

[system_saboteur_...]

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 .

Could someone please send me this patch?

Thanks in advance

[cruzlee]

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.

see this thread to understand what I mean.
http://www.cowonamerica.com/forums/showthread.php?t=13253

[Mike Giacomelli]

It would be odd for them to use low precision given how ridiculously fast Tremor would be on the Iaudio 7's CPU.

[Yirkha]

Unfortunately, Tremor in latest iAUDIO 7 firmware is indeed compiled with _LOW_ACCURACY_.

[sprockkets]

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.

[Yirkha]

By actually seeing the co... uhm, nobody can have their code, of course.

See Tremor source code, floor1.c - there is a nice lookup table with values like

CODE

XdB(0x69f80e9a), XdB(0x70dafda8), XdB(0x78307d76), XdB(0x7fffffff),

where

CODE

#ifdef _LOW_ACCURACY_
#  define XdB(n) ((((n)>>8)+1)>>1)
#else
#  define XdB(n) (n)
#endif

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.)

[Rotareneg]

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.

This post has been edited by Rotareneg: Aug 15 2008, 21:53

[sprockkets]

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?

This post has been edited by sprockkets: Aug 20 2008, 03:55

[sprockkets]

Well, I tried, but of course the firmware is signed or has a checksum to it and my U3 rejects it. Got an idea for this?

This post has been edited by sprockkets: Aug 20 2008, 02:46

[Mike Giacomelli]

Well, I tried, but of course the firmware is signed or has a checksum to it and my U3 rejects it. Got an idea for this?

This guy figured out a way:

http://forums.rockbox.org/index.php?topic=...31268#msg131268

However, since the LOW_ACCURACY define changes how fixed point multiplies in Tremor work, you'd need to change dozens, if not hundreds of inlined calls to it's MULT* functions.

[sprockkets]

Ok, so explain to me what it means to ((((n)>>8)+1)>>1) the hex values so I can do more searching.

[Mike Giacomelli]

Ok, so explain to me what it means to ((((n)>>8)+1)>>1) the hex values so I can do more searching.

That divides an interger by 512, rounding to the nearest whole number.

[Yirkha]

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.)

[sprockkets]

I see. And just by changing the value did not work anyhow.

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.

This post has been edited by sprockkets: Aug 20 2008, 06:43