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: MP3 at 128kbps public listening test - FINISHED (Read 52894 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 at 128kbps public listening test - FINISHED

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

MP3 at 128kbps public listening test - FINISHED

Reply #51 –
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 

MP3 at 128kbps public listening test - FINISHED

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

MP3 at 128kbps public listening test - FINISHED

Reply #53 –
I'd really like to see how newest Xing does at 192 kbps compared to LAME.
Wanna buy a monkey?

MP3 at 128kbps public listening test - FINISHED

Reply #54 –
Quote
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 ?
WavPack 4.3 -mfx5
LAME 3.97 -V5 --vbr-new --athaa-sensitivity 1

MP3 at 128kbps public listening test - FINISHED

Reply #55 –
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?
< w o g o n e . c o m / l o l >

MP3 at 128kbps public listening test - FINISHED

Reply #56 –
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...

MP3 at 128kbps public listening test - FINISHED

Reply #57 –
Quote
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

MP3 at 128kbps public listening test - FINISHED

Reply #58 –
Quote
Quote
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.
Juha Laaksonheimo
 

MP3 at 128kbps public listening test - FINISHED

Reply #59 –
Quote
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.
Juha Laaksonheimo

MP3 at 128kbps public listening test - FINISHED

Reply #60 –
I just added the bitrates distribution table to the results page.

MP3 at 128kbps public listening test - FINISHED

Reply #61 –
thanks rjamorim
I know, that I know nothing (Socrates)

MP3 at 128kbps public listening test - FINISHED

Reply #62 –
Quote
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

Quote
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?

MP3 at 128kbps public listening test - FINISHED

Reply #63 –
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!")

MP3 at 128kbps public listening test - FINISHED

Reply #64 –
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.

MP3 at 128kbps public listening test - FINISHED

Reply #65 –
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?

MP3 at 128kbps public listening test - FINISHED

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

MP3 at 128kbps public listening test - FINISHED

Reply #68 –
Quote
"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.
Microsoft Windows: We can't script here, this is bat country.

MP3 at 128kbps public listening test - FINISHED

Reply #69 –
Quote
[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.

MP3 at 128kbps public listening test - FINISHED

Reply #70 –
Quote
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.
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

MP3 at 128kbps public listening test - FINISHED

Reply #71 –
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.

MP3 at 128kbps public listening test - FINISHED

Reply #72 –
Quote
Quote
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

MP3 at 128kbps public listening test - FINISHED

Reply #73 –
Quote
Quote
"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..
Juha Laaksonheimo

MP3 at 128kbps public listening test - FINISHED

Reply #74 –
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.
Juha Laaksonheimo