I also think that the commercial CT encoder should be different from the 3gpp reference code, because there is no tonality estimation in the 3gpp code.

It would be a little strange for CT to not have any tonality estimation in its commercial encoder.

Are you sure?
As I look at the 3GPP TS 26.404 and the source code also, I see "the tonality is derived from the prediction gain of a second order linear prediction...", etc. etc. As a matter of fact, without tonality detection most other modules would be seriously crippled, namely noise estimation, sines detection and inverse filtering, which would probably make this encoder useless - and it isn't useless at all.

This is for the SBR part, not the base part.

From 26.403 (AAC part):

Sorry, didn't look at the core AAC.

Now that we know the core AAC is crippled (which makes whole 3GPP encoder crippled), it would be ok to know if SBR part is fully functional...

Most importantly, I'd like to know if one will have to install the whole new Nero 7 just to use the improved AAC+ for which Ivan Dimkovic has been providing drumrolls. ( I'm darkly suspicious of any software that's compatible with Blu-Ray.)
I had wondered why some of the top posters have been quiet in encoding quality disccussion/debate, but it seems they must have been gagged by beta tester non-disclosure agreements.
I also am wondering how the proprietary elements that Coding Technologies and Ahead put into their encoder applications will affect willingness of hardware manufacturers to create portable devices that can play the files. If the iPod Nano could play the files, I'd surely have bought one right away, since one could get not far shy of 200 hours good quality music on the 4Gb model.

SBR and PS are not proprietary elements, just plain mpeg-4 standard.

guruboolez
Can you add this encoder for comparision @ 48000Hz?

Hmm I wouldn't be that surprised - I think Dolby's AAC encoder described in their AES paper didn't use tonality esitmation as well, and I know for a fact that couple of other commercial LC-AAC encoders do not use tonality estimation I cannot reveal names, of course Not having a tonality estimation might not be so problematic especially at the very low bit rate CBR - where maintaining stable NMR and avoiding spectral holes is much more important than avoiding artifacts of a problematic harmonic structures (hello pitchpipe) - and for high bitrates, you could overcode anyway (like Dolby is doing in A52 specification, or as described in fast AAC AES paper).

Also, 3GPP reference code obviously misses some things from what I saw, for example TNS encoding, uses fixed multiplication of the post-TNS thresholds (factor 0.25), while in the specs it is clearly called "a table" - and, well, some more.

Also - quality difference clips between CT (commercial) and 3GPP - just try Waiting.wav @48 kbps, 48 khz with CT encoder and 3GPP reference source (I am talking about HE-AAC , not v2 with PS) - and check the amount of stereo reduction (which is being done to improve the LC SNR on the expense of stereo image) - while 3GPP code almost completely downmixes LC part to mono - CT maintains better spatial image (not perfect, though, but much better) - which means it had more SNR available so it didn't need to reduce stereo image that much (or the 3GPP reference code algo is broken).

There are many more - i.e. with castanets.wav you can clearly hear typical short block distortions @48 kbps (HE, too) at the end of the "fast" castanets clip - while they are not there with CT's commercial encoder, etc.. etc...



Unfortunately, I cannot tell you that. What is sure, at the moment, the new encoder will be available with N7 web release - and about its future and possible other applications, no more public info is available at this moment.



You can be pretty sure that HE-AAC encoders (at least for Nero I can be 101% sure, and for CT I have no reason to doubt it is also the case) do not put anything proprietary in the elementary bitstream - which is what it is needed to be decoded by the ISO decoders ;-) There are proprietary algorithms, of course - but all of them produce standard compatible MPEG-4 streams.

Where from to download program "Helix Producer v11" ? Because I on net nowhere can find this version...

https://helixcommunity.org/beula/download/

registration needed but it's free.

Nice work guruboolez . Cheers

could we put helix encoder on rarewares ?

You can't redistribute helix aac codec anyway so you will have to register to download.

I didn't find a bitrate (or final size) table. I noticed that Helix produce slighlty bigger files than other encoders. For some people it's not important the difference on some kilobytes. But I work with limited space of memory. Especially for encodes for audiotrack of home videos file to fit one CD for example

All encodings were done in CBR mode. Size is approximately the same for both implementation (if not, the MP4 container could be optimized in order to reduce the difference: a tool like foobar2000 can do it).

All files are deleted; I can't therefore post the bitrate table (useless in this case I'd say).
Cheers.

Hi, every one. Just to say that MediaCoder now natively supports 3gpp AAC+ encoder (supports 44.1Khz). There is a little bit performance gain after I optimized the compiler options (enabled SIMD).

How could you test the CT encoder?
did you bought the SDK?

You can get the CT encoder on Winamp, Real Player, etc, etc.