IPB

Welcome Guest ( Log In | Register )

9 Pages V   1 2 3 > »   
Reply to this topicStart new topic
How far will AAC plus go?
dnewhous
post Aug 18 2005, 07:04
Post #1





Group: Members
Posts: 62
Joined: 3-February 05
Member No.: 19550



Nero is the only retail product supporting AAC+. Does anyone think it has any chance of ever being supported by the broader consumer market? Like portable audio players and car CD players?
Go to the top of the page
+Quote Post
vinnie97
post Aug 18 2005, 07:14
Post #2





Group: Members
Posts: 472
Joined: 6-March 03
Member No.: 5360



*dons flamewar* Who needs it at least at ~80 kbps and above? tongue.gif
Go to the top of the page
+Quote Post
dnewhous
post Aug 18 2005, 07:26
Post #3





Group: Members
Posts: 62
Joined: 3-February 05
Member No.: 19550



Point taken. So then let me add to my question, will we ever see VBR AAC supported in the general consumer market?
Go to the top of the page
+Quote Post
zombiewerewolf
post Aug 18 2005, 07:52
Post #4





Group: Members
Posts: 119
Joined: 27-January 03
From: Perth, AU
Member No.: 4755



IMO, AAC+ is likely to have more support in mobile phone.

I found some test about codecs and their battery consumtion. (ex:iriver battery test)
I really want to know about AAC+ energy consumtion. How much different when compare to Ogg, WMA, AAC or MP3? Anyone have information on this?

Even without audio playing capability, smart phones are hardly survive a day. It would be great if AAC+ is battery friendly.

This post has been edited by zombiewerewolf: Aug 18 2005, 10:43
Go to the top of the page
+Quote Post
Oki
post Aug 18 2005, 09:24
Post #5





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (dnewhous @ Aug 18 2005, 08:04 AM)
Nero is the only retail product supporting AAC+.  Does anyone think it has any chance of ever being supported by the broader consumer market?  Like portable audio players and car CD players?
Nero is one of them. There are a lot of other companies supporting HE AAC:
- In the encoding front you can find companies like like RealNetworks, Helix, Sorenson, Coding Technologies among other initiatives.
- In the Steaming front you have Nullsoft (Winamp), Yahoo!, XM Satellite Radio, Digital Radio Mondiale, and many other players like Foobar2000, etc...
- In the hardware arena you have Siemens, Motorola, O2, Nokia, all the 3GPP members, Apple in a near future, etc...

HE AAC has also been approved as a mandatory compression format for the ROM zone of DVD-Audio by the DVD Forum in June 2004.

Do not worry, HE AAC will be the MP3 format of the future. When? soon, very soon. One of the most important reasons is that most cell phones will have a lot of memory or flash card support and they will be able to play AAC+ and even AAC++ audio thus taking most of the market share of the current portable audio solutions.
Go to the top of the page
+Quote Post
Digisurfer
post Aug 19 2005, 04:14
Post #6





Group: Members
Posts: 371
Joined: 10-August 04
From: Canada
Member No.: 16174



The revolution for internet radio is only just getting off the ground now (or at least soon) I think. That's another area where it will eventually dominate I think.

By the way, I'm confused. I know Nero supports HE-ACC, but ACC+ v1 and v2 aren't just HE-ACC, correct? ACC+ is HE-ACC plus a few other tricks, like SBR and what not. So technically Nero does not actually support ACC+ (yet).
Go to the top of the page
+Quote Post
dnewhous
post Aug 19 2005, 04:50
Post #7





Group: Members
Posts: 62
Joined: 3-February 05
Member No.: 19550



AAC+ and HE-AAC are exactly the same thing.

Hopefully XM radio will start streaming in AAC+. If they did, I'd subscribe again in a heartbeat. The content is incomparable.

This post has been edited by dnewhous: Aug 19 2005, 06:57
Go to the top of the page
+Quote Post
Oki
post Aug 19 2005, 10:25
Post #8





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (Digisurfer @ Aug 19 2005, 05:14 AM)
By the way, I'm confused. I know Nero supports HE-ACC, but ACC+ v1 and v2 aren't just HE-ACC, correct? ACC+ is HE-ACC plus a few other tricks, like SBR and what not. So technically Nero does not actually support ACC+ (yet).
This a basic abstract about the AAC family:

AAC = MPEG2 AAC ~= MP3 + TNS + TP (It is not an upgrade of MP3 since it is not backward compatible but uses all MP3's features in a better way).

MPEG4 AAC = MPEG2 AAC + LTP + PNS
There are several profliles depending on the decoding/encoding complexity, required power, delay, bandwith characteristics, error resilience characteristics, etc... The most used profile in the PC arena is the AAC LC (Low Complexity) = MPEG4 AAC without LTP.

HE-AAC = SBR + AAC LC
Coding Technologies, developers of SBR, named this coding aacPlus™, also known as AAC+, HE-AAC, AACP, AAC-LC+SBR, etc... SBR technology was prevously introduced in the MP3pro codec.

HE-AAC v2= PS + HE-AAC
Coding Technologies, developers of the MPEG Parametric Stereo, named this coding aacPlus™ v2 as a new revision of the previous release. It is also known as AAC++, EAAC+, Enhanced HE-AAC, EAACP, HE-AAC+PS, etc... Recently it was standarized by ISO as HE-AAC v2.

S-AAC...(Just guessing, not yet released but in Reference Model 0 stage)
Since MPEG is focusing in multichannel, the next standard will be something based in the Spatial Audio Coding tool standarized as MPEG Surround, that allows to do someting similar to PS but aimed to 5.1ch or 7.1ch content. This could be named as S-AAC, AAC Surround or AACS, Surround HE-AAC, [Put your favorite name here]. There isn't an official name for it yet.

Terms and acronyms:

AAC Advanced Audio Coding, developed by Dolby Laboratories.

TNS Temporal Noise Shaping is a tool designed to control the location, in time, of the quantization noise by transmission of filtering coefficients.

TP Temporal Prediction is a tool designed to enhance compressibility of stationnary signals.

LTP Long Term Prediction is once again a prediction tool. This one requires less computation power but it is far more complex than the one used in MPEG-2 AAC, while providing comparable coding performance.

PNS Perceptual Noise Substitution, allows to replace coding of noise-like parts of the signal by some noise generated on the decoder side, so the decoding result is not deterministic among multiple decoding processes of the same encoded data.

SBR Spectral Band Replication is a tool that creates associated higher frequency content based on the lower frequencies and coding it as statistical information: level, distribution and ranges. Each of these parameters is encoded separately, taking account of their distinctive characteristics. It involves reconstruction of a noise-like frequency spectrum by employing a noise generator with some statistical information (level, distribution, ranges), so the decoding result is not deterministic among multiple decoding processes of the same encoded data. Both ideas are based on the principle that the human brain tends to consider high frequencies to be either harmonic phenomena associated with lower frequencies or noise, and is thus less sensitive to the exact content of high frequencies in audio signals.

PS Parametric Stereo, the stereo image information is separated from the mono signal being represented as a small amount of high quality parametric stereo information. The scheme relies on dissecting the incoming audio signal into three ‘objects’ that are a common constituent of all audio signals: transients, sinusoids and noise The stereo information is efficiently parameterized. Each of these objects is encoded separately, taking account of their distinctive characteristics. Like PNS and SBR the decoding result is not deterministic among multiple decoding processes of the same encoded data.

SAC Spatial Audio Coding exploits inter-channel differences in level, phase and coherence to capture the spatial image of a multi-channel audio signal relative to a transmitted downmix signal. It encodes each of these cues separately taking account of their distinctive characteristics such that the cues, and the transmitted signal, can be decoded to synthesize a high quality multi-channel representation allowing higher compression than separate channel coding.

I hope this clarifies a little all the confusion about the AAC codec family and the technology it uses.

Regards,
Oki

Edit: typo and added details.

This post has been edited by Oki: Sep 22 2005, 15:17
Go to the top of the page
+Quote Post
Oki
post Aug 19 2005, 10:29
Post #9





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (dnewhous @ Aug 19 2005, 05:50 AM)
Hopefully XM radio will start streaming in AAC+.  If they did, I'd subscribe again in a heartbeat.
My friend, MX Satellite Radio is broadcasting in AAC+ since quite some time. In the XM Satellite Radio FAQ you can read this:

"XM searched the world for the best sound quality technologies and found them in customized CT-aacPlus audio encoding with Neural Audio optimization, which provides superior sound quality remarkably close to Compact Disc."

and

"The key to XM's outstanding sound quality is CT-aacPlus, a third-generation audio encoding technology."

Hurry up!!!

Regards,
Oki
Go to the top of the page
+Quote Post
Digisurfer
post Aug 19 2005, 12:52
Post #10





Group: Members
Posts: 371
Joined: 10-August 04
From: Canada
Member No.: 16174



Thanks for the in-depth reply Oki! biggrin.gif
Go to the top of the page
+Quote Post
dnewhous
post Aug 19 2005, 16:57
Post #11





Group: Members
Posts: 62
Joined: 3-February 05
Member No.: 19550



QUOTE (Oki @ Aug 19 2005, 04:29 AM)
My friend, MX Satellite Radio is broadcasting in AAC+ since quite some time. In the XM Satellite Radio FAQ you can read this:

"XM searched the world for the best sound quality technologies and found them in customized CT-aacPlus audio encoding with Neural Audio optimization, which provides superior sound quality remarkably close to Compact Disc."

and

"The key to XM's outstanding sound quality is CT-aacPlus, a third-generation audio encoding technology."

Hurry up!!!

Regards,
Oki
*


That's the satellilte broadcast, not the internet stream. Why don't you pay attention to what I am talking about before trying to correct me?

This post has been edited by dnewhous: Aug 19 2005, 16:58
Go to the top of the page
+Quote Post
yahknow1
post Aug 19 2005, 17:18
Post #12





Group: Members
Posts: 71
Joined: 23-February 05
Member No.: 20082



QUOTE (dnewhous @ Aug 19 2005, 08:57 AM)
QUOTE (Oki @ Aug 19 2005, 04:29 AM)
My friend, MX Satellite Radio is broadcasting in AAC+ since quite some time. In the XM Satellite Radio FAQ you can read this:

"XM searched the world for the best sound quality technologies and found them in customized CT-aacPlus audio encoding with Neural Audio optimization, which provides superior sound quality remarkably close to Compact Disc."

and

"The key to XM's outstanding sound quality is CT-aacPlus, a third-generation audio encoding technology."

Hurry up!!!

Regards,
Oki
*


That's the satellilte broadcast, not the internet stream. Why don't you pay attention to what I am talking about before trying to correct me?
*


Wow, I took it as Oki was trying to help you....what's the big deal if he didn't understand EXACTLY what you were saying....? blink.gif
Go to the top of the page
+Quote Post
vinnie97
post Aug 20 2005, 04:14
Post #13





Group: Members
Posts: 472
Joined: 6-March 03
Member No.: 5360



The big deal is excessive "sensitivity." wink.gif
Go to the top of the page
+Quote Post
ckjnigel
post Aug 20 2005, 09:13
Post #14





Group: Members
Posts: 218
Joined: 12-October 01
Member No.: 278



I'd still like to know what codec AOL is using to broadcast 72 XM stations to its subscribers. AOL is secretive but the fact that they too have inked a deal with Coding Technologies makes me suspect they'll shift all Radio@AOL to this AAC+. The problems with keeping steady volume levels (it is a beta) when there's lots of bass makes me suspect that SBR is in there. I've converted my laptop to an AOL/XM stream radio using the fat AOL client and a direct USB cable to my JVC receiver. It sounds awesome.
As to Coding Technologies AAC+, I think it's the shiznit. I use it for music on my Pocket PC (encoded at 80 kbps using Magix MP3 Maker Deluxe 10) and I do think play time is longer than with MP3s or Ogg. But, I'd have to put MP3s on the CF microdrive if I wanted adequate variety and that certainly uses more juice than running off the 2 Gb Sandisk SD card.
Go to the top of the page
+Quote Post
Defsac
post Aug 20 2005, 09:55
Post #15





Group: Members
Posts: 347
Joined: 17-May 05
Member No.: 22107



QUOTE (ckjnigel @ Aug 20 2005, 06:13 PM)
I use it for music on my Pocket PC (encoded at 80 kbps using Magix MP3 Maker Deluxe 10) and I do think play time is longer than with MP3s or Ogg.
*
What software do you use for playback? I tried most of the 3rd party players but ended up just using WMP with MP3 (LAME APS).
Go to the top of the page
+Quote Post
ckjnigel
post Aug 20 2005, 17:02
Post #16





Group: Members
Posts: 218
Joined: 12-October 01
Member No.: 278



QUOTE (Defsac @ Aug 20 2005, 03:55 AM)
QUOTE (ckjnigel @ Aug 20 2005, 06:13 PM)
I use it for music on my Pocket PC (encoded at 80 kbps using Magix MP3 Maker Deluxe 10) and I do think play time is longer than with MP3s or Ogg.
*
What software do you use for playback? I tried most of the 3rd party players but ended up just using WMP with MP3 (LAME APS).
*


BetaPlayer, but the new incarnation redubbed TCPMP works fine, too.
Go to the top of the page
+Quote Post
Oki
post Aug 21 2005, 23:15
Post #17





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (zombiewerewolf @ Aug 18 2005, 08:52 AM)
I really want to know about AAC+ energy consumtion. How much different when compare to Ogg, WMA, AAC or MP3? Anyone have information on this?
*
I can give you the computational complexity of several decoding implementations on a ADSP-218x DSP:
MP3: 36 MIPS
AAC: 48 MIPS
HE-AAC: 48 MIPS
HE-AAC v2: 66 MIPS
This can give you an approximate idea about the diffenrence between these algorithms. But remember that the power consumtion of the processor is not the only thing you have as a load of your baterry; you have a memory, an analog amplifier, a display, etc... so the global difference in power consumtion of a portable audio device should be less than the difference in computational complexity when playing back different kind of audio codings.
QUOTE (zombiewerewolf @ Aug 18 2005, 08:52 AM)
Even without audio playing capability, smart phones are hardly survive a day. It would be great if AAC+ is battery friendly.
*
The big load on a battery is the OS, the display controller (now they even have 3D accelerated functions based in OpenGL), the screen and the radio module. Playing AAC+ or MP3 should not be much different when considering the life of the battery.

Regards,
Oki
Go to the top of the page
+Quote Post
dnewhous
post Aug 21 2005, 23:21
Post #18





Group: Members
Posts: 62
Joined: 3-February 05
Member No.: 19550



QUOTE (ckjnigel @ Aug 20 2005, 03:13 AM)
I'd still like to know what codec AOL is using to broadcast 72 XM stations to its subscribers.
*


I found the link. The free version sounds awful. I guess it's 24 kbps WMA. Will the pay version really sound better than 64 kbps WMA that is available directly from XM online?

This post has been edited by dnewhous: Aug 22 2005, 03:01
Go to the top of the page
+Quote Post
rjamorim
post Aug 22 2005, 01:02
Post #19


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (Oki @ Aug 21 2005, 07:15 PM)
AAC: 48 MIPS
HE-AAC: 48 MIPS
HE-AAC v2: 66 MIPS
*


That sounds very wrong.

For once, HE AAC should consume much more CPU power than pure LC AAC, as besides the LC part, it has the SBR part to decode.

And HE AAC v2 should consume a little less than HE AAC, since the decoding is done in one channel, and only later the spatialization information is applied to the stream.

For further proof, I point you at this FhG page:
http://www.iis.fraunhofer.de/amm/techinf/a..._dsp/index.html

A stereo LC AAC decoder requires as little as one DSP56300 @ 25MHz
A HE AAC decoder, OTOH, requires one DSP 56300 @ 80 MHz (and more SRAM)


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Oki
post Aug 22 2005, 08:47
Post #20





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (rjamorim @ Aug 22 2005, 02:02 AM)
QUOTE (Oki @ Aug 21 2005, 07:15 PM)
AAC: 48 MIPS
HE-AAC: 48 MIPS
HE-AAC v2: 66 MIPS
*


That sounds very wrong.

For once, HE AAC should consume much more CPU power than pure LC AAC, as besides the LC part, it has the SBR part to decode.

And HE AAC v2 should consume a little less than HE AAC, since the decoding is done in one channel, and only later the spatialization information is applied to the stream.

For further proof, I point you at this FhG page:
http://www.iis.fraunhofer.de/amm/techinf/a..._dsp/index.html

A stereo LC AAC decoder requires as little as one DSP56300 @ 25MHz
A HE AAC decoder, OTOH, requires one DSP 56300 @ 80 MHz (and more SRAM)
*


SBR and PS algorithms were developed by Coding Technologies and your link points to a competitor. A competitor such as FhG will not give you good numbers on their technology (Remember that Coding Technologies was a spin off of FhG) since they do not have the latest developments on SBR implemented in their products. Just look at the link you give, you can see that FhG does not have enough experience in HE-AAC since they only have one implementation of HE-AAC compared to 8 implementations of the AAC-LC algorithm. Simply their SBR know-how is not mature enough. I will explain why my numbers are closer to the reality than those from FhG:

FhG is giving you the computational complexity of High Quality SBR, this makes HE-AAC 30% more complex than AAC-LC but Coding Technologies released a Low Power SBR algorithm with 30% less computational complexity. Subjective quality test results demostrated that there was no statistical difference between HQ-SBR and LP-SBR when they are incorporated into AAC decoders and CT implementations use CT's latest and more advanced method, being chosen as a standard by 3GPP. That leaves AAC-LC and HE-AAC (using the new LP-SBR algorithm) at the same level of complexity.

Why does HE-AAC v2 need more computational power? Because Parametric Stereo needs the HQ-SBR tool and it can not be implemented with the LP-SBR. The huge difference in power consumtion comes from this fact.

Note that implementations on different platforms are not proportional and you always have to take into account the processor you are going to use before evaluating the difference in complexity. In the page you are giving, If you take the ADSP21060, you would conclude that MP3 decoding requires the same speed than AAC-LC decoding, 40MHz.

Regards,
Oki

Edit: typo

This post has been edited by Oki: Aug 22 2005, 10:36
Go to the top of the page
+Quote Post
ckjnigel
post Aug 22 2005, 09:50
Post #21





Group: Members
Posts: 218
Joined: 12-October 01
Member No.: 278



That's interesting, Oki. Isn't it likely that CT has developed optimizations for SSE extensions on Intel chips, though? I'm a Mozillian and I've been amazed by the Firefox speed improvements achievable by builders like mmoy who optimize for chip features, cut cycles and so on. I've been wondering if that's part of what CT's deal with AOL involves. AAC+ surely is less taxing than a VBR Ogg file, don't you think?
As to the question about how XM on AOL sounds ... it certainly beats any 64 kbps WMA by a wide margin. I noticed that shifting DAC processing from my 1.5 mhz Celeron notebook to my new JVC receiver by connecting with USB cable eliminated breakups and distortion.
Go to the top of the page
+Quote Post
Oki
post Aug 22 2005, 13:02
Post #22





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (ckjnigel @ Aug 22 2005, 10:50 AM)
That's interesting, Oki.  Isn't it likely that CT has developed optimizations for SSE extensions on Intel chips, though? I'm a Mozillian and I've been amazed by the Firefox speed improvements achievable by builders like mmoy who optimize for chip features, cut cycles and so on.
*
Improving power consumption in the PC arena is not important, most computers can play HE-AAC and HE-AAC v2 without any problem, using less than a mere 2-3% of the resources. CT should focus on improving HE-AAC v2 on several DSPs or researching on a Low Power Parametric Stereo algorithm, 3GPP members would be very welcome.
QUOTE (ckjnigel @ Aug 22 2005, 10:50 AM)
AAC+ surely is less taxing than a VBR Ogg file, don't you think?
*
I will use real values for estimating the power consumtion of AAC compared to OGG:
Rio Karma has a 3.7V 1600mAh battery and it can handle 16 hours of MP3 and 11 Hours of ogg, that means that the relative difference in power consumption is (Tmp3/Togg - 1) x 100 % = 45% But the power load of MP3 decoding is not that much, most of the power is taken by the hard drive. An ARM7 needs about 10MHz to decode MP3 and about 180Mhz for OGG (for this purpose Rio Karma has 2 x ARM7 processors running at 90MHz) this is 18 times more power for ogg than for MP3!!!! If we do some calculations, it means that Wmp3 = 1 /37 Wtotal. That means that the MP3 decoding uses only Wmp3 = 10mW and OGG needs 180mW!!! This numbers make perfect sense because iPod Shuffle with a 3.7V 220mAh battery provides 12 hours of MP3 or AAC audio (note that the power requirements are the same for AAC than for MP3). The power consumption is about the same because, for the iPod shuffle, Wtotal = 67mW. Maybe the decoding process is taking 1/4 or less of the total, giving numbers very close to those from the very efficient ARM7 processor.

Concluding,
1st: Wogg ~= 18 x Waac;
2nd: Waac ~= Wmp3 in the newest implementations.

In the same way you can expect similar improvements in HE-AAC decoders in the near future, and we will see that HE-AAC decoders require the same power than MP3 decoders.
QUOTE (zombiewerewolf @ Aug 18 2005, 08:52 AM)
I found some test about codecs and their battery consumtion. (ex:iriver battery test)
I really want to know about AAC+ energy consumtion. How much different when compare to Ogg, WMA, AAC or MP3? Anyone have information on this?
*
The page you give is a perfect example of what I try to say, compare the 14.75h of MP3 playback with the 9.5 hours of OGG using the same hardware. The conclusion is similar to the Rio Karma one.


Regards,
Oki

Edit: typo

This post has been edited by Oki: Aug 22 2005, 14:15
Go to the top of the page
+Quote Post
rjamorim
post Aug 22 2005, 14:12
Post #23


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (Oki @ Aug 22 2005, 04:47 AM)
SBR and PS  algorithms were developed by Coding Technologies and your link points to a competitor. A competitor such as FhG will not give you good numbers on their technology (Remember that Coding Technologies was a spin off of FhG) since they do not have the latest developments on SBR implemented in their products.


LOL. They are not competitors, they have worked as partners since CT spun off! Guess who made the underlying MP3 and AAC encoders in MP3pro and HE AAC? If FhG really regarded CT as a fierce competitor, they would tell them to screw off and go find another encoder.

QUOTE
Just look at the link you give, you can see that FhG does not have enough experience in HE-AAC since they only have one implementation of HE-AAC compared to 8 implementations of the AAC-LC algorithm.


So you make conclusions of their experience based on how many DSPs they develop to? And later you think twice and decide the fact is that FhG is using another variant of SBR than CT? Bleh.

QUOTE
Simply their SBR know-how is not mature enough.


This is bullshit. Their SBR know-how is just as good as CT's. Why wouldn't CT want a partner as powerful and influential as FhG? Sure, FhG would make more profit in selling DSP implementations. But CT would have their IP licensing income guaranteed.

QUOTE
FhG is giving you the computational complexity of High Quality SBR, this makes HE-AAC 30% more complex than AAC-LC but Coding Technologies released a Low Power SBR algorithm with 30% less computational complexity. Subjective quality test results demostrated that there was no statistical difference between HQ-SBR and LP-SBR when they are incorporated into AAC decoders and CT implementations use CT's latest and more advanced method, being chosen as a standard by 3GPP. That leaves AAC-LC and HE-AAC (using the new LP-SBR algorithm) at the same level of complexity.


Got proof of that? That is really hard to swallow based on most people's experience.

QUOTE
Note that implementations on different platforms are not proportional and you always have to take into account the processor you are going to use before evaluating the difference in complexity. In the page you are giving, If you take the ADSP21060, you would conclude that MP3 decoding requires the same speed  than AAC-LC decoding, 40MHz.
*


Duh, that's precisely why I only mentioned the 53600 on my post.


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
spoon
post Aug 22 2005, 14:50
Post #24


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2745
Joined: 24-March 02
Member No.: 1615



>An ARM7 needs about 10MHz to decode MP3
>ADSP-218x DSP MP3: 36 MIPS

The ADSP is a cisc processor - (ARM is risc?), and is able to handle 3 operations per instruction cycle (a multiply, add and move for example) - all instructions are done within a single instruction cycle (unlike an intel processor, perhaps even the ARM because of the limited risc instructions).

So why is a DSP processor (which is good at maths) taking 36MHz (which is really 36*3 on the ADSP or 108MHz) to decode something a 10MHZ arm processor can decode? Something doesn't seem right...


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Oki
post Aug 22 2005, 23:25
Post #25





Group: Members
Posts: 98
Joined: 20-July 05
From: Barcelona (Spain)
Member No.: 23436



QUOTE (spoon @ Aug 22 2005, 03:50 PM)
>An ARM7 needs about 10MHz to decode MP3
>ADSP-218x DSP MP3: 36 MIPS

So why is a DSP processor (which is good at maths) taking 36MHz (which is really 36*3 on the ADSP or 108MHz) to decode something a 10MHZ arm processor can decode? Something doesn't seem right...
*
The answer is very simple: different implementations of the same algorithm give different performances and if they are implemented them in different hardware platforms then they are not comparable at all. You can find some info about both implementations here:

ADSP-218x DSP MP3: 36 MIPS solution by Nuntius
ARM7 MP3 Soution by Spirit DSP

Best regards
Oki

edit: links added

This post has been edited by Oki: Aug 22 2005, 23:46
Go to the top of the page
+Quote Post

9 Pages V   1 2 3 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 27th August 2014 - 22:26