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

MP3 Listening Test at 128 kbps

I would like to ask you to submit suggestions what MP3 encoder to include in my upcoming test, as well as suitable settings to produce ~128 kbps MP3 files. I would like to use only one setting per contender, so no suggestions like "LAME with -V 5 and -b 128 to test VBR vs. CBR". If that is really needed, a possible solution could be having -b 128 as contender and -V 5 or a higher setting as high anchor. Low anchor could be Shine, Blade or some very (very) old FhG encoder.

The goal of the test is to find out if fast encoders are really worse than LAME and if yes, how much worse. Some ideas for contenders: Gogo, LAME, iTunes, Helix, some FhG from Nero or Adobe or MMJB (in case I can still download it - heard that Y! stopped developing it) or WMP...

Also, since MP3 supports real CBR, do you think I should favor CBR over VBR for possible portability reasons (iPods not dealing well with LAME VBR)?

Bear in mind that LAME devs are the only persons to ask for recommended settings. I tried getting in touch with Helix folks some months ago but I had no luck (they didn't know what to recommend). Obtaining recommendations from FhG isn't possible neither.

Edit: One more thing - the max no. of contenders should be 4 + 2 anchors.

MP3 Listening Test at 128 kbps

Reply #1
Helix has a vbr quality mode for 128k, but FHG lowest setting is 150..160k (m3) which rules it out. Alternative for FHG is ABR mode for 135..140k (m4), but would that bitrate be unfair in a 128k test ?. So we can do FHG / Helix CBR 128k :

mp3sencoder -br128000
hmp3 -B64
gogo -b128

ABR:

mp3sencoder -br0 -m4
hmp3 - ?????
gogo -b135 -a

MP3 Listening Test at 128 kbps

Reply #2
Note that Nero is using multiple MP3 encoders depending on the application. The one from FhG we use in one place is AFAIK the same as what they have as demo on their website (unless that one is somehow limited, but doesn't look like it).

MP3 Listening Test at 128 kbps

Reply #3
I would like to see AAC 96 kbps CBR LC (used in previous test as high anchor) as a low anchor in this test.
This would be helpful to have some connection of results for 48 kbps and 64 kbps with this test.
But I suppose most people will be against it.

MP3 Listening Test at 128 kbps

Reply #4
I would like to see AAC 96 kbps CBR LC (used in previous test as high anchor) as a low anchor in this test.
This would be helpful to have some connection of results for 48 kbps and 64 kbps with this test.
But I suppose most people will be against it.


Yes this would be great, also because I hear the phrase "AAC 96k is equal to MP3 128k" thrown around a bit and it would be interesting to see if it's in any way true.

MP3 Listening Test at 128 kbps

Reply #5

I would like to see AAC 96 kbps CBR LC (used in previous test as high anchor) as a low anchor in this test.
This would be helpful to have some connection of results for 48 kbps and 64 kbps with this test.
But I suppose most people will be against it.


Yes this would be great, also because I hear the phrase "AAC 96k is equal to MP3 128k" thrown around a bit and it would be interesting to see if it's in any way true.


People have the wrong idea regarding this. it depends where the quality bump is. For mp3 there is a big one from 96 > 128k , smaller from 128 > 160k and yet smaller from 160 > 192k. The other codecs are similar , converging more or less @ 128k but drop quality more gracefully @ bitrate < 100 k.

So saying ogg/aac 96k = mp3 128k is a possibility (IMO 96k will be worse than LAME -V5). We can't use these assumptions for high bitrates: 170=200, 256=320 etc etc, because once you pass the big quality bump you get less and less as you bump up the bitrate.

MP3 Listening Test at 128 kbps

Reply #6
Anyway, I would like to see the mp3s encoder from FhG as we are using this since recently and it would be good to see how it performs compared to LAME. We only use CBR at the moment.

MP3 Listening Test at 128 kbps

Reply #7
Anyway, I would like to see the mp3s encoder from FhG as we are using this since recently and it would be good to see how it performs compared to LAME. We only use CBR at the moment.


Me too.


MP3 Listening Test at 128 kbps

Reply #9
IMO we should use with any encoder that setting which is a priori supposed to yield the best result. This can be quite disputable but we should try it.

Helix has a good VBR mode, so with Helix I suggest to use -V55 or -V60 which according to a listening test I did some time ago matches 128 kbps on average quite well. According to that (restricted) test we should use the default options (with the exception of -X2).

The problem with Lame is: 3.97 or 3.98b5+? With this only exception I suggest we use both versions because of their practical importance and in order to see what things are like with these versions.

With FhG IMO we shouldn't use VBR. According to my experience FhG's VBR mode is not attractive qualitywise.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #10
Sorry, but I maybe missed previous discussions where it was discussed why low anchor has to be significantly worse. Can you please give a rationale about this?
IMO it is enough that it is worse than almost all contenders in almost all samples. There was also a case in 64 kbps where I would prefer low anchor over one of contenders.

MP3 Listening Test at 128 kbps

Reply #11
96 kbps LC-AAC might be too good as low anchor. Consider that the low anchor has to be significantly worse than the rest.

I agree to that one. Considering the results of the 96 kbit/s AAC anchors of the 48 kbit/s and 64 kbit/s multiformat tests, it definitely won't be an appropriate low anchor in this case. I vote for Shine @128 kbit/s as low anchor.

Reason: Shine's an extremely simple encoder, which could be called a reference implementation for people starting to develop own encoders. It would be a good indicator to see how much better optimized encoders perform compared to a very basic one like Shine. Lately I had a few arguments with technically unexperienced people who refused believing me that the quality of MP3s can highly vary, depending on the encoders used for creating them. For these guys MP3 encoding is a fix matter that can't be altered/optimized in any way. I guess that's a major reason for the many 128 kbit/s full stereo Blade MP3s still found throughout the internet.

Quote
IMO it is enough that it is worse than almost all contenders in almost all samples.

Judging by the multiformat test results I mentioned there's no clear proof that 96 kbit/s AAC is actually worse than the contenders for this test. In this one it resulted at 4.59, i.e. on many samples it was transparent for a lot of listeners. How should you distinguish a transparent low anchor from the contenders and the high anchor?

MP3 Listening Test at 128 kbps

Reply #12
Sorry, but I maybe missed previous discussions where it was discussed why low anchor has to be significantly worse. Can you please give a rationale about this?
IMO it is enough that it is worse than almost all contenders in almost all samples. There was also a case in 64 kbps where I would prefer low anchor over one of contenders.


If the low anchor is on par with the contenders, or only slightly worse, then there is no need for an anchor at all. An anchor should be clearly distinguishable from the rest.

Now, doesn't this look really sweet: http://www.rjamorim.com/rrw/l3enc.html

MP3 Listening Test at 128 kbps

Reply #13
what about the mp3 encoder from iTunes ? dunno if it's FhG-based...

MP3 Listening Test at 128 kbps

Reply #14
what about the mp3 encoder from iTunes ? dunno if it's FhG-based...


I should like to see the iTunes encoder included, not for any technical reason but because it is so prevalent. It would be convenient for me to use it, instead of Max + Lame, and I'd like to know how the quality stacks up -- and I guess I'm not the only one.

MP3 Listening Test at 128 kbps

Reply #15
IMO we should use with any encoder that setting which is a priori supposed to yield the best result. This can be quite disputable but we should try it.

Helix has a good VBR mode, so with Helix I suggest to use -V55 or -V60 which according to a listening test I did some time ago matches 128 kbps on average quite well. According to that (restricted) test we should use the default options (with the exception of -X2).

The problem with Lame is: 3.97 or 3.98b5+? With this only exception I suggest we use both versions because of their practical importance and in order to see what things are like with these versions.

With FhG IMO we shouldn't use VBR. According to my experience FhG's VBR mode is not attractive qualitywise.


I say 3.98 and FHG @ 128 vbr mode is really ABR. The FHG cbr is also like a freeformat.

MP3 Listening Test at 128 kbps

Reply #16
Here's my two cents' worth,

FhG, Nero or WMP11 ?
- muaddib, please make some in-house queries about the exact details and version of FhG. Has anyone inside Nero actually compared the surround version against the presumably older "standard" version which included in WMP11?

Helix, VBR -- the exact -V value must be tried with a large amount of complete tracks (I can contribute).
- what is the last released source code version? AFAIK, the compile at Rarewares has not changed since it was put online.

LAME, VBR (whatever version and setting the developers recommend)
- 3.97 vs. 3.98 should be tested in private tests. The differences are probably not significant unless 3.98 is seriously regressed because of the developers' mistakes. I can promise to do a private test after this public test using the same samples. It would be relatively easy after doing the public test and finding out which kind of problems and where exactly the selected samples produce (which is going to be tough).

GoGo, ABR ~135 kbps (would produce a similar bitrate with LAME -V5)
- according to my limited personal testing this setting is slightly better than CBR 128. Perhaps I, halb27, shadowking, muaddib and others interested could select a few samples and compare these encoding modes in a quick "semi-public" pretest...

iTunes, CBR or VBR 128 kbps
- must be quite popular, is quite fast and has supposedly lower quality than LAME. Is anyone else interested?
(to kurtnoise: it is not FhG)

Low anchor, Shine 128 kbps
- this worked fine in the previous 128 kbps multi-format test. Even a very old FHG at 128 kbps would probably be too good. iTunes AAC at 96 kbps would most certainly be too good.
(To muaddib: The intention of a poor quality low anchor is to introduce the testers with typical encoding artifacts so that they can more easily try to pinpoint similar, but less pronounced artifacts that the contenders possibly produce.)

High Anchor, a surprise suggestion: FhG, CBR 192 kbps
- if it is good enough (I have been privately testing LAME -V2 variants too much lately and I would like to know how good FhG is at higher bitrates. Would it be transparent for the majority of testers?)

Edit: several typos...

MP3 Listening Test at 128 kbps

Reply #17
High Anchor, a surprise suggestion: FhG, CBR 192 kbps
- if it is good enough (I have been privately testing LAME -V2 variants too much lately and I would like to know how good FhG is at higher bitrates. Would it be transparent for the majority of testers?)

Sounds like a good choice to me, even with FhG already being included as a contender. The two FhG results could be very interesting for the many users out there, who rip their CDs with widely available commercial software, e.g. Windows Media Player. I don't have any figures available, but to me it doesn't look like the majority of people goes for alternative software, that uses a bundled version of LAME for MP3 encoding.

Alternatively, if Nero's/WMP's FhG encoder was used as the High Anchor, we could also go for the MP3 Surround encoder as a contender instead.

MP3 Listening Test at 128 kbps

Reply #18
Because of the meaning of Lame I still think it's worth while to test 3.97 as well as most current 3.98.

But if I'm the only one who thinks like that I suggest to use 3.98 cause it's the latest version and close to final.

As for iTunes mp3 I also like to see it tested.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #19
FhG, Nero or WMP11 ?
- muaddib, please make some in-house queries about the exact details and version of FhG. Has anyone inside Nero actually compared the surround version against the presumably older "standard" version which included in WMP11?


I'm pretty sure WMP does not use the new 4.0 series of FhG encoders. Nero does, but I'm not sure since what version (or if we even included that already). FhG claims their 4.x version is completely new compared to 3.x.
As said, I do not think the command line evaluation from the FhG website uses anything different than the SDK Nero uses, but I might be mistaken. If you want me to check it, let me know.
It support CBR and since recently also VBR (not enabled in Nero), there's also a quality/fast switch.

We are also still using the CodingTechnologies MP3Pro encoder in some places. I haven't heard anyone about that one yet (as it also does normal MP3).

MP3 Listening Test at 128 kbps

Reply #20
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 #21
*Low anchor:
AAC-LC @96 is not a suitable low anchor for such a test, IMHO. (anchor should not be used as a contender)
Regarding Shine, well, now that everyone seen how lame is Shine I think that it's perhaps a too low anchor. I would rather suggest either Blade or L3enc 2.72

*CBR vs VBR: hardware compatibility is a non-issue now. Every player should be able to properly play mp3 streams (even Apple is reported to having fixed Ipod's buffering issues with vbr)

*Lame version: I'd suggest 3.98 rather than 3.97. 3.98 is representative of  current Lame, while 3.97 is from 1 year ago, and is unlikely to be updated/maintained by anyone.

MP3 Listening Test at 128 kbps

Reply #22
dBPoweramp uses the Fhg IIS 4.0.3 encoder as well. Is this the surround sound encoder? Does Nero use 4.0.3 as well? What versions of Nero offer this encoder? WMP, as someone showed, uses Fhg 3.x.

I'm not sure of any Mac applications that can use Fhg 4.0.3. I asked Fraunhofer and they replied Cubase. Well this "only" costs about $1000!!!


MP3 Listening Test at 128 kbps

Reply #24
I thought the consensus was that Fhg only does CBR very well and that VBR still left much to be desired? I may be wrong though.

A bit off-topic, but still valid to the concerns of those doing the listening test -

which encoders can do gapless on iTunes and the iPod. Apple's own MP3, iTunes AAC, LAME MP3 can. What about  Fhg MP3, Nero AAC?