AAC @ 128kbps listening test discussion Options

[rjamorim]

Hello.

I'm creating this thread so that we can discuss how the upcoming AAC @ 128kbps listening test will be handled.

The encoders I plan to feature are:

-Nero AAC encoder VBR profile Streaming :: Medium (@Ivan: Fast or HQ mode?)
-Apple iTunes 4.2 128kbps
-FAAC "whatever VBR setting comes close to 128kbps"
-Compaact! "same thing as above"
-Winamp AAC encoder 128kbps
-FhG l3enc 1.0 as anchor

Some codecs that might be considered to replace another:
-Real Producer
-NCTU AAC
-Emuzed
-Imagine Technology


I am personally very fond of the idea of using l3enc as anchor. It'll be a good insight on how perceptual audio coding developed since the first MP3 implementation. It'll be like "the oldest vs. the newest".

Of course, as usual, EVERYTHING is still open to discussion. Remember I am conducing these tests for you, not for me, so please make your opinions heard.

Actually, only one thing is not open for discussion: the amount of codecs. There won't be more than 6 (including anchor), no matter what.

Some other topics I want to discuss:

-Samples tested. IMO we should definitely replace some samples. Specifically Polonaise (I would suggest Fossiles as replacement) and Illinois (I would replace it with our old friend Fatboy). Do you believe something else should be replaced?

I wouldn't like to replace Waiting. I love that sample for it's wacky behaviour, so I want to force you guys to listen to it over and over again until your ears pop out of your skull :B


-Should only LC be tested? Or maybe test other (better?) profiles when the encoder supports them, like FAAC and Compaact. I think an argument for this would be that it's like VBR vs. CBR - you shouldn't penalize some codecs because others lack that feature. A very good argument against this would be that LC is waaaay more supported now and probably in the future. Opinions?


-Do you think there is any need for encryption (it will definitely be used on the Multiformat tests)? If so, we'll only use Schnofler's comparator, since ff123's doesn't support encryption.


These are the subjects I can think about ATM. I'll post more ideas/questions as I come up with them.

Thanks for your help.

Best regards;

Roberto.

This post has been edited by rjamorim: Feb 8 2004, 01:18

[Bonzi]

Well, isn't winamp AAC practically the same thing as quicktime AAC except an older version? I would be in favour of NCTU AACenc instead if this is the case. It would be interesting to see how it would fare in comparison to other codecs which rely less on ODG and other objective measures in development.

[schnofler]

Well, I am personally very fond of the idea of using l3enc as anchor. It'll be a good insight on how perceptual audio coding developed since the first MP3 implementation. It'll be like "the oldest vs. the newest".

Yeah, but what will you say when it comes in third?

P.S.: Come on, somebody had to say it.

[rjamorim]

It would be interesting to see how it would fare in comparison to other codecs which rely less on ODG and other objective measures in development.

That is a very good point, indeed.

Yeah, but what will you say when it comes in third?

I will give up all this mess and become a hermit

This post has been edited by rjamorim: Feb 8 2004, 01:20

[sony666]

6 encoders is the absolute maximum imho, I'd rather drop the anchor to be honest.

128kbit AAC will likely be even harder than the mp3 test, and listening gets a little tedious after the 3rd or 4th sample, so adding exotics like NCTU is a big nono

[guest0101]

I would like to see you keep the WinAmp encoder due to its widespread use among users. Would be nice to know how well it encodes. Also I would like to know of Imagine Technology's codec as I use that with their Cool Edit Pro/Adobe Audition plug-in. Thanks rjamorim for all the kind advice your post on HA. You're very helpful!

[rjamorim]

6 encoders is the absolute maximum imho, I'd rather drop the anchor to be honest.

No, there must be a bottom anchor. It doesn't have to be l3enc, but it's a good way to keep things in perspective.

[harashin]

How about VQF as anchor? According to AudioCodingWiki , it is(was?) a part of MPEG-4 Audio version 1.

[Cygnus X1]

Re: the profile issue: I'd say just stick with the LC profile, for the simple fact that I'm not personally aware of any hardware player that can handle higher profiles like Main. Plus, I also question whether using the more complex profiles drastically improves sound quality (i.e., a statistically significant improvement over LC). I haven't seen any data comparing the different profiles of popular encoders (FAAC, Nero, Dolby, et al), so while higher profiles should sound better in theory, to what extent (if any) has yet to be studied.

[rjamorim]

How about VQF as anchor? According to AudioCodingWiki , it is(was?) a part of MPEG-4 Audio version 1.

Actually, TwinVQ is part of MPEG4 audio. It's slightly different from VQF, and in MPEG4 audio it's limited to veeeery low bitrates - around 8-16kbps

That said, I was planning to use it as an anchor in the multiformat test that will come after the AAC test.

[sony666]

6 encoders is the absolute maximum imho, I'd rather drop the anchor to be honest.

No, there must be a bottom anchor. It doesn't have to be l3enc, but it's a good way to keep things in perspective.

I trust in your greater wisdom
Also, thank you for going through the trouble once again.

For the anchor, FhG 1.0 would surely be funny, but I persoanlly would prefer something that is used more widely in old files and has a bad name to it. (hint: Blade 128k) Maybe it is not so bad as many ppl like to call it?

For the profile, only plain LC please

For samples: I would surely like to see "mybloodrusts" and "daFunk" from the mp3 test

[rjamorim]

but I persoanlly would prefer something that is used more widely in old files and has a bad name to it. (hint: Blade 128k)

I already ruined Blade's reputation


(First multiformat @ 128kbps test)

Maybe it is not so bad as many ppl like to call it?

I wouldn't think so...

[harashin]

Actually, TwinVQ is part of MPEG4 audio. It's slightly different from VQF, and in MPEG4 audio it's limited to veeeery low bitrates - around 8-16kbps

That said, I was planning to use it as an anchor in the multiformat test that will come after the AAC test.

Oh. Thanks for the clarification.

[sony666]

<scientific graph that proves Blade 128k, indeed, stinks>

Ack.

[bond]

Actually, only one thing is not open for discussion: the amount of codecs. There won't be more than 6 (including anchor), no matter what.

dont get that...
one codec more would make sense to me!

and i would choose real for this extra codec, as i dont like their 192kbps is better than 128kbps marketing blabla...
first of all i want to know how their codec does compared to itunes

[rjamorim]

dont get that...
one codec more would make sense to me!   

I guess you have no idea the utter pain in testing several (6+) encoders, most of them getting pretty close to transparency :B

hehe

BTW, I would expect Real to be similar to Winamp.

[bond]

I guess you have no idea the utter pain in testing several (6+) encoders, most of them getting pretty close to transparency

well as i attended every test till now, also the first one, i think i have a small idea of what this means

but when it will be finished i think most will say "it was worth it"

anyways you said the codec amount is not to be discussed and i respect this
and i also dont want that real with its .ra sh*t gets popular

[karl_lillevold]

i also dont want that real with its .ra sh*t gets popular

RM is just another container format, playable in many players these days, but I have already mentioned that AAC wrapped in RM is just a temporary solution. Our alternative file writers were not ready in time for Beta. RealPlayer 10 Gold and RealProducer (Helix Producer) 10 Gold will write AAC to another format...

The Real (HE-)AAC encoder was licensed from Coding Technologies, is the only HE capable encoder in addition to Nero (CT did invent aacPlus/HE by the way), and their AAC base encoder probably started out from a similar codebase as the FhG AAC encoder. Personally I would be very curious how it compares to the rest of the AAC encoders out there. "Installing" Helix Producer is as simple as unzipping the files, and if included in the test, I will make sure Roberto has no trouble whatsoever with the encoding or installation (don't want to repeat trying to install RealPlayer.. ), as well as losslessly convert the .ra files to whichever format is preferred, .aac, or .m4a.

As a sidenote, I think it is a good idea to be very clear about which is the actual codec provider, for example for WinAmp, who did they license the encoder from? For Real, like I mentioned, this would be Coding Technologies.

[ssjkakaroto]

e ai Roberto

would it make any sense using LAME instead of FhG l3enc? that way we could see how much better (if better at all ) AAC is when compared with the best MP3 encoder
I wouldn't be surprised at all if it came out in first

[rjamorim]

As a sidenote, I think it is a good idea to be very clear about which is the actual codec provider, for example for WinAmp, who did they license the encoder from? For Real, like I mentioned, this would be Coding Technologies.

Nullsoft (AOL actually) licensed from Dolby.

CodingTechnologies licensed their base AAC encoder from FhG (FhG consumer AAC encoder, actually)

FhG and Dolby share a lot of codebase, according to an AAC developer.

That's why I guess they would be similar

Maybe I should start a poll with AAC codec options? What do you think?

[rjamorim]

would it make any sense using LAME instead of FhG l3enc? that way we could see how much better (if better at all ) AAC is when compared with the best MP3 encoder
I wouldn't be surprised at all if it came out in first

Dude, you pointed out the exact problem in your suggestion. How can I use an anchor that might even surpass some of the actual competitors? :B

[kwanbis]

would it make any sense using LAME instead of FhG l3enc? that way we could see how much better (if better at all ) AAC is when compared with the best MP3 encoder
I wouldn't be surprised at all if it came out in first

Dude, you pointed out the exact problem in your suggestion. How can I use an anchor that might even surpass some of the actual competitors? :B

well ... you mean it to be an anchor ... but what happened to xing? ... i second the opinion of using LAME ...

[guest0101]

Well I think Apple iTunes (Quicktime 6.5) and Nero 6 should be in for sure since they are 2 quite different codecs and 2 of the most popular AAC encoder apps. Apple is based on Dolby Consumer I believe with heavy tweaking and Nero is heavily tweaked and is based on the Coding Technoligies codec I believe. I thought WinAmp would make a good baseline Dolby Consumer (without tweaking) comparison against the iTunes/Quicktime 6.5 encoder.

That would take care of 3 of your 6 choices in my opinion.

RealNetworks would be nice, to see a mostly untweaked Coding Technologies codec compared against Nero (heavily tweaked) one. Hopefully RealPlayer 10 will play .m4a and .mp4 (including HE AAC) natively when it gets out of beta

This post has been edited by guest0101: Feb 8 2004, 04:28

[rjamorim]

well ... you mean it to be an anchor ... but what happened to xing? ...

Blah!!!

Please consider all the bad comments on Xing done here and elsewhere over the years, and then come tell me I did a bad choice!

[bidz]

No more than 6 codecs, as 6 is already enough. I also second the latest LAME version for anchor. Atleast keep iTunes, Nero and Winamp in the test, as these are the most widespread codecs. RA's AAC codec might also be more spread than some of the others (NCTU, etc) once it's out of beta, so i'd probably want to include that one also, even though all these codecs may be based on the same codebase - optimizations might be different.