Hydrogenaudio Forums

Lossy Audio Compression => Ogg Vorbis => Ogg Vorbis - Tech => Topic started by: HbG on 06 May, 2005, 07:23:22 AM

Title: Tremor issues.
Post by: HbG on 06 May, 2005, 07:23:22 AM
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?
Title: Tremor issues.
Post by: john33 on 06 May, 2005, 07:33:24 AM
http://www.rarewares.org/files/ogg/oggdecT.zip (http://www.rarewares.org/files/ogg/oggdecT.zip)
Title: Tremor issues.
Post by: HbG on 06 May, 2005, 08:24:26 AM
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?
Title: Tremor issues.
Post by: john33 on 06 May, 2005, 08:48:33 AM
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!!
Title: Tremor issues.
Post by: HbG on 06 May, 2005, 09:43:55 AM
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...
Title: Tremor issues.
Post by: aspifox on 06 May, 2005, 11:16:14 AM
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...
Title: Tremor issues.
Post by: HbG on 06 May, 2005, 04:32:15 PM
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.
Title: Tremor issues.
Post by: picard on 23 May, 2005, 03:32:38 AM
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...
Title: Tremor issues.
Post by: HbG on 23 May, 2005, 07:50:58 AM
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  (http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=1556)
Title: Tremor issues.
Post by: rt87 on 23 May, 2005, 12:59:00 PM
Quote
Quote
I hope no-one is shipping player products using low-precision Tremor mode, but...
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=295676")

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]
Title: Tremor issues.
Post by: picard on 23 May, 2005, 05:23:41 PM
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...
Title: Tremor issues.
Post by: system_saboteur_13 on 01 July, 2005, 08:13:55 AM
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 (http://www.sandvall.nu/patch) but this link was dead  .

Could someone please send me this patch?

Thanks in advance 
Title: Tremor issues.
Post by: cruzlee on 14 August, 2008, 04:57:48 PM
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 (http://www.cowonamerica.com/forums/showthread.php?t=13253)
Title: Tremor issues.
Post by: saratoga on 14 August, 2008, 05:27:28 PM
It would be odd for them to use low precision given how ridiculously fast Tremor would be on the Iaudio 7's CPU.
Title: Tremor issues.
Post by: Yirkha on 15 August, 2008, 09:37:31 AM
Unfortunately, Tremor in latest iAUDIO 7 firmware is indeed compiled with _LOW_ACCURACY_.
Title: Tremor issues.
Post by: sprockkets on 15 August, 2008, 03:45:11 PM
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.
Title: Tremor issues.
Post by: Yirkha on 15 August, 2008, 04:44:41 PM
By actually seeing the co... uhm, nobody can have their code, of course.

See Tremor source code, floor1.c (http://svn.xiph.org/trunk/Tremor/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.)
Title: Tremor issues.
Post by: Rotareneg on 15 August, 2008, 04:52:04 PM
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.
Title: Tremor issues.
Post by: sprockkets on 19 August, 2008, 08:20:01 PM
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?
Title: Tremor issues.
Post by: sprockkets on 19 August, 2008, 08:51:35 PM
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?
Title: Tremor issues.
Post by: saratoga on 19 August, 2008, 11:22:25 PM
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 (http://forums.rockbox.org/index.php?topic=15360.msg131268#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.
Title: Tremor issues.
Post by: sprockkets on 19 August, 2008, 11:37:15 PM
Ok, so explain to me what it means to ((((n)>>8)+1)>>1) the hex values so I can do more searching.
Title: Tremor issues.
Post by: saratoga on 19 August, 2008, 11:45:28 PM
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.
Title: Tremor issues.
Post by: Yirkha on 20 August, 2008, 12:15:20 AM
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.)
Title: Tremor issues.
Post by: sprockkets on 20 August, 2008, 01:00:22 AM
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.
Title: Tremor issues.
Post by: Yirkha on 20 August, 2008, 12:30:30 PM
I'm hacking the original firmware, selfishly without anyone else, only to solve a few issues I have with a gadget I bought. I know those three forums only indirectly from occasional Googling.
Title: Tremor issues.
Post by: pellgarlic on 29 May, 2009, 10:33:50 AM
i know this is a relatively old post, but i came across it myself when looking for info about this problem, so thought it would be a good place to put an update...

i just wanted to share some new info with anyone who already owns, or is thinking about getting an iaudio 7 - there is a new firmware release - 1.18 (go here: http://www.cowonglobal.com/ (http://www.cowonglobal.com/) to get it) - which fixes this particular problem (the vorbis distortion).

it was a significant problem for me (as my music collection is predominantly in ogg-vorbis format), but i didnt find out until after i had purchased the player. to be honest, i couldn't find another player which ticked all the boxes for me that the i7 does, so i was pretty peeved, and loathe to start the hunt for an alternative, so i emailed cowon support (as many other people have probably done too) and got a few replies, the last one being a few days ago, saying they were releasing a fix 

i have now downloaded it and tested it, and can confirm that it has resolved the distortion-caused-by-low-frequency problem. may i say... "woohoo!"

(any eagle-eyes out there may spot that i pasted the exact same message in a couple of other places... didn't think it was worth re-typing it in different words, but did think it was info worthy of mass dissemination...  )
Title: Tremor issues.
Post by: Yirkha on 29 May, 2009, 01:14:51 PM
That's great news, thank you very much! It's nice to see continuing support for an older product like this.
Title: Tremor issues.
Post by: AshenTech on 31 May, 2009, 08:40:48 PM
ogg support isnt really that hard to find, sansa clip/fuze/view support it, samsungs players all support ogg from my experiance, iaudio and cowan have ogg support.

what I would like to see is more musepack support, gonna get on sansa about it now that i got a fuze
Title: Tremor issues.
Post by: saratoga on 31 May, 2009, 10:15:53 PM
Hopefully MPC will be available on the Fuze soon via rockbox.

That said, Tremor could still use some work.  Most firmwares have very slow ogg decoding leading to decreased battery life.  A faster IMDCT in Tremor would go a long way towards fixing that.  Unfortunately most people are hesitant to release code like that under suitable license.
Title: Tremor issues.
Post by: AshenTech on 01 June, 2009, 12:12:18 AM
Hopefully MPC will be available on the Fuze soon via rockbox.

That said, Tremor could still use some work.  Most firmwares have very slow ogg decoding leading to decreased battery life.  A faster IMDCT in Tremor would go a long way towards fixing that.  Unfortunately most people are hesitant to release code like that under suitable license.


only issue i have had with rockbox is on some units it lessens batt life quite drastically, so much so that the bennifit isnt worth the cost for people like me who use their units for long periods(got fuze in part because its got great batt life)

we will see, I wont rockbox my fuze till its debuged and there are reports on its effect on batt life :/
Title: Tremor issues.
Post by: saratoga on 01 June, 2009, 10:55:09 AM
only issue i have had with rockbox is on some units it lessens batt life quite drastically,


This isn't true.
Title: Tremor issues.
Post by: Rotareneg on 01 June, 2009, 01:07:33 PM
Wow, I figured they would never fix that! Time to convert everything to Vorbis at -q3.
Title: Tremor issues.
Post by: AshenTech on 01 June, 2009, 10:39:30 PM
only issue i have had with rockbox is on some units it lessens batt life quite drastically,


This isn't true.


try the older 80gb ipod, with parametric EQ enabled it droped bat life by 1/3 for alot of people.........thats a pretty big hit if you ask me......other players have gotten simlar effects from being boxed, others havent lost anything....i would rather just wait and see
Title: Tremor issues.
Post by: saratoga on 01 June, 2009, 10:46:13 PM
only issue i have had with rockbox is on some units it lessens batt life quite drastically,


This isn't true.


try the older 80gb ipod,


Battery life is the same or perhaps little better then the Apple firmware.

other players have gotten simlar effects from being boxed, others havent lost anything....i would rather just wait and see


Why wait?  You could see right now.
Title: Tremor issues.
Post by: Soap on 01 June, 2009, 10:50:02 PM
only issue i have had with rockbox is on some units it lessens batt life quite drastically,


This isn't true.


try the older 80gb ipod, with parametric EQ enabled it droped bat life by 1/3 for alot of people.........thats a pretty big hit if you ask me......other players have gotten simlar effects from being boxed, others havent lost anything....i would rather just wait and see

Rockbox beats the iPod retail firmware when comparing like to like.  Hasn't always, historically, but does now.  Period.

Beats every other device's original firmware runtime as well.
There are runtime wikipages of user submitted battery benchmarks (a Rockbox TSR logger) documenting this for every target.

Burn tons of CPU using 5 bands of a much more complex EQ than Apple offers and don't be shocked it comes at a cost.

EDIT:  Mike beat me.
Battery life is the same or perhaps little better then the Apple firmware.

On the 5G with MP3 it should be a clear victory for Rockbox.  I've been getting over 19 hour real-world runtimes (starting/stopping, backlight, replaygain, crossfeed, etc) on my 5G, haven't benched the OF for well over a year, but was only getting 20.75 hours then when doing the synthetic (no backlight, yadda yadda yadda).
The LCD controller shutdown really pushed Rockbox over the edge on the always problematic 5th gens.
Title: Tremor issues.
Post by: timber on 03 June, 2009, 09:14:17 AM
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 (http://www.sandvall.nu/patch) but this link was dead  .

Could someone please send me this patch?

Thanks in advance 


Just in case someone might still be interested, I think itùs this one
http://fanoush.wz.cz/maemo/sandvall-tremor.patch (http://fanoush.wz.cz/maemo/sandvall-tremor.patch)