MP3 at 128kbps public listening test - FINISHED Options

[Garf]

Does this mean that in abc/hr when running the testscript for say sample 1, that slider no1 (the leftmost) was Xing? Or am I misunderstanding something?

No, ABC/HR always randomizes the order.

It means that files named "something_1" were the Xing ones. You can use this to look at the comments and relate them to the codec.

[Jan S.]

I was thinking.. maybe AudioActive did this good because it used cbr at a bitrate where it seems vbr (/abr?) normally isn't very good...

Most interesting thing is xing's results though

[rjamorim]

I was thinking.. maybe AudioActive did this good because it used cbr at a bitrate where it seems vbr (/abr?) normally isn't very good...

The issue of VBR being bad at mid-low bitrates only applies to Lame, and maybe Gogo.

[yourtallness]

I'd really like to see how newest Xing does at 192 kbps compared to LAME.

[[proxima]]

The issue of VBR being bad at mid-low bitrates only applies to Lame, and maybe Gogo.

Are we completely sure about this ?
Taking as references ff123's pages i can see different results for Fhg fastenc VBR implementation: with velvet.wav CBR is better, on the contrary, with fatboy.wav VBR wins.
Even in this forum, Fhg Fastenc was considered a good choice for 128 kbps, sometimes better than LAME. Can we extend the test results even for Fastenc CBR ?

[Mac]

Assuming Guruboolez's 3.90.3 vs 3.95.1 results are mirrored elsewhere, what would it take for the new (non 'HA build') to become recommended?

[CiTay]

Where did Xing lowpass? Maybe Xing performs the same or even worse at higher bitrates, because it applies a higher lowpass and people can hear ringing and other artifacts. Xing was never good with HF content...

[Vietwoojagig]

My results are here. Additionnal tests are included :
- 3.90.3
- 3.95.1 -q0

http://membres.lycos.fr/guruboolez/128.htm

Maybe this question is stupid to someone who does more testing than me, but maybe not:

One thing I don't understand with the results of your testing:

If endoder_2 = Lame3.95 and encoder_6 = AudioActive,
why differ the ratings so much between the tests, eg: Audioactive/Sample 11, LAME/Sample 3, 4, 6, 10. LAME/Sample 2 vs Sample 3.

Apart from that, thanks for these kind of testing. Good to know, that there are some people out there, spending there time and ears to make a difference.

Thanks again

[JohnV]

I was thinking.. maybe AudioActive did this good because it used cbr at a bitrate where it seems vbr (/abr?) normally isn't very good...

The issue of VBR being bad at mid-low bitrates only applies to Lame, and maybe Gogo.

My impression has always been that VBR isn't FhG's forte. CBR has always been FhG's strong point especially on lower bitrates.

[JohnV]

Assuming Guruboolez's 3.90.3 vs 3.95.1 results are mirrored elsewhere, what would it take for the new (non 'HA build') to become recommended?

I'm not sure. Much more testing with lots and lots of samples.
Guru's results indicate pretty much tie, so that doesn't help much in this sense. I think Guru's ratings can be often quite temperamentic also, so we need much more results from many samples by many people.

[rjamorim]

I just added the bitrates distribution table to the results page.

[bond]

thanks rjamorim

[QuantumKnot]

Where did Xing lowpass? Maybe Xing performs the same or even worse at higher bitrates, because it applies a higher lowpass and people can hear ringing and other artifacts. Xing was never good with HF content...

From memory, version 1.5 of Xing, by default, has the high frequency switch enabled, so it encodes up to 20 kHz. But if you can hear ringing or twinkling, you can turn it off and it cuts it at around 16 kHz I think.

From the Xing help file

High Frequency Mode when selected, enables encoding of high frequencies (up to 20kHz), for CBR bitrates 112k and VBR settings of Low/Normal and above. Note: Only a small percentage of users have both hardware that can clearly reproduce high frequency sounds and exceptional hearing to distinguish those high frequencies from lower frequencies within the music.

Is Xing still the fastest mp3 encoder in the world now? Or has Gogo or even the nasm-optimised LAME surpassed it?

This post has been edited by QuantumKnot: Feb 7 2004, 02:49

[rjamorim]

Added a note to the results page stressing that the "iTunes" codec being tested is NOT the AAC codec. It seems some pages were confusing this point.

http://mp3.wp.pl/p/informacje/njus/222581.html

(I admit I translated that page with Poltran, so I'm not sure, maybe they didn't confuse codecs at all. Can some Polish speaker help me? What does this mean:

"To dość ciekawy wynik: komercyjny format Advance Audio Coding gorszy jest od tradycyjnego MP3!")

This post has been edited by rjamorim: Feb 7 2004, 07:02

[Dologan]

Heh, the link from your name (with an added A at the end ) in the Polish site you pointed out curiously points to the ReallyRarewares site.

[Feltzkrone]

Regarding my senses I always found when comparing XING to FhG or LAME at 160kbps:
- I could hear more artifacts on XING encoded files at the mid-tones
- I could hear more artifacts on FhG at higher frequencies (hihats, cymbal rides...)

On classical style music I found XING was always performing bad, leaving some very noticeable "short holes" in some mid-tone instruments (128kbps), but I never came across a XING file with disturbed cymbal rides or hihats (unlike FhG).

Generally I find artifacts at high frequencies more disturbing than the ones at the mid-tones, which was some years ago reason for me (apart from the much higher speed) encoding files only with XING instead of FhG. And for 128kbps I would even choose XING nowadays as long as it's not about classical music.

BTW: Which FhG-Codec was used and what options/switches for all encoders were used?

[bond]

maybe it makes sense to list somewhere which codec is used in which prog (ie musicmatch...) cause this would avoid newbies critics that the test is leaving out important codecs and of course it would be also interesting to have such a summary available in the test

[rjamorim]

BTW: Which FhG-Codec was used and what options/switches for all encoders were used?

You can find settings at the presentation page:

http://www.rjamorim.com/test/mp3-128/presentation.html

[Peter]

"To dość ciekawy wynik: komercyjny format Advance Audio Coding gorszy jest od tradycyjnego MP3!")

"It's a quite interesting result: commercial AAC format is worse than traditional MP3!"
It would appear that they think that you tested iTunes AAC encoder instead of iTunes MP3.
[edit]Correction, they originally made that mistake then edited the news post. You must have seen the original version.

[rjamorim]

[edit]Correction, they originally made that mistake then edited the news post. You must have seen the original version.

Yes, I posted there yesterday night clarifying the issue.

Thanks for helping.

[Jojo]

I'd really like to see how newest Xing does at 192 kbps compared to LAME.

me too! It would be nice if LAME 3.90.3 was included as well.

[Feltzkrone]

I guess AudioActive uses FhG ACM Codec (variant?) whereas FhG's Cool Edit / Adobe Audition Plugin uses MP3Enc/FastEnc code. This would at least be the reason for both showing different results.

[sony666]

I'd really like to see how newest Xing does at 192 kbps compared to LAME.

me too! It would be nice if LAME 3.90.3 was included as well.

encode some tracks and compare them, then you know it

[JohnV]

"To dość ciekawy wynik: komercyjny format Advance Audio Coding gorszy jest od tradycyjnego MP3!")

"It's a quite interesting result: commercial AAC format is worse than traditional MP3!"
It would appear that they think that you tested iTunes AAC encoder instead of iTunes MP3.

I knew that people would confuse this, and I warned Roberto earlier.

The best would be if Roberto edits the iTunes specs in the codec presentation page to "Apple iTunes 4.2 MP3 112kbps VBR, Highest quality, joint stereo, smart encoding".

Now the "MP3" is missing from the iTunes specs although it is attached to some of the other specs and seems even some web sites can become confused, which is definitely not good..

[JohnV]

Btw. I don't want to start defending iTunes MP3 or anything, but did the 128 VBR settings really give so high average bitrates for it that it couldn't be considered and you had to go for 112?
Now in this test not even one sample reached 128kbps with iTunes, highest it reached was 126kbps, which I find a bit troublesome considering the test..

I wonder what the result would have been if iTunes 128 vbr had been chosen, which no doubt masses would choose if they want to encode iTunes vbr mp3 near 128kbps.


PS. sorry for all this bitching, Roberto... You do generally good and unique job here, and I appreciate that.