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: AAC @ 128kbps listening test discussion (Read 81945 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AAC @ 128kbps listening test discussion

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.

AAC @ 128kbps listening test discussion

Reply #1
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.

AAC @ 128kbps listening test discussion

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

AAC @ 128kbps listening test discussion

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

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


I will give up all this mess and become a hermit

AAC @ 128kbps listening test discussion

Reply #4
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

AAC @ 128kbps listening test discussion

Reply #5
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!

AAC @ 128kbps listening test discussion

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


AAC @ 128kbps listening test discussion

Reply #8
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.

AAC @ 128kbps listening test discussion

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

AAC @ 128kbps listening test discussion

Reply #10
Quote
Quote
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

AAC @ 128kbps listening test discussion

Reply #11
Quote
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


AAC @ 128kbps listening test discussion

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

AAC @ 128kbps listening test discussion

Reply #13
Quote
<scientific graph that proves Blade 128k, indeed, stinks>

Ack.

AAC @ 128kbps listening test discussion

Reply #14
Quote
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
I know, that I know nothing (Socrates)

AAC @ 128kbps listening test discussion

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

AAC @ 128kbps listening test discussion

Reply #16
Quote
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
I know, that I know nothing (Socrates)

AAC @ 128kbps listening test discussion

Reply #17
Quote
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.
Sr. Codec Engineer (video) | RealNetworks Codec Group | helixcommunity.org 
This information is provided "AS IS" with no warranties,  grants no rights, and reflects my personal opinion.

AAC @ 128kbps listening test discussion

Reply #18
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
Allegari nihil et allegatum non probare, paria sunt.

AAC @ 128kbps listening test discussion

Reply #19
Quote
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?

AAC @ 128kbps listening test discussion

Reply #20
Quote
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

AAC @ 128kbps listening test discussion

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

AAC @ 128kbps listening test discussion

Reply #22
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

AAC @ 128kbps listening test discussion

Reply #23
Quote
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!

AAC @ 128kbps listening test discussion

Reply #24
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.
myspace.com/borgei - last.fm/user/borgei