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 Listening Test at 128 kbps (Read 209048 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 Listening Test at 128 kbps

Reply #75 –
Quote from: guruboolez on
8/8 everywhere (I didn't mentionned it, sorry).
I can restart the test if you really want ABX log files.

No ABX log necessary, I just wanted to know the result.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #76 –
Sample “A03” offers the most obvious difference IMHO.
I didn't try yet with VBR -m4 which seems much more suitable to a ~130 kbps listening test (with non-classical music samples).
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

MP3 Listening Test at 128 kbps

Reply #77 –
What is fraunhofer mp3encs v1.4 20070711 please?

all4mp3's mp3sEncoder.exe V1.4 is dated 2007, July 5, and based on an encoder library V04.01.00 2007-05-18.

So this must be something else.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #78 –
http://www.all4mp3.com/tools/sw_fhg_cl.html

check the filename
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

MP3 Listening Test at 128 kbps

Reply #79 –
Thank you, but that's what my version originates from (the Win32 version). Guess you use another OS.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #80 –
I checked all download links and all are providing “mp3sEnc(...)20070711.zip”
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

MP3 Listening Test at 128 kbps

Reply #81 –
I see, you referred to the file name of the zip file, not the encoder itself.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #82 –
exactly
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

MP3 Listening Test at 128 kbps

Reply #83 –
1. I'm more interested in quality than speed, so, if there are other mp3 encoders being actively developed besides Lame (--I assume FhG is), and if unofficial but quick abx tests by known good listeners show they may plausibly be contenders, then I would like to see them included, or at least the one that is suspected of being the best rival. I also think mixing VBR & CBR can lead to some questions about the results (even in the 64kbps round), at least on tricky individual subtests where VBR produces a significantly bigger bitrate file than CBR, though I realize you keep it within reasonable bounds (10% or whatever). (Is any mp3 encoder not developed to take advantage of VBR likely to do as well as LAME in bitrates of 128kbps?)

2. Of course, if you are testing speed, then it would make sense to make sure all encoders are at the same level of speed (just as you would for bitrate)--produce what quality at the same bitrate in the same time. Else, you are comparing apples and oranges. What you are aiming for is quality per bit per second. Now you could correct for different times by normalizing the numbers after the test (ratios per time etc.), but that obviously is less meaningful (some encoders might do disproportionately bettter or worse at a different speed setting, so a linear ratio or normalization would be deceptive).

MP3 Listening Test at 128 kbps

Reply #84 –
How about adding Lame 3.90.3 as well, just for kicks.  And since I imagine there are quite a few of those mp3's laying around.

MP3 Listening Test at 128 kbps

Reply #85 –
Quote from: Sebastian Mares on
iTunes and Helix are also featured for sure. Should I use both in VBR mode?

I'd say yes.

Quote from: Sebastian Mares on
Fraunhofer is also an encoder I would like to include - same question now: CBR or VBR?

Does FhG have a set of recommendations in any open documentation? According to this:
Quote
.. If you use a variable bitrate setting, choose the maximum quality setting available in the encoder interface.

That's not too terribly informative, but I don't see anything that leads me to believe that FhG advises against VBR, so I'd say VBR should be used.

MP3 Listening Test at 128 kbps

Reply #86 –
Quote from: spockep on
How about adding Lame 3.90.3 as well, just for kicks. And since I imagine there are quite a few of those mp3's laying around.


Can't demand so much of the testers--I think they're trying to get the list down to four candidates, so 3.90.3 should not be included.

MP3 Listening Test at 128 kbps

Reply #87 –
Yes, and besides, Lame 3.90.3 was most popularly used for VBR ~ 190-200 kbps (-alt-preset standard, equiv to -V2), not much at 128 kbps (for which no VBR mode was available, only CBR or ABR).
Dynamic – the artist formerly known as DickD

MP3 Listening Test at 128 kbps

Reply #89 –
Someone mentioned Radium/ProducerPro/l3codecp.acm v1.2.x before.  I too would like to see this encoder included as it was so widely used.  (heck, I still use it with virtualdub)  I wan't to see how everyone else thinks it compares to the newer versions found in wmp10/11 (l3codecp.acm v3.4.x aka fastenc).

Personally I would drop GOGO since it is based on lame 3.88 (or something around there) and would much rather see lame 3.90.3/3.93.1 --alt-preset CBR 128 -h (only because you all don't like my crazy/custom settings  ) to see how much lame really has/hasn't improved.

I think it would be better to have an FhG test, a Xing test, and a LAME test to see how much the encoders have changed over the years.  Then compare the best with each other.

My $.02
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

MP3 Listening Test at 128 kbps

Reply #90 –
I will definitely not include versions older than 3.97. 3.97 was an idea because it's the currently recommended encoder, but since Gabriel and others want to test 3.98, I prefer that over 3.97.

Any idea what was changed from Gogo 3.12 to 3.13?
 

MP3 Listening Test at 128 kbps

Reply #91 –
I think before starting to discuss settings, we should decide what the test should be good for:

A. Compare recommended LAME quality settings to "defaults" of the competition (defaults in quotation marks because VBR will be probably enforced - what I mean is that no additional settings like optimization for speed or quality should be supplied)

B. Compare recommended LAME speed settings to fastest mode of the competition

C. Compare recommended LAME quality settings to best quality mode of the competition (but only if those settings have a note that they really increase quality, such as in FhG's case, so no funky Helix switches that nobody knows what they are actually good for)

MP3 Listening Test at 128 kbps

Reply #92 –
I choose C. I'm interested in how competitors perform with quality-geared settings. Encoding speed should be mentioned but should also be a secondary consideration unless we can create a metric to gauge performance-per-time-unit as a fellow above suggested.

MP3 Listening Test at 128 kbps

Reply #93 –
FhG MP3 Surround Encoder is an Next-Gen MP3 encoder & you must use the full version for any test...

MP3 Listening Test at 128 kbps

Reply #96 –
Quote from: Sebastian Mares on
I think before starting to discuss settings, we should decide what the test should be good for:

Quote from: Silver Wave on
FhG MP3 Surround Encoder is an Next-Gen MP3 encoder & you must use the full version for any test...

I'm not sure to understand what Silver Wave means by 'full version' but if 'full' means 'full quality' I would agree with this point.



The first questions I would ask:

• now we have bi-, quad- and soonly octo-core processors working at several GHz, is there any point of testing encoders, which are already very fast, with their fastest settings?
• shouldn't we first respect these new competitors and check their full potential - especially if we oppose them to a reference called LAME which will be set to offer its best - before evaluating their quality on their fastest mode?


In my opinion the true challenge of this “MP3 listening test” is to see what potential offer the latest “2007” Fraunhofer encoder, the flexible HELIX one, and maybe the last Apple's implementation (totally different from Fhg & Xing). I would consider them as true competitors to LAME, and not the poor ones we could handicap even further with 'fast'/'lower quality' settings.
It's a listening test: we don't have to presuppose that LAME's competitors are worse in order to justify our choice to lower their quality a bit more. It implies the following rule: if one encoder is set to reach its full potential (LAME) all others should be set with the same principle. If our goal is to test ultra-fast MP3 implementations, then LAME 3.xx looks out of competition.

what are we interested for? To see if LAME's superiority is still valid? To see which x90 MP3 encoder offers the less distorted sound?


I know there's another question (already mentionned): is LAME relative “slowness” really justified by a quality boost? That's why some users are interested (for practical purpose) to "boost" speed to the max level. This question is perfectly valid and is truly interesting. But starting a listening test for the sole purpose to answer this question is problematic. If LAME appears as better, what would be our gain? We would only “discover” that a x60 encoder sound worse than a x15 one: what a lesson! And we would still ignore if Fraunhofer 4.xx in HQ mode is able to compete with LAME. Gain in this hypothesis = nada.
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

MP3 Listening Test at 128 kbps

Reply #97 –
Quote from: guruboolez on
... In my opinion the true challenge of this “MP3 listening test” is to see what potential offer the latest “2007” Fraunhofer encoder, the flexible HELIX one, and maybe the last Apple's implementation (totally different from Fhg & Xing). ...

I absolutely second that. Speed really shouldn't be an issue as any encoder can be considered fast enough.
Sure it's remarkable in case it should come out that a superfast encoder has better quality than a sufficiently fast one, but that's all.

As far as I remember in the first thread for the 128 kbps listening test there was a rough motivation to see how Lame competes with other encoders which happen to be faster. The speed thematics was there, but it was not an overwhelming one.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #99 –
I prefer the CLI encoder because I did use it and had a pretty good impression qualitywise.
I also bought Real when I cared about Helix a lot but wasn't impressed and continued to use the CLI encoder.
I must admit however I don't remember the details, and it may be that it was just the GUI that disappointed me.
lame3995o -Q1.7 --lowpass 17