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 82099 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AAC @ 128kbps listening test discussion

Reply #75
Quote
Well, I see there is too much discussion about what codecs to support and what anchor to use. I think the best and most fair way to settle the issues is creating a poll.
(...)
Do you agree?

Yes, absolutely.
I think this would be the best way to settle this issue.

But I think that everybody agrees on the 3 codecs you mention, so why don't you have a list with only the remaining codecs. Let every one vote and select the three with the most votes.
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

AAC @ 128kbps listening test discussion

Reply #76
Quote
Let every one vote and select the three with the most votes.

Two, actually
(The anchor would be handled in another poll)

I think that might work too, although that would limit votes to one per person, and the ideal would be two. Ideas, comments?

AAC @ 128kbps listening test discussion

Reply #77
Hmm?
Two separate polls?
Monday through wednesday, choice of first contender.
Separate poll, thursday through saturday, remaining candidates minus first poll winner.

It's the only thing that comes to my mind right now.
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

AAC @ 128kbps listening test discussion

Reply #78
that's a good idea, having a separate poll for the anchor i think it's the best choice right now

after reading this thread i've been convinced that LAME would not be a good anchor, now my vote would go for iTunes since it had the lowest score in the last test
Allegari nihil et allegatum non probare, paria sunt.

AAC @ 128kbps listening test discussion

Reply #79
go for the polls separated by time.

please just pick an anchor. it doesn't really matter as long as it sucks. it isn't in there to compare to the other codecs, its there to lose, and keep the other ratings up.

AAC @ 128kbps listening test discussion

Reply #80
My vote is to use the old FAAC as the anchor.  After all, this test is about AAC.


AAC @ 128kbps listening test discussion

Reply #82
What about the Homeboy AAC encoder as an anchor? Wasn't it really bad?

AAC @ 128kbps listening test discussion

Reply #83
Regarding Nero AAC - Fast mode shouldn't be used, as it is still not tuned.

AAC @ 128kbps listening test discussion

Reply #84
Quote
Besides, what's wrong with using Lame in many tests? It allows (to an admittedly small amount) inter-test comparability (Another meaning of the word anchor?), while FhG l3enc 1.0 will only make the used rating range smaller.

I like the idea.
Using a stable high quality encoder as an anchor could indeed allow some inter-test comparison and IMO such kind of anchor would be much more valuable than any low quality old encoder. An ancient encoder is just a waste of listening slot.


Quote
Let's be realistic: If Lame is included, it won't be an anchor. It will just be another competitor. An MP3 competitor in an AAC test. You probably notice the mess here...

How can you know LAME won't lose? IMHO LAME at a last place is a realistic scenario.
I really think comparing the best MP3 to the worst AAC encoder would be fascinating and I can't see any mess here.

AAC @ 128kbps listening test discussion

Reply #85
EDIT: Winamp problem is a decoder-only problem. Nothing seems wrong with the encoder.

EDIT: Hmm, actually I can't be sure if this is an encoder problem too. I guess some testing should be done whether a Winamp file decoded with Winamp sounds better then with another decoder. The difference between 2 decoded samples (winamp decoder versus another) is quite difficult to hear, but in a test like this it will probably be noticed.

Besides this, I think NCTU-AAC should be added to the test, just to show how much it sucks. As low anchor also the new Adobe Audition filter could be used.

Menno

 

AAC @ 128kbps listening test discussion

Reply #86
If everyone knows that NCTU-AAC sucks badly may be it could be used as anchor? Just a thought.

-Eugene
The  greatest  programming  project of all took six days;  on the seventh  day  the  programmer  rested.  We've been trying to debug the !@#$%&* thing ever since. Moral: design before you implement.

AAC @ 128kbps listening test discussion

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

VQF ran at around 80-96kbps. i should know, i was the one that was so happy about it intially (with my 128kbps mp3 vs 96kbps vqf) i spammed the mp3 newsgroups and mp3.d newsgroup about it when i first started playing with it. (i wouldn't even touch it now, altho i think it's in my audio tools collection somewhere X)

can't find it or anything else that's helpful .. seems to have fallen off google 

oh, here we go.. here's one at least... http://www.mp3-tech.org/tests/pm/VQF-96k.htm

AAC @ 128kbps listening test discussion

Reply #88
Quote
Besides this, I think NCTU-AAC should be added to the test, just to show how much it sucks. As low anchor also the new Adobe Audition filter could be used.

A question comes to mind: Is NCTU AAC bad enough to be used as low anchor?

AAC @ 128kbps listening test discussion

Reply #89
Quote
But if, say, Lame finishes last in both the AAC test and the multiformat test (excluding anchors, the latter is to be expected), you will only provoke senseless claims like "Vorbis finished 1.2 points ahead of Lame in the multiformat test, but FAAC only managed an advantage of 0.9 in the AAC test, so Vorbis must be better than FAAC".

Well, such claim is better than pure guess when you can't compare faac to vorbis directly.

AAC @ 128kbps listening test discussion

Reply #90
@ Menno: Thanks for bringing this issue to our attention.

Discussion here:
http://www.hydrogenaudio.org/forums/index....ndpost&p=182562

About anchors: I'm taking note of all your suggestions, and will later create a poll so that people can vote on what they prefer. Thank-you.

AAC @ 128kbps listening test discussion

Reply #91
rjamorim: Are you going to use VBR streaming profile with Nero? I have done some encoding with it, and the average bitrate is too high for this "128kbps" test. VBR Internet profile produces closer to 128kbps on average.

I think that more encoders should be included or the anchor should be replaced with some AAC encoder. As i did the MP3 test, the anchor was useless to me, and this time it make out quite well against some other encoders.

AAC @ 128kbps listening test discussion

Reply #92
Quote
I think that more encoders should be included or the anchor should be replaced with some AAC encoder. As i did the MP3 test, the anchor was useless to me, and this time it make out quite well against some other encoders.

Seconded. Same here.
Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello

AAC @ 128kbps listening test discussion

Reply #93
Quote
Quote
I think that more encoders should be included or the anchor should be replaced with some AAC encoder. As i did the MP3 test, the anchor was useless to me, and this time it make out quite well against some other encoders.

Seconded. Same here.

I personally would prefer that fewer codecs be tested rather than more.  If an anchor is used it should sound bad, IMO.  Otherwise, I think it's better to just drop it.  Especially on a test in which all the codecs should approach transparency.  6 codecs was almost too much for me in the mp3 test.

ff123

AAC @ 128kbps listening test discussion

Reply #94
Evil Psytel as anchor. 

AAC @ 128kbps listening test discussion

Reply #95
OK, now a fucker decided to mess my poll.

My patience is growing too thin, so I'll tell you what I plan to do:

-Compaact and Real are in
-Winamp is out because it seems to be broken, so it would be unfair to test it now.
-NCTU is in as an anchor.
-The test will be encrypted and will require Java ABC-HR.

Flames? Opinions? Comments?

BTW: Everything is discusseable, except encryption. It is definitely going to happen.

Regards;

Roberto.

AAC @ 128kbps listening test discussion

Reply #96
It may sound a bit unfair to newer members, but to remove any doubts about manipulating the result in favour of compaact!, I suggest to only take hydrogenaudio members into account, that were members *before* the release of compaact!, i.e. end of october 03.

If the participation at the listening test would be without restriction, and compaact! would rate good, nobody would believe it now anyway.

Alexander

AAC @ 128kbps listening test discussion

Reply #97
*deleted*

AAC @ 128kbps listening test discussion

Reply #98
Quote
-The test will be encrypted and will require Java ABC-HR.

How strong this encryption is? What crypto system it uses?
Juha Laaksonheimo

AAC @ 128kbps listening test discussion

Reply #99
Quote
If the participation at the listening test would be without restriction, and compaact! would rate good, nobody would believe it now anyway.

Ph34r my m4d scr33ning skillz!