Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Tremor issues. (Read 40998 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Tremor issues.

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?
Veni Vidi Vorbis.


Tremor issues.

Reply #2
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?
Veni Vidi Vorbis.

Tremor issues.

Reply #3
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!!

Tremor issues.

Reply #4
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...
Veni Vidi Vorbis.

Tremor issues.

Reply #5
Quote
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!!
[a href="index.php?act=findpost&pid=295649"][{POST_SNAPBACK}][/a]


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

Tremor issues.

Reply #6
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.
Veni Vidi Vorbis.

Tremor issues.

Reply #7
Quote
I hope no-one is shipping player products using low-precision Tremor mode, but...
[a href="index.php?act=findpost&pid=295676"][{POST_SNAPBACK}][/a]

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

Tremor issues.

Reply #8
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
Veni Vidi Vorbis.

Tremor issues.

Reply #9
Quote
Quote
I hope no-one is shipping player products using low-precision Tremor mode, but...
[{POST_SNAPBACK}][/a]

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...
[a href="index.php?act=findpost&pid=299664"][{POST_SNAPBACK}][/a]

You missed a good player for PocketPC 
It is GSPlayer. It supports mp3/ogg and plugins.
[a href="http://hp.vector.co.jp/authors/VA032810/]http://hp.vector.co.jp/authors/VA032810/[/url]
Sorry for my English.

Tremor issues.

Reply #10
Quote
You missed a good player for PocketPC 
[a href="index.php?act=findpost&pid=299865"][{POST_SNAPBACK}][/a]

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

Tremor issues.

Reply #11
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 

Tremor issues.

Reply #12
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

Tremor issues.

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

Tremor issues.

Reply #14
Unfortunately, Tremor in latest iAUDIO 7 firmware is indeed compiled with _LOW_ACCURACY_.
Full-quoting makes you scroll past the same junk over and over.

Tremor issues.

Reply #15
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.

 

Tremor issues.

Reply #16
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: [Select]
XdB(0x69f80e9a), XdB(0x70dafda8), XdB(0x78307d76), XdB(0x7fffffff),
where
Code: [Select]
#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.)
Full-quoting makes you scroll past the same junk over and over.

Tremor issues.

Reply #17
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.

Tremor issues.

Reply #18
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?

Tremor issues.

Reply #19
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?

Tremor issues.

Reply #20
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.

Tremor issues.

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


Tremor issues.

Reply #23
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.)
Full-quoting makes you scroll past the same junk over and over.

Tremor issues.

Reply #24
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.