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

MP3 at 128kbps public listening test

Reply #100 –
Quote
Just to be sure I used your abchr (first time),  f123.

Code: [Select]
ABC/HR Version 0.9b, 30 August 2002
Testname: main_theme

1R = C:\main theme iTunes 128.wav
2R = C:\fastenc -hq main theme.wav

---------------------------------------
General Comments:
Sample 1 has more ringing but I think has higher cut-off
---------------------------------------
ABX Results:
C:\main theme iTunes 128.wav vs C:\fastenc -hq main theme.wav
    10 out of 10, pval < 0.001


As I said fastenc -hq (or slowenc) sounds much better to me.

I'm almost sure when you use the "ringing" term that you're hearing higher frequency stuff in iTunes that I can't.

I'd bet that you'd personally like the slow FhG codec best overall, preferring it over the fast FhG codec and lame --alt preset 128.  However, it has annoying low frequency glitches (not apparent in main_theme.wav, though) which make it just about the worst mp3 codec for me.

It would definitely be an interesting codec to include, but I doubt that many people use it these days because I think FhG phased it out of their mp3 library.

ff123

Edit:  for an example of the type of low frequency glitching that occurs, try using fastencc.exe -hq on the blackbird.wav sample:

http://lame.sourceforge.net/download/sampl...s/BlackBird.wav

MP3 at 128kbps public listening test

Reply #101 –
Mhh... that BlackBird is rather nasty. Is the hq switch limited? I tried to test BlackBird with -vbr -hq & -br192 -hq, in both situations -hq won't work with the other command

MP3 at 128kbps public listening test

Reply #102 –
sorry to go a little offtopic but...

I'm confused
There seems to be so many different FhG encoders and many diff programs with various settings using them...
Could someone give my a list or a link to a list with all the encoders and which program using it. And what year they are from.
And what is supposedly to be the newest/best encoder?
(I know FhG encs used to have a phase shift problem in JS before, but I believe it to be solved now)

1. L3enc (1994-1997)
2. Producer Pro 1.0 (1996)  this is also the radium hack
3. Producer Pro 2.0 (1997)
3. Mp3enc (1997- ?)
4. Fastenc (?)      What versions/settings were there problems with? Is it still developed?
5. Musicmacht x.xx  What is the enc the newest version is using?
6. FhG Audition Legacy Slow/Current  Never heard of this, is the prog or the encoder called audition? Is it using fastenc?
7. WMP
8. Cool edit
9. Audioactive
10. ?

Isn't every FhG encoder based on each other(L3enc)?
Anybody help?

MP3 at 128kbps public listening test

Reply #103 –
Quote
fastencc.exe -hq (what I call "slowenc") might be the best-sounding codec for people with good high-frequency hearing.  It would be interesting to include in a 128 kbit/s mp3 test, but then that would mean either including 3 FhG codecs, or dropping either the fast codec or the Audioactive/Radium codec.

ff123

I have not tested in depth slowenc but in at least one sample (rebel.wav) the codec fails quite badly with high frequencies (ringing, some frequencies are completely throwed out). Both "good" fastenc (CEP2.1) and iTunes have similar problems, LAME with nspsytune is much better even if not perfect. I think this sample is quite interesting, even new generation AAC encoders (expecially Fhg) have troubles with it. Reading this previous post you can download the clip and see some spectral views concerning AAC.
I'm of the idea of dropping slowenc, the codec is too slow and abandoned by Fraunhofer. The pre-test about CBR vs. VBR with Fraunhofer encoders is a right idea, what samples and encoders should be tested ? IIRC in your site there are some tests showing that Fhg CBR is better than VBR but i don't remember which Fhg codec.
WavPack 4.3 -mfx5
LAME 3.97 -V5 --vbr-new --athaa-sensitivity 1

MP3 at 128kbps public listening test

Reply #104 –
Quote
I don't understand how it follows that we should test alt-preset standard (aps) against 128 kbit/s settings from music_man_mpc's test.


Quote
Let's get serious here:  --alt preset standard is heads and shoulders above --alt-preset cbr 128, and it would be a gigantic waste of time and effort to show this.  Try any sample with sharp transients (eg., castanets.wav).  Convince yourself.


Quote
I agree entirely, my test was conducted simply to see if Gogo is, as Mike Giacomelli implied, in the same ballpark as LAME.  My conclusion was this:  to my ears, on the sample I tested (Tool - Schism 0:26 - 0:35) Gogo sound virtually identical to LAME at 128kbit/s.  What does this have to do with --alt-preset standard kwanbis?


are you sure about what you are saying? i do encode in -aps, but is it really that better? or is it as music_man_mp thought about lame vs gogo? why is it a waste of time to test it? what abx do you have to prove it? (rule #8)? that you just don't agree with me, does not mean that i'm not being serious ... also, is just my friendly thought

MP3 at 128kbps public listening test

Reply #105 –
I've read every single post in this thread, but I'm now a little lost as to where we're at.


FWIW I think it's essential that you include the _good_ _real_ version of FastEnc at CBR 128kbps, using either Cool Edit Pro (last version of both CEP and the plug-in), Adobe Audition (what is the real FastEnc called in that?), or Music Match Jukebox (recent version). Not fastenc.exe or old Music Match because both are buggy.

I think this is essential because it's such a newbie default mp3 encoding.


To my ears, FhG audio active, FhG FastEnc, and FhG SlowEnc all have their own sound. They all have their own faults too - pick samples carefully!


I don't know how you deal with CBR or VBR/ABR. Probably stick with one or the other. Seems unfair to mix both, but then I can't see why you would use lame CBR when ABR is so good, whereas I've never seen anyone claim that FhG VBR beats FhG CBR around this bitrate (maybe no one around here uses it). Difficult to answer all questions in six samples, so decide: do you want to compare encoders, or modes (ABR/CBR) - because I don't think you can comprehensively to both in one test.

btw recent Xing isn't as bad as very old Xing. Very Old Xing makes better low quality anchor, but current Xing is more relevant.

Cheers,
David.

P.S. lame -h -b 128 beats lame --alt-preset cbr 128 on at least two samples, so nothing is clear cut and predictable!

MP3 at 128kbps public listening test

Reply #106 –
Quote
are you sure about what you are saying? i do encode in -aps, but is it really that better? or is it as music_man_mp thought about lame vs gogo? why is it a waste of time to test it? what abx do you have to prove it? (rule #8)? that you just don't agree with me, does not mean that i'm not being serious ... also, is just my friendly thought

Because there are about a million samples where lame cbr 128 is ABXable vs the original, and about ten where lame aps is ABXable vs the original.

Cheers,
David.

MP3 at 128kbps public listening test

Reply #107 –
Quote
Because there are about a million samples where lame cbr 128 is ABXable vs the original, and about ten where lame aps is ABXable vs the original.

but you don't provide any supporting facts ... you just keep repeating a "known" (or assumed) fact ...

8. Any statement about sound quality must be supported by the author responsible for such statements by a double blind listening test demonstrating that he can hear a difference, together with a test sample. Graphs, non-blind listening tests, subtracting two files and so on are definetely not considered as valid evidences of sound quality

MP3 at 128kbps public listening test

Reply #108 –
Quote
are you sure about what you are saying? i do encode in -aps, but is it really that better? or is it as music_man_mp thought about lame vs gogo? why is it a waste of time to test it? what abx do you have to prove it? (rule #8)? that you just don't agree with me, does not mean that i'm not being serious ... also, is just my friendly thought

Did you actually try castanets.wav, or florida_seq.wav, or death2.wav, or any sample at all?  Don't throw rule 8 at me until you've done a little homework!

ff123

MP3 at 128kbps public listening test

Reply #109 –
Quote
Quote
Because there are about a million samples where lame cbr 128 is ABXable vs the original, and about ten where lame aps is ABXable vs the original.

but you don't provide any supporting facts ... you just keep repeating a "known" (or assumed) fact ...

8. Any statement about sound quality must be supported by the author responsible for such statements by a double blind listening test demonstrating that he can hear a difference, together with a test sample. Graphs, non-blind listening tests, subtracting two files and so on are definetely not considered as valid evidences of sound quality

I'm talking from personal experience.

(Not the "millions" part obviously! I was extrapolating from the samples I've encoded at 128kbps, and assuming that other people have similar experiences.)


The first sample I played with at 128kbps was youcantdothat.wav:
http://lame.sourceforge.net/gpsycho/quality.html


The reason you're not getting a serious answer to your question is because it's probably harder (though certainly not impossible) to find a sample where aps and 128cbr are equal. It's easier to find a sample where 128cbr is audibly worse than aps - just go out and rip a random CD! You have to listen carefully to the result, but it's there much of the time.


Cheers,
David.

MP3 at 128kbps public listening test

Reply #110 –
Quote
Don't throw rule 8 at me until you've done a little homework!

I can't believe someone is actually trying to throw rule 8 at ff123, of all people! 

MP3 at 128kbps public listening test

Reply #111 –
Quote
I don't know how you deal with CBR or VBR/ABR. Probably stick with one or the other. Seems unfair to mix both, but then I can't see why you would use lame CBR when ABR is so good, whereas I've never seen anyone claim that FhG VBR beats FhG CBR around this bitrate (maybe no one around here uses it). Difficult to answer all questions in six samples, so decide: do you want to compare encoders, or modes (ABR/CBR) - because I don't think you can comprehensively to both in one test.

----

P.S. lame -h -b 128 beats lame --alt-preset cbr 128 on at least two samples, so nothing is clear cut and predictable!

Hi,
I think it could be useful (or, at least I am really interested ) to have a listening test to compare CBR 128 versus ABR 128, and which encoder sounds better.
It could be split in four parts: the first one would be aimed at choosing the best commandline for ABR, the second would be aimed at finding the best encoder for ABR, the third aimed at finding the best CBR and the fourth will be a direct comparison of ABR vs CBR.

It is obviously a long and difficult test, but maybe it can help to clear some questions.

What do you think: is it worth trying?
Vital papers will demonstrate their vitality by spontaneously moving from where you left them to where you can't find them.

MP3 at 128kbps public listening test

Reply #112 –
Quote
What do you think: is it worth trying?

What I wonder is if there is still that much interest in MP3 these days that would justify giving it so much attention. The people that are after listening tests and comparisions (I.E, the target audience of my tests) probably already know about modern formats, so they would probably only use MP3 for hardware compatibility.

MP3 at 128kbps public listening test

Reply #113 –
Considering that 99% of downloadable audio is 128kbps mp3 (old & new material) & hardware mp3 support is being stuck in almost every DVD player, a lot of discmans, car head units, mobile phones & even digital cameras I think it's highly relevant. I also would want really fastenc -hq (slowenc) in the test because it is very different to other encoders & as f123 has said for people with better higher frequency hearing it is a great performer.

I also vote for a pre-test for fastenc settings (lowpass?) & CBR+VBR.

MP3 at 128kbps public listening test

Reply #114 –
Quote
I also vote for a pre-test for fastenc settings (lowpass?) & CBR+VBR.

Well, anyone willing to organize this quick pre-test?

I would do so myself, but I'll travel soon for the holidays and will only be back by mid-January.

I don't think several samples and countless listeners are needed. Just half dozen samples would be enough, since we only need to have an idea of what include in the test.

Ideas?

MP3 at 128kbps public listening test

Reply #115 –
Quote
I also vote for a pre-test for fastenc settings (lowpass?) & CBR+VBR.

The same should be done for iTunes, really. If anyone's interested, I could encode a few samples using iTunes VBR & CBR.

First, I'll encode a couple of CD's of different genres to see what setting matches 128kbps VBR best.

MP3 at 128kbps public listening test

Reply #116 –
Quote
MWAHAHAHA. OK then, I'll keep some of the samples and replace others, and I'll keep the list of what stays and what goes secret until the date of the test

I agree with you, that should avoid claims of tampering.

I think vice versa. The list of samples MUST BE publicated so nobody will say there were tampering.
Ogg Vorbis for music and speech [q-2.0 - q6.0]
FLAC for recordings to be edited
Speex for speech

MP3 at 128kbps public listening test

Reply #117 –
Quote
I think vice versa. The list of samples MUST BE publicated so nobody will say there were tampering.

Right, but if the list is publicated before the test start, people might say some developer tweaked his encoder exactly for those samples.

MP3 at 128kbps public listening test

Reply #118 –
Quote
Quote
I think vice versa. The list of samples MUST BE publicated so nobody will say there were tampering.

Right, but if the list is publicated before the test start, people might say some developer tweaked his encoder exactly for those samples.

Hmmmm...
You can try to do the list so difficult so tuning to 1-3 samples will distune the codec for the others  . Isn't it possible? If it isn't. You could publicate the list and fix all the participants current versions. I think there can't be any REVOLUTION in 2-3 monthes. Huh? By the way how many samples will you use?
Ogg Vorbis for music and speech [q-2.0 - q6.0]
FLAC for recordings to be edited
Speex for speech

MP3 at 128kbps public listening test

Reply #119 –
Quote
Isn't it possible?

Might be, if I were a developer and knew exactly what feature in a sample would break others when trying to tune for it.

Quote
I think there can't be any REVOLUTION in 2-3 monthes. Huh?


Yeah, I think I'm being overcautious.

But I believe Ivan will try to fix the issues in EnolaGay

Quote
By the way how many samples will you use?


12, as usual.

Regards;

Roberto.

MP3 at 128kbps public listening test

Reply #120 –
Just wondering
Since different encoders use different frequency-cutoff , is the comparison fair? I mean, a clip isn't the same clip anymore when each encoder is lowpassing it before encoding. How about finding out what frequency the most frequency-cutting-encoder is lowpassing at, and then lowpassing each sample in cooledit or some prog., according to the found frequency. Then mp3encode the samples. Would that be a better/worse comparison?

Just a thought....

MP3 at 128kbps public listening test

Reply #121 –
Quote
Just wondering
Since different encoders use different frequency-cutoff , is the comparison fair? I mean, a clip isn't the same clip anymore when each encoder is lowpassing it before encoding. How about finding out what frequency the most frequency-cutting-encoder is lowpassing at, and then lowpassing each sample in cooledit or some prog., according to the found frequency. Then mp3encode the samples. Would that be a better/worse comparison?

If an encoder is lowpassing too much or too few, it's his fault. And therefore it should be punished for it, and not bring every other codec down to the same (bad) level.

MP3 at 128kbps public listening test

Reply #122 –
Quote
Quote
I think there can't be any REVOLUTION in 2-3 monthes. Huh?


Yeah, I think I'm being overcautious.

But I believe Ivan will try to fix the issues in EnolaGay


You didn't understood me on this statement.
I mean you can publicate the list _today_ and use the last for _today_ encoders versions. They can't evolute much till testing starts so _today_ versions will be almost up to date versions in 2-3 monthes and the test will be almost recent too.
Or even we the developer of encoder will make tuning it speaks of good support of encoder 
Ogg Vorbis for music and speech [q-2.0 - q6.0]
FLAC for recordings to be edited
Speex for speech

MP3 at 128kbps public listening test

Reply #123 –
Quote
Quote
Just wondering
Since different encoders use different frequency-cutoff , is the comparison fair? I mean, a clip isn't the same clip anymore when each encoder is lowpassing it before encoding. How about finding out what frequency the most frequency-cutting-encoder is lowpassing at, and then lowpassing each sample in cooledit or some prog., according to the found frequency. Then mp3encode the samples. Would that be a better/worse comparison?

If an encoder is lowpassing too much or too few, it's his fault. And therefore it should be punished for it, and not bring every other codec down to the same (bad) level.

I think test results would be more accurate if all encoders used the same lowpass where possible (e.g if the encoder allows, Cool Edit 2.1). After all lame is allowed to use the alt-preset command line other encoders should also be tweaked where possible. Aren't we trying to find the best performing encoder? then we should tweak all the encoders the best possible.

Edit: Someone might ABX an encoder "dull sounding" just because it uses 16khz lowpass

MP3 at 128kbps public listening test

Reply #124 –
You should not tweak yourself the encoders, otherwise the result won't be representative of the usual encoder results.

Moreover, it is likely that the codec developers know better than you which lowpass value to use.