NCTU AAC encoder, never heard of it, but here it is ... Options

[SebastianG]

Website

Well, first the graphs/quality seemed to be promising.
The I realized the term "objective tests" and really weird LAME settings


I'll give it a try...


Sebastian

[kurtnoise]

Yeah...but the last version is the 1.0 GM


Another thread about NTCU AAC in HA...

[SebastianG]

Thanks for the link.
Sorry for bringing this up again.

Sebastian

[Selur]

since the final wasn't out in the other thread,...

did anyone test the new version (final) an can say if it's good/worth using/better than... ?

Cu Selur

[JohnV]

My first impressions on default settings for 128kbps is that it's not very high quality (surprise surprise). But I'm not sure if they used the default settings on their (PEAQ) tests or not.
I'm asking on their forum which settings they used for their tests with their encoder, then I can comment more.

[JohnV]

OK, NCTU claims here, that their new 1.0 encoder is better than QT and Nero, based on PEAQ-basic odg value software measurements with 12(?) samples.

Here's some real life proof that NCTU is not that good as they claim, and it would be probably ranked lower than QT and Nero in real life 128kbps group listening test.

This is the first 10 sample package which shows clearly worse problems with NCTU 1.0 than than with QT and Nero encoded equivalents. Judge for yourself if their claims of being the best AAC encoder can be true...
Encoders used were latest QT and Nero with default 128kbps cbr settings, and NCTU-AAC 1.0 GM with settings used in their odg measurements for 128kbps.

http://www.hydrogenaudio.org/stuff/PackageA.zip (8 MB)
http://www.hydrogenaudio.org/stuff/PackageA_Originals.zip (18.5 MB)

I'll post more samples soon for further proof.

[[proxima]]

I just tested NCTU with the samples JohnV gently provided and i'm really surprised for the very bad quality of NCTU encoder. ALL samples have inacceptable, obvious ringing artfifacts.
Scores for Nero and QT are probably a bit bloated... NCTU is maybe good for a low anchor

CODE

                   NCTU      QT     Nero

41_30sec           1.0      3.0     4.0
cymbals            1.0      4.0     3.8
PinkFloydTime      2.0      4.0     4.5
Scars              1.0      4.8     4.5
SmashingSample     1.5      4.7     3.8
taking_you_home    1.0      4.7     4.2
test_4_artifacts   1.0      4.5     2.7
trust              1.5      3.5     2.5
Velvet             1.0      3.5     2.0
youwalkaway        1.0      3.5     4.0

ABC/HR logs here: http://xoomer.virgilio.it/fofobella/nctu_aac_10GM.zip

Since the beginning the NCTU team based the supposed quality of the encoder ONLY with ODG values, in their forums i can see lots of posts (mainly by JohnV) about the need of conducting subjective listening tests but these people still continue to cheat with their tests. I'm wondering if they ever listened the results of their encoder with some samples
That said, i don't need to test more samples, i'm really disappointed.

[Gabriel]

ALL samples have inacceptable, obvious ringing artfifacts.

That is what happens when you:
*use a lowpass as high as 21kHz when targetting 128kbps
*do not use any ath by default

http://psplab.csie.nctu.edu.tw/projects/in...ac-command.html

But on the other hand, it is a good strategy when mainly targeting ODG scores.

I guess that the encoder would be better with
-ATHMode 1 -ATHoffset 80 -ATH 3 -c 16000

[dev0]

Are they still blatantly violating the GPL?
Or did they actually write a new encoder from scratch?

[rjamorim]

Are they still blatantly violating the GPL?
Or did they actually write a new encoder from scratch?

It was the LGPL.

And they claim the new encoder is written from scratch. If it's not, a binary analysis would probably denounce it.

[[proxima]]

I guess that the encoder would be better with
-ATHMode 1 -ATHoffset 80 -ATH 3 -c 16000

Thanks for your explaination.
I tried to test the encoder with the setting you proposed but unfortunately advanced options like -ATHMode doesn't work for me (unrecognized option).

This post has been edited by [proxima]: Aug 19 2004, 20:07

[Ivan Dimkovic]

What's really surprising is how they managed to get so high ODG - like they tweaked all of the code for the ODG scoring of the samples they use on the webpage

Also it is very strange to see how ODG differs so much from the real listening in their case - I am puzzled.

This post has been edited by Ivan Dimkovic: Aug 19 2004, 20:51

[Gabriel]

We could perhaps organize an ODG competition?

For Lame I'd suggest -k --noshort.

Regarding AAC, unfortunately for Ivan I think that Apple has won, as they have some positive ODG.

[cmliu]

Here's some real life proof that NCTU is not that good as they claim

No encoder can win in every track. PSPLab has collected about 300 tracks as the development reference. http://psplab.csie.nctu.edu.tw/projects/in...bitstreams.html

There are various test sets that will be used as the daily test to help developers confirm the convergence of the newly checkin codes or algorithms. Also, the webserver has included a test set referred to as the ff123 which is the most critical tracks for NCTU-AAC.
http://ff123.net/samples.html
These tracks are classed as "the tough tracks" during our development process. Some of the tracks you mentioned can be found in the set.

I guess that the encoder would be better with
-ATHMode 1 -ATHoffset 80 -ATH 3 -c 16000

and

ALL samples have inacceptable, obvious ringing artfifacts.

It maybe a good policy to cut all the frequency above 16k to avoid the ringing effect (or generally referred to as the birdie effect). However, a good encoder should automatically detect the risks and tune the frequency range. Till now, NCTU-AAC are trying the automatic approach. The ATH or the cutoff frequency options are block out in the release. NCTU-AAC would prefer to adjust the perceptual models to avoid the ringing effect.

What's really surprising is how they managed to get so high ODG

The methods used is just to remove the percetual artifacts audible by ears and confirmed through ODG score. The technical contents in the NCTU-AAC will be published through three technical papers in AES 117 Convention, held in San Francisco, CA, USA.

[JohnV]

Here's some real life proof that NCTU is not that good as they claim

No encoder can win in every track. PSPLab has collected about 300 tracks as the development reference. http://psplab.csie.nctu.edu.tw/projects/in...bitstreams.html

You don't have to tell me that no encoder can win in every track.. But this is not about winning or losing. This is about very serious artifacting which simply can't be there in _any_ encoder which claims to be top quality at 128kbps. That said I almost forgot to post another set of samples, will be online soon..

I happen to have also several hundreds of test samples, but if you don't use them properly, they are no good...

[Ivan Dimkovic]

Dear NCTU team,

The point here is - that no good AAC encoder could have bad artifacting @128 kbit/s. Period. Neither QT nor FhG nor Nero AAC do have bad artifacting for majority of the clips at this bit rate.

On the other hand, your encoder managed to have some pretty nasty artifacts on a whole range of casual music clips (no killer tracks, just normal music) which is a clear sign for problems that need to be fixed in your coding system, and also a clear sign that these issues would propagate to a wide range of music items.

We all (people involved in codec development) had been there once - it took more than two years for myself to get rid of nasty artifacts even when the entire psychoacoustic and bit allocation model were written and worked perfectly on paper and simulation, approx the same amount of time was needed by the LAME team to make their encoder good enough as well - please make sure you actually do listen to the stuff you produce.

This post has been edited by Ivan Dimkovic: Aug 23 2004, 22:41

[JohnV]

Ok, here's another set of 10 samples where NCTU-AAC doesn't actually perform like the "best" AAC encoder should..
Picked quickly but there's some interesting artifacting like stereo image fluctuation with gekkou-intro.wav etc.

http://www.hydrogenaudio.org/stuff/PackageB.zip (9 MB)
http://www.hydrogenaudio.org/stuff/PackageB_Originals.zip (21 MB)

[wkwai]

We all (people involved in codec development) had been there once - it took more than two years for myself to get rid of nasty artifacts

I quite agree with you.. As far as I remember it.. development on an encoder as complex as the AAC usually required a few people working closely together..
If you work alone like I am now... it would require a few years to get satisfactory quality..

It gets worse, if you are trying to develop an embedded version of the encoder on specific processor platforms..


wkwai