Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: HE-AAC v.1 & v.2 comparison (Read 89454 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

HE-AAC v.1 & v.2 comparison

Reply #50 –
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.

HE-AAC v.1 & v.2 comparison

Reply #51 –
Quote
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.
[a href="index.php?act=findpost&pid=326781"][{POST_SNAPBACK}][/a]

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.

HE-AAC v.1 & v.2 comparison

Reply #52 –
Quote
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.

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

From 26.403 (AAC part):
Quote
No difference is made between tonal and noisy components in the signal. Therefore the "worst case" is assumed, i.e. the signal is tonal for the complete frequency range.
 

HE-AAC v.1 & v.2 comparison

Reply #53 –
Quote
Quote
No difference is made between tonal and noisy components in the signal. Therefore the "worst case" is assumed, i.e. the signal is tonal for the complete frequency range.


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...

HE-AAC v.1 & v.2 comparison

Reply #54 –
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.

HE-AAC v.1 & v.2 comparison

Reply #55 –
Quote
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.

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

HE-AAC v.1 & v.2 comparison

Reply #56 –
guruboolez
Can you add this encoder for comparision @ 48000Hz?

HE-AAC v.1 & v.2 comparison

Reply #57 –
Quote
Gabriel
It would be a little strange for CT to not have any tonality estimation in its commercial encoder.


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...

Quote
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.)


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.

Quote
ckjnigel
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.


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.

HE-AAC v.1 & v.2 comparison

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

HE-AAC v.1 & v.2 comparison

Reply #60 –
Nice work guruboolez . Cheers
An eye for eye will make the whole world blind

HE-AAC v.1 & v.2 comparison

Reply #61 –
could we put helix encoder on rarewares ?
Sven Bent - Denmark

HE-AAC v.1 & v.2 comparison

Reply #62 –
Quote
could we put helix encoder on rarewares ?
[a href="index.php?act=findpost&pid=337659"][{POST_SNAPBACK}][/a]


You can't redistribute helix aac codec anyway so you will have to register to download.
An eye for eye will make the whole world blind

HE-AAC v.1 & v.2 comparison

Reply #63 –
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

HE-AAC v.1 & v.2 comparison

Reply #64 –
Quote
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
[a href="index.php?act=findpost&pid=337863"][{POST_SNAPBACK}][/a]

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.

HE-AAC v.1 & v.2 comparison

Reply #65 –
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).

HE-AAC v.1 & v.2 comparison

Reply #66 –
How could you test the CT encoder?
did you bought the SDK?