QUOTE(Ivan Dimkovic @ Oct 23 2002 - 09:44 AM)
AAC+ could theoretically use both AAC and AAC LD as the "core" bitstream. But for the consumer and high-quality applications AAC is the default. Only place where LD would be a better solution is the two-way hardware codec for live conversation.
(taken from "ISO/IEC - Workplan for MPEG-4 Audio Extension 1 Core Experiments" from March 2002, so it may be outdated already):--------------------------------------------------------------------------------
3.2.2 Core Experiments
[...]
With respect to potential CEs targeting at low delay functionality, the following principles are to be followed:
* All developments must be extensions of the current RMx BWE tool.
* AAC-LD must be used as the base coder.
* The performance targets agreed upon for the BWE work item apply, that is the coder/BWE system must perform at least as good as the coder without BWE at a 25% higher bitrate. Due to the difference in efficiency between AAC and AAC-LD, this translates into a comparison between AAC-LD/BWE at 32 kbps/ch and AAC-LD at 40 kbps/ch.
* Proposals for LD strongly deviating from RMx need to be significantly better than LD proposals more closely related to RMx to justify their existence.
--------------------------------------------------------------------------------
So this could also mean that they only wanted to simplify the development of AAC+ with LD functionality and not limit the use of SBR to Low Delay implementations of AAC - which I would prefer too, of course...

QUOTE
At 44.1 kHz stereo, minimum (meaningful) bit rate for AAC+ is 32 kbps - can be lower for other sampling rates.
By the way, where would you state the minimum meaningful bitrate for PsyTEL AACEnc?

I'm asking this, because I have spent the last few weeks trying to come close to the sound of the FhG AAC (evaluation build from August, 23th) that was used in the recent c't listening test at 64 kbps. In my mind (or ears) PsyTEL has to use some more bits than 64 kbps (15-20%) to compete with FhG, WMA9 or mp3PRO at that bitrate. So the best command line I could come up with was -radio -resample 32000, which resulted in 73 kbps with the c't reference.wav.
QUOTE
QUOTE
Is the AAC + SBR decoder easily implemented on a DSP / microProcessor that does not have a floating point unit?
I would have to look at the specs for this - I suppose it could be implemented much easier than AAC encoder

I should have cited this paragraph from the same document before (where I also found the table with the CPU MIPS):
--------------------------------------------------------------------------------
Decoder complexity of Coding Technologies RM0 proposal for bandwidth extension (SBR). The numbers given below are based on an actual
24 bit fix-point DSP implementation for MPEG-2 AAC LC and MPEG-2 AAC LC+SBR. They are given for information purpose and
might differ for other implementations.QUOTE
QUOTE
2.will aac+ offer any low-complexity stereo support such as mp3PRO?
SBR extension does not care if the baseline stream has intensity stereo, PNS or any other tool - I am personally against Intensity Stereo, and I also think that PNS is useless in combination with SBR.
Yes, I remember your rant in alt.music.mp3 about the different stereo methods in AAC.

But of course I couldn't help to try out intensity stereo with your encoder in my listening tests and found absolutely no difference at these low bitrates (this could be related to the lack of a superb stereo image in the reference file). Does the -is switch work at all or is it disabled in the code? The display at least told me that I would be using intensity stereo then...
QUOTE
QUOTE
3.tell us more tell us more
Unfortunately, I can't

Except that I am impressed with the quality so far

It is still really too early to talk about AAC+ as a consumer encoder - other than technical things.
The best place to look for important new informations probably is the official website of the MPEG Audio Subgroup that also lists all recent press releases. So maybe there is already one from the last meeting on October, 21th in Shanghai:
http://www.tnt.uni-hannover.de/project/mpe...g/audio/public/