"Engineer Hugo Fiennes took a break from his day job as a hardware and firmware designer at Rio Audio (maker of the iPod competitor Karma player, among other things) to give us some more info on the OGG-on-iPod."
iPod & Ogg
Full Version: Why iPod Can't play Vorbis
QUOTE(detokaal @ Jun 4 2004, 03:58 PM)
"Engineer Hugo Fiennes took a break from his day job as a hardware and firmware designer at Rio Audio (maker of the iPod competitor Karma player, among other things) to give us some more info on the OGG-on-iPod."
iPod & Ogg
iPod & Ogg
BTW, I sent Gizmodo a mild rebuttal to Hugo's article:
QUOTE
[re:
+http://www.gizmodo.com/archives/ogg-on-ipod-why-the-ipod-may-not-have-the-horsepower-for-ogg-015607
+.php]
Hi there; it's interesting to see one's software being talked about by
others as if it fell from the sky :-)
First off, the original iPod does indeed have the horsepower for Ogg;
the original Tremor codec written in C used approximately 40MHz of a
Cirrus Maverick (720TDMI), an ARM7 chip somewhat more underpowered
than the chip in the iPod. What the Maverick often has that many
other DSPs don't have is access to alot of memory. This was indeed a
stumbling block for a while.
Since then, we've made three mostly seperate branches of the Tremor
codec line (used in the Rio), each tailored to specific CPU and memory
structural differences found in different DSP architectures. Hugo
Fiennes didn't mention which he was using... or if he was aware there
are multiple different branches today (although I expect he is aware,
it's worth mentioning).
From the story:
"The 5002 has a "broken" cache (1 wait state per access for program or
data, meaning you effectively have half the effective clock rate when
running code from external memory). This means that running code that
doesn't fit in the internal 96kbyte SRAM of the player is very
inefficient, both in terms of CPU cycles and power."
He didn't say if he meant code, data or both, but modern Tremor can
fit both comfortably into this space. This is still substantially
faster than the ARM7 DRAM-based access Tremor was originally designed
for (using SRAM as a random-replacement cache with 7-14 wait-states on
a cache miss).
Also, he says it uses more power but also says they didn't optimize
much and so, they're mostly using the stock ANSI C Tremor decoder,
written by a single engineer (me) in a month as a 'starting point' to
help other engineers write a Vorbis decoder for their own
platforms. The mp3 playback is likely handcoded assembly written by a
professional team focused on only that task. This is in fact
astounding! It's also a testement to the power of good modern
compilers. I smile every time GCC soundly beats me at optimizing.
I agree that the newer iPods are more likely to decode Ogg and Vorbis
with ease. I do, however, strongly believe the original iPods can
also do so with room and cycles to spare.
Monty
TD, Xiph.Org
+http://www.gizmodo.com/archives/ogg-on-ipod-why-the-ipod-may-not-have-the-horsepower-for-ogg-015607
+.php]
Hi there; it's interesting to see one's software being talked about by
others as if it fell from the sky :-)
First off, the original iPod does indeed have the horsepower for Ogg;
the original Tremor codec written in C used approximately 40MHz of a
Cirrus Maverick (720TDMI), an ARM7 chip somewhat more underpowered
than the chip in the iPod. What the Maverick often has that many
other DSPs don't have is access to alot of memory. This was indeed a
stumbling block for a while.
Since then, we've made three mostly seperate branches of the Tremor
codec line (used in the Rio), each tailored to specific CPU and memory
structural differences found in different DSP architectures. Hugo
Fiennes didn't mention which he was using... or if he was aware there
are multiple different branches today (although I expect he is aware,
it's worth mentioning).
From the story:
"The 5002 has a "broken" cache (1 wait state per access for program or
data, meaning you effectively have half the effective clock rate when
running code from external memory). This means that running code that
doesn't fit in the internal 96kbyte SRAM of the player is very
inefficient, both in terms of CPU cycles and power."
He didn't say if he meant code, data or both, but modern Tremor can
fit both comfortably into this space. This is still substantially
faster than the ARM7 DRAM-based access Tremor was originally designed
for (using SRAM as a random-replacement cache with 7-14 wait-states on
a cache miss).
Also, he says it uses more power but also says they didn't optimize
much and so, they're mostly using the stock ANSI C Tremor decoder,
written by a single engineer (me) in a month as a 'starting point' to
help other engineers write a Vorbis decoder for their own
platforms. The mp3 playback is likely handcoded assembly written by a
professional team focused on only that task. This is in fact
astounding! It's also a testement to the power of good modern
compilers. I smile every time GCC soundly beats me at optimizing.
I agree that the newer iPods are more likely to decode Ogg and Vorbis
with ease. I do, however, strongly believe the original iPods can
also do so with room and cycles to spare.
Monty
TD, Xiph.Org
If Itunes started to use a well tuned VBR AAC version the ogg might not be necessary.
Look what Gabriel and the others have been able to do with Lame. If they ever pitch in with the FAAC project that is going to be one very hot well tuned codec.
Will Frank Klemm and Gabriel and the others ever devote time to AAC? I remember Gabriel expressing surprise with FAAC's efficiency despite the fact it has no special tunings (tricks) at all.
I don't know anything about the politics of all these various codecs so if I am offending in some way I certainly don't mean to.
It almost sounds like Faac could be turned into a monster with only a few tunings from these guys.It's exciting to think about.
Look what Gabriel and the others have been able to do with Lame. If they ever pitch in with the FAAC project that is going to be one very hot well tuned codec.
Will Frank Klemm and Gabriel and the others ever devote time to AAC? I remember Gabriel expressing surprise with FAAC's efficiency despite the fact it has no special tunings (tricks) at all.
I don't know anything about the politics of all these various codecs so if I am offending in some way I certainly don't mean to.
It almost sounds like Faac could be turned into a monster with only a few tunings from these guys.It's exciting to think about.
QUOTE(kennedyb4 @ Jun 4 2004, 09:44 PM)
If Itunes started to use a well tuned VBR AAC version the ogg might not be necessary.
But it'd be nice to have the option to play a gapless format on the iPod.
Unless they have a crossfader which can emulate gapless playback (which would actually be good enough for me).
AAC can be gapless - Apple just doesn't support that 
The (only) reason the iPod doesn't play OGG files is because there is no demand. If more people request it, they would probably implement it (according to Steve Jobs himself)...
QUOTE(Busemann @ Jun 5 2004, 01:25 PM)
The (only) reason the iPod doesn't play OGG files is because there is no demand. If more people request it, they would probably implement it (according to Steve Jobs himself)...
Of course there are only relatively few people asking for Ogg/MPC/whatever support. The typical consumer doesn´t care what formats are supported as longs as that thing plays music.
If Apple really was interested in best-possible user support they would release a SDK so "power-users" could extend iPod to their needs...
According to the Linux-on-iPod guys, stock tremor runs at about 80% realtime. Realtime playback should definetly be possible with some optimizations.
QUOTE(kennedyb4 @ Jun 5 2004, 12:44 PM)
Will Frank Klemm and Gabriel and the others ever devote time to AAC? I remember Gabriel expressing surprise with FAAC's efficiency despite the fact it has no special tunings (tricks) at all.
It's possible but at the moment, unlikely. A lot of people here donated a PC to Frank so that he can do development in MPC. There are lots of people working on AAC but only one on MPC (and likewise, only a small handful on Vorbis and LAME). If no-one worked on MPC and no-one worked on Vorbis or LAME, there'd be no competition, and in that case, no way of judging the quality of AAC, as we've done in the recent multiformat test. Because of MPCs stagnant development over the past few months, it has seen it's first place shared with Vorbis and it's lead narrowed a bit over LAME since both have more active development. This should serve as a catalyst for MPC developer(s) to put more effort int improving and tuning. The drive of competition is a beautiful thing because without it, there can be no real progression.
See, i'm thoroughly confused by this whole situation. Maybe i'm misunderstanding how the iPod's hardware is set up, but i was under the impression that (in addition to the actual CPU) the iPod had a dedicated MP3-decoding chip/processor/whatever you call it.
If the iPod's CPU is powerful enough to decode Vorbis (which is more intensive than MP3) on its own, why does it need a dedicated hardware MP3 decoder in addition just to decode MP3?
Or am i confused about the iPod's hardware after all? :/
If the iPod's CPU is powerful enough to decode Vorbis (which is more intensive than MP3) on its own, why does it need a dedicated hardware MP3 decoder in addition just to decode MP3?
Or am i confused about the iPod's hardware after all? :/
QUOTE(Lav @ Jun 6 2004, 10:15 AM)
See, i'm thoroughly confused by this whole situation. Maybe i'm misunderstanding how the iPod's hardware is set up, but i was under the impression that (in addition to the actual CPU) the iPod had a dedicated MP3-decoding chip/processor/whatever you call it.
If the iPod's CPU is powerful enough to decode Vorbis (which is more intensive than MP3) on its own, why does it need a dedicated hardware MP3 decoder in addition just to decode MP3?
Or am i confused about the iPod's hardware after all? :/
If the iPod's CPU is powerful enough to decode Vorbis (which is more intensive than MP3) on its own, why does it need a dedicated hardware MP3 decoder in addition just to decode MP3?
Or am i confused about the iPod's hardware after all? :/
Having a dedicated decoder chip extends battery life ++.
Somewhat off-topic, but on the subject of iPod:
I tried to search for this, but perhaps couldn't find correct English search words....
I hear that Apple's 3rd Gen iPods have a bug in the mp3 decoder that causes continuous steady signals to change in level considerably.
Has anybody verified / tested this?
Is it a know issue or something which is possibly (has been) fixed by firmware updates?
Regards,
halcyon
I tried to search for this, but perhaps couldn't find correct English search words....
I hear that Apple's 3rd Gen iPods have a bug in the mp3 decoder that causes continuous steady signals to change in level considerably.
Has anybody verified / tested this?
Is it a know issue or something which is possibly (has been) fixed by firmware updates?
Regards,
halcyon
QUOTE(Halcyon @ Jun 7 2004, 04:15 PM)
I hear that Apple's 3rd Gen iPods have a bug in the mp3 decoder that causes continuous steady signals to change in level considerably.
Has anybody verified / tested this?
Is it a know issue or something which is possibly (has been) fixed by firmware updates?
Has anybody verified / tested this?
Is it a know issue or something which is possibly (has been) fixed by firmware updates?
i don't know if i totally understand you, but someone told me about an underwatersound with 320kbps encoded MP3's. I tested it with some samples and i indeed heard some sort of stuttery sound. (320kbps MP3 only) Latest firmware upgrade didnt fix this..
I'm sorry, can't abx it
Actually this has been covered elsewhere:
http://www5.head-fi.org/forums/showthread....&threadid=67497
THe latest issue of Finnish Hifi magazine also tested and verified this bug.
It looks like the bug is in the mp3 decoder. I don't have one to test myself.
Sorry for off-topic content.
regards,
halcyon
http://www5.head-fi.org/forums/showthread....&threadid=67497
THe latest issue of Finnish Hifi magazine also tested and verified this bug.
It looks like the bug is in the mp3 decoder. I don't have one to test myself.
Sorry for off-topic content.
regards,
halcyon
QUOTE(maikmerten @ Jun 5 2004, 04:18 PM)
Of course there are only relatively few people asking for Ogg/MPC/whatever support. The typical consumer doesn´t care what formats are supported as longs as that thing plays music.
That's so true. The average standard user (which are about 95% I'd guess) just wants a small box that plays music upon pressing the biggest button. There's absolutely nothing wrong with that! We just have to accept that to the non-HA-world all that vbr/aac/ogg/codec/container/abx/bitrate/whatever stuff just isn't important (and in advance it isn't so important for the companys either). Try to explain it and they go
...I feel like a nerd right now
One point of note that no one is talking about here is the impact on battery life that ogg vorbis would have.
I own a iRiver HD player. iRiver claims you will get 16 hours playing 128 kbps CBR mp3 files. When using Ogg I can maybe get 11-12 hours (ogg -q8).
If Apple were to support ogg then the battery life would be something like 5 hours for the average ipod. How many owners wouild be thrilled with that?
JMHO
rs
I own a iRiver HD player. iRiver claims you will get 16 hours playing 128 kbps CBR mp3 files. When using Ogg I can maybe get 11-12 hours (ogg -q8).
If Apple were to support ogg then the battery life would be something like 5 hours for the average ipod. How many owners wouild be thrilled with that?
JMHO
rs
try WAV files. youll get much shorter than even ogg q8, though the cpu usage is negligible in comparison to ogg or mp3.
the battery life is directly related to how often the iriver has to spin up the hard drive.
you'll get better battery life with lower q's.
the battery life is directly related to how often the iriver has to spin up the hard drive.
you'll get better battery life with lower q's.
QUOTE(bani @ Jun 15 2004, 03:59 PM)
the battery life is directly related to how often the iriver has to spin up the hard drive.
It's also related to how much CPU is consumed on decoding.
battery life is impacted by far more by the hard drive than the cpu usage.
wav takes nearly negligible amounts of cpu but it eats the batteries by far more than any other codec.
dont worry about cpu usage. worry instead about the bitrate, which is directly related to how often your hard drive is going to have to spin up.
no point in encoding at q8 when q6 might be abx transparent for you. you'll get more storage space and better battery life to boot.
abx it guys, dont blindly q8!
wav takes nearly negligible amounts of cpu but it eats the batteries by far more than any other codec.
dont worry about cpu usage. worry instead about the bitrate, which is directly related to how often your hard drive is going to have to spin up.
no point in encoding at q8 when q6 might be abx transparent for you. you'll get more storage space and better battery life to boot.
abx it guys, dont blindly q8!
QUOTE(bani @ Jun 15 2004, 06:29 PM)
dont worry about cpu usage. worry instead about the bitrate, which is directly related to how often your hard drive is going to have to spin up.
Instead of worrying about bitrate, I would actually worry about format.
So, WAV is nono because disk access takes too much energy.
Vorbis is nono because tremor isn't nearly as optimized for DSP platforms as commercial MP3 and AAC decoders.
So there.
QUOTE
dont worry about cpu usage. worry instead about the bitrate, which is directly related to how often your hard drive is going to have to spin up.
no point in encoding at q8 when q6 might be abx transparent for you. you'll get more storage space and better battery life to boot.
abx it guys, dont blindly q8!
no point in encoding at q8 when q6 might be abx transparent for you. you'll get more storage space and better battery life to boot.
abx it guys, dont blindly q8!
Couldn't agree more
And if anything be done blindly it should be q3 or q4 not q8
QUOTE(rickshaw @ Jun 10 2004, 03:52 AM)
I own a iRiver HD player. iRiver claims you will get 16 hours playing 128 kbps CBR mp3 files. When using Ogg I can maybe get 11-12 hours (ogg -q8).
Also, claimed battery lives are for non-stop play without turning the player on and off, something that will take a few hours off.
QUOTE(cheerow @ Jun 10 2004, 06:31 AM)
QUOTE(maikmerten @ Jun 5 2004, 04:18 PM)
Of course there are only relatively few people asking for Ogg/MPC/whatever support. The typical consumer doesn´t care what formats are supported as longs as that thing plays music.
That's so true. The average standard user (which are about 95% I'd guess) just wants a small box that plays music upon pressing the biggest button. There's absolutely nothing wrong with that! We just have to accept that to the non-HA-world all that vbr/aac/ogg/codec/container/abx/bitrate/whatever stuff just isn't important (and in advance it isn't so important for the companys either). Try to explain it and they go
...I feel like a nerd right now
But remember, if it weren't for the obsessive, over-zealous types (not to put words in the mouths of any fellow HA'ers, but c'mon face it, we are) there wouldn't be this little company you might've heard of, I think the name is Microsoft or something.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.