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

MP3 Listening Test at 128 kbps

Reply #51 –
So should we do anything to avoid people to react strangely? IMO this is not a good target and we won't succeed anyway.

No, indeed - we can't avoid it. But there's one question we must ask to ourselve: would such reaction be strange? Why should someone believe that CBR performs better than VBR? Why should someone accept that ABR is globally a better choice when this superiority is only attested for specific problems? I personally don't see any reason to do that. I (can) accept some advice from developers themselves but from unknown people I simply can't do it. Or to be more precise: I could trust some people's advices for a personal usage of an unfamiliar encoder but I wouldn't engage the credibility of a test and the work of 20 listeners on such fragile knowledge.

We should do the best according to what we know - well conscious about the imperfections.

OK, but if someone (me for exemple) will provide samples revealing that FHG VBR performs better than CBR? What would be our knowledge?
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 #52 –
The only sure thing is lame -V5 cause we know it well. Helix, Fhg should be tested @ 130k vbr too, not CBR.. Gogo shouldn't be tested as its too old and not really faster than the others. Why do I have a gut feeling that the results will be again near perfect not showing much difference ?

MP3 Listening Test at 128 kbps

Reply #53 –
Quote from: Sebastian Mares on
halb27, as far as I heard so far, FhG 4 seems to be a new encoder so maybe the VBR performance increased compared to the 3 series.

OK, I did my test with an earlier version so my experience may not be valid any more.
lame3995o -Q1.7 --lowpass 17
 

MP3 Listening Test at 128 kbps

Reply #54 –
According to my bitrate table Fhg VBR -m3 mode looks as the perfect VBR setting for such listening test: 128 kbps on 150 full classical music tracks (16 hours of music). For comparison, LAME 3.98b5 -V5 reaches 129 kbps on the same corpus.
As usual advantage of VBR coding, bitrate fluctuates and can reach high values on critical samples. Here are four examples, coming from my usual gallery, showing that Fhg VBR (-m3 -q0) outperforms CBR/ABR encodings (tested -br 134):

http://rapidshare.com/files/54002892/fhgsamples.zip

You may notice it: individual bitrate is considerably higher than 130 kbps but that's exactly what we're expecting from VBR with such 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 #55 –
Quote from: guruboolez on
... OK, but if someone (me for exemple) will provide samples revealing that FHG VBR performs better than CBR? What would be our knowledge? ...

That would be a valuable piece in the puzzle of improving experience.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #56 –
@halb27> I anticipated your wish (see previous message)

A small bitrate table (150 full tracks of music; genre = classical):
http://www.megaupload.com/?d=Z1VKHJ0U

In summary:

Code: [Select]
fraunhofer mp3encs v1.4 20070711

-m1..... 193 kbps
-m2..... 161 kbps
-m3..... 128 kbps
-m4..... 118 kbps
-m5..... 101 kbps


LAME 3.98 beta 5

-V4..... 160 kbps
-V5..... 129 kbps
-V6..... 112 kbps



EDIT: commandline used (foobar2000):
-if - -of %d -vbri -ofl -eof -sr 44100 -c 2 -br 0 -m 1 -q 0
-if - -of %d -vbri -ofl -eof -sr 44100 -c 2 -br 0 -m 2 -q 0
-if - -of %d -vbri -ofl -eof -sr 44100 -c 2 -br 0 -m 3 -q 0
-if - -of %d -vbri -ofl -eof -sr 44100 -c 2 -br 0 -m 4 -q 0
-if - -of %d -vbri -ofl -eof -sr 44100 -c 2 -br 0 -m 5 -q 0

-c2 = 2 channels
-br 0 = required to enable VBR
-m n = VBR mode
-q 0 = enables fast quality coding mode [damned! I used the wrong switch!!! I had to redo the whole table]
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 #58 –
In a quick test with my AC/DC sample a "FhG IIS 4.1.0 @ -m 3" file was easy to ABX. A lot easier than a LAME -V5 encoding. The electric guitar in the beginning of the sample is totally ruined. The bitrate was 144 kbps.

I am going to gather a few of my favorite samples and test FhG 3.4 CBR, FhG 4.1.0 CBR & VBR and GoGo ABR. However that is not going to happen before I have run the bitrate and encoding time tests on Saturday or Sunday.

MP3 Listening Test at 128 kbps

Reply #60 –
Quote
Code: [Select]
fraunhofer mp3encs v1.4 20070711

-m3..... 128 kbps
-m4..... 118 kbps


I tested on more than 100 samples gathered from listening tests over the years:

-m3 produces 140 kbps
-m4 produces 130 kbps

Lame -V5 produces 136 kbps on this set

MP3 Listening Test at 128 kbps

Reply #62 –
Quote
q 0 = enables fast quality coding mode


This is the default mode and should be preferred for this test.

MP3 Listening Test at 128 kbps

Reply #64 –
Quote from: Sebastian Mares on
BTW, what does the "Original File Length" actually do? Does it have anything to do with gapless playback?

Yes, it is for gapless playback. FhG decided to reinvent the wheel.

Edit:

It would be great if Nyaochi or some other developer could create a front end that would save a LAME info header to FhG files, as I wrote in this reply:

Quote from: Alex B on
The WMP11 encoder is currently this:

Code: [Select]
MPEG Layer-3 Codec Version 3.4.0
Fraunhofer IIS MPEG Layer-3 Codec (professional)
Copyright (C) 1996-2004 Fraunhofer IIS


The great thing about this codec is that it can used through Nyaochi's "acmenc" command line tool (after a small registry edit). Acmenc can include a LAME info tag style header which contains info for gapless playback. It is easy to configure foobar to encode through acmenc. I have used it as a faster option to LAME when I am in a hurry.

I wonder if Nyaochi could create a modified version which could be used with FhG's exe encoder (for creating a compatible gapless playback info header instead of FhG's quite useless newly introduced header).

MP3 Listening Test at 128 kbps

Reply #65 –
Quote from: Alex B on
This is the default mode and should be preferred for this test.

Why should speed be prefered over quality?
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 #66 –
Testing the faster options vs. LAME has been the idea of this test since August 2006 (or even before).

Perhaps the new FhG version changes that, but could you first try if the encoder is any better at -q 1 than at -q 0.

MP3 Listening Test at 128 kbps

Reply #67 –
Quote from: Sebastian Mares on
Test -m 3 with some of my audio tracks (Pink Floyd, Led Zeppelin, Alphaville, Dire Straits...) and the bitrate is around 150 kbps.

menno also said that -m 4 seems to produce ~130 kbps.

I just tried with one “speed metal” album:
-m3 = 150 kbps
-m4 = 140 kbps
-m5 = 113 kbps (32 KHz)

I'd like to see a bitrate table including different musical genre (some members did it in the past) to see which -m mode would be the most adequate. -m4 sounds significantly worse than -m3 (crappy artifacts everywhere on metal).

Quote from: Alex B on
Testing the faster options vs. LAME has been the idea of this test since August 2006 (or even before).

Yes, I remember that some people requested a “fast MP3 encoder listening test”, right?
But is it still the purpose here? Or are we interested to see if the new and rather untested MP3 encoders are valid challengers to LAME?
If the goal of this test is to check which fast MP3 implementation offers the best quality, then I don't see the point of including LAME (excepted maybe as high anchor). But of the goal is to evaluate what degree of quality all "modern" MP3 encoders are offering, then I would use them at their “high quality mode” - not their “fast” ones.
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 #68 –
-m 3 seems to encode at 50x with foobar2000 (two parallel encoders due to HT CPU).

The actual idea of the test was to see if LAME, which is really slower than the other encoders, offers a much higher quality that would justify the speed "issue". LAME could serve as high anchor, but -V 5 --vbr-new might not be that much better than the rest thus doing a bad job as high anchor.

MP3 Listening Test at 128 kbps

Reply #69 –
On rock / metal i get around 152k (m3) 140 (m4)

MP3 Listening Test at 128 kbps

Reply #70 –
Quote from: Sebastian Mares on
-m 3 seems to encode at 50x with foobar2000 (two parallel encoders due to HT CPU).

The actual idea of the test was to see if LAME, which is really slower than the other encoders, offers a much higher quality that would justify the speed "issue".


I missed this idea. Sorry.
But shouldn't the first logical competitor to LAME be LAME itself, at -q7 or -q9 setting (which are significantly improving the encoding speed)? If the purpose is to evaluate the tradeoff between quality and speed shouldn't we question first the choice of LAME developers before testing alternative encoders?
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 #71 –
Here are some results with -m 3:

Vivaldi's Four Seasons: 130
Chris Rea (3 albums): 150
Coldplay (2 albums): 145
Deep Purple's Made in Japan Remastered: 150
Dire Straits (3 albums, 1 live with 2 CDs, 2 studio, 1 remastered version of a studio album): 150

I can let fb2k encode and see what else comes out after encoding my large Pink Floyd collection, Jethro Tull, etc., but I think it will stay at around 150 kbps.

Eminem's Curtain Call - The Hits: 145

Quote from: guruboolez on
Quote from: Sebastian Mares on

-m 3 seems to encode at 50x with foobar2000 (two parallel encoders due to HT CPU).

The actual idea of the test was to see if LAME, which is really slower than the other encoders, offers a much higher quality that would justify the speed "issue".


I missed this idea. Sorry.
But shouldn't the first logical competitor to LAME be LAME itself, at -q7 or -q9 setting (which are significantly improving the encoding speed)? If the purpose is to evaluate the tradeoff between quality and speed shouldn't we question first the choice of LAME developers before testing alternative encoders?


I was thinking about testing the recommended LAME settings for 128 kbps (= -V 5 --vbr-new) against other fast encoders with their default setting to see if there's a big quality difference. Another possibility would be asking LAME devs for the fastest LAME setting and then comparing that to the fastest setting of the other encoders OR trying to figure out what high quality settings to use for the contenders and then checking the results of the test - if the other contenders that were set to prefer quality over speed are still worse than LAME, then their fast setting would be for sure, too. If they are better and the speed is similar to LAME's, LAME no longer is the king of MP3 encoders. If the quality is equal, look at the encoding speed. If the speed was also similar to LAME's, then we still have the "problem" that we don't know how well the fast settings perform.

MP3 Listening Test at 128 kbps

Reply #72 –
Quote from: shadowking on
Gogo shouldn't be tested as its too old and not really faster than the others. Why do I have a gut feeling that the results will be again near perfect not showing much difference ?

yeah, besides, gogo has already been tested.

MP3 Listening Test at 128 kbps

Reply #74 –
8/8 everywhere (I didn't mentionned it, sorry).
I can restart the test if you really want ABX log files.
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