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

MP3 Listening Test at 128 kbps

Reply #150 –
• LAME 3.98b5: --vbr-new is not needed anymore (used by default)
• iTunes: I don't see any reason to not use the highest quality level.
• Fraunhofer: same than iTunes
• GoGo: I would trust AlexB's advice on GoGo (he has an experience I don't have)
• Real: As you wish (I would personally avoid to install Real and use the CLI tool instead). VBR seems to be the way to go.

___
I finished on my side a personnal MP3 listening test based on classical samples which features four encoders. I can give the average bitrate of 150 files (16 hours of music), unfortunately not representative of compressed and/or popular music:
• LAME -V5 = 128,73 kbps
• iTunes 128 VBR HQ = 131,54 kbps
• Helix -V65 = 129,12 kbps
• Fhg -m3 -q1 = 127,86 kbps
I'm lucky that VBR settings are so much comparable bitrate-wise. Fhg seems to be downgraded to -m4 with louder music to match the targeted bitrate range; Helix can easily be adjusted if needed; iTunes needs to be tested by someone else (if it's not already done).

For information: both iTunes & Fhg are giving pretty good (but not constant) results here.
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 #151 –
Quote from: guruboolez on
• LAME 3.98b5: --vbr-new is not needed anymore (used by default)
• iTunes: I don't see any reason to not use the highest quality level.
• Fraunhofer: same than iTunes
• GoGo: I would trust AlexB's advice on GoGo (he has an experience I don't have)
• Real: As you wish (I would personally avoid to install Real and use the CLI tool instead). VBR seems to be the way to go.

In my ABC-HR test of 30 various samples FHG VBR -m4 -q1 was surprisingly not better than the default faster mode.

It would be nice if you could verify that with your familiar classical samples. In addition, my test package contains some interesting new samples in case you would like to try them.

Quote
I finished on my side a personnal MP3 listening test based on classical samples which features four encoders. I can give the average bitrate of 150 files (16 hours of music), unfortunately not representative of compressed and/or popular music:
• LAME -V5 = 128,73 kbps
• iTunes 128 VBR HQ = 131,54 kbps
• Helix -V65 = 129,12 kbps
• Fhg -m3 -q1 = 127,86 kbps
I'm lucky that VBR settings are so much comparable bitrate-wise. Fhg seems to be downgraded to -m4 with louder music to match the targeted bitrate range; Helix can easily be adjusted if needed; iTunes needs to be tested by someone else (if it's not already done).

For information: both iTunes & Fhg are giving pretty good (but not constant) results here.

It seems that FhG needs to be used at -m4 if VBR mode is selected. -m3 produces too hig bitrates with anything else than classical.

"if it's not already done"

- I did (I copied my results here so you don't need to scroll back.):

Quote from: Alex B on
Here are my results. For iTunes and RealPlayer I used the standard GUI programs. For the command line encoders I used Speeks' Batchenc frontend. The WMP11 mp3 codec was accessed by Nyaochi's Acmenc and Speek's Batchenc. The test bench was a 2.8 GHz P4. Before the speed tests I tried to disable all unnecessary background processes. The source files were in wave format on one HD and the target HD was separate. I measured the encoding times with a digital stopwatch. I didn't run several passes that would have been needed for lowering the error margin, but I think the results are accurate enough for this purpose. For measuring the bitrates I used Encspot Pro's "Complete Scan" feature (some other programs may not show correct bitrates with files that don't contain a Xing header).

The test file set consists of 25 selected complete tracks of various genres. The total duration is one hour, 31 minutes and 34 seconds.

The encoding speeds and average bitrates:


The individual bitrates of the VBR files:


A chart of the VBR bitrates:


Some readers may also find the following table interesting (Album = the 25-track test set):



I uploaded the test data here (Excel file & Encspot Pro reports):
http://www.hydrogenaudio.org/forums/index....st&p=515301

MP3 Listening Test at 128 kbps

Reply #152 –
Thanks for reminding me some elements submitted some days ago 
Apparently iTunes MP3 VBR (134 kbps) is suitable for this test.
Fraunhofer q0/q1 difference: I won't test it on my side (I tried and -bored- I quickly gave up last week). I strongly believe that we should use the switch called “high quality”; even if didn't improved anything according to your test, I didn't lowered the quality either. We should always test the HQ mode and let people use the fastest mode if they're ready to take some risks (even minimal ones) by maximizing encoding speed.

I agree that Fhg speed is pretty impressive with -q0 but I'd like to give the same weapons to Fhg's encoder (HQ mode).
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 #153 –
Also, my test of iTunes settings:

Quote from: Alex B on


Surprisingly the quality options have almost no effect to the encoding speeds. The very small encoding time differences may be caused by other things as well (I did only one pass). I wonder if these settings do anything, even though there was a very small bitrate increase.

The Smart Encoding Adjustments and Filter Frequencies Below 10 Hz options seem to slightly affect the speed so perhaps they actually do something.

... I think the setting names Apple has chosen suggest that the best quality would be achieved @ 128 kbps VBR, Quality: Highest, Stereo Mode: Joint Stereo, Smart Encoding Adjustments & Filter Frequencies Below 10 Hz: enabled.
 

MP3 Listening Test at 128 kbps

Reply #154 –
Quote from: guruboolez on
... Fraunhofer q0/q1 difference: I won't test it on my side (I tried and -bored- I quickly gave up last week). I strongly believe that we should use the switch called “high quality”; even if didn't improved anything according to your test, I didn't lowered the quality either. We should always test the HQ mode and let people use the fastest mode if they're ready to take some risks (even minimal ones) by maximizing encoding speed.

I agree that Fhg speed is pretty impressive with -q0 but I'd like to give the same weapons to Fhg's encoder (HQ mode).

After my test I don't have any preference. Personally, if I would need to encode something really fast I wouldn't hesitate to use the default, faster mode. It didn't show strong regression with any of my test samples. Some samples were slightly worse and some were slightly better in the default mode.

In general, it would be nice to know why -q 1 obviously reduced quality with some of the samples.

Anyway, as I said before, the sample selection is going to be crucial in case we want to make this a fear test. For example, by picking up certain 18 or 20 samples of the 30 samples I tested I could change my overall test results.

MP3 Listening Test at 128 kbps

Reply #155 –
Quote from: Alex B on
Some samples were slightly worse and some were slightly better in the default mode.

I noticed it on my side too.
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 #156 –
I'm interestin in test like Lame vs others encoders  without any speed restrictions.

MP3 Listening Test at 128 kbps

Reply #157 –
I feel we can do this with 2 low anchors: LC-AAC 80 to 112 kbps, AotuvB5 also 80 to 112 kbps. The value needs to be chosen, thats all. This can greately help in finding out to what extent the claims of aac and vorbis are true. WMA 10 pro, nero E-AAC 64 also look good.

the contenders should be Lame, Fraunhofer, Helix, iTunes and the rest mutually decided niche encoders which have proved a lot in the recent months

MP3 Listening Test at 128 kbps

Reply #159 –
Sebastian. Is there any dead line of this discussion? Not hurry but there isn't much activity.

MP3 Listening Test at 128 kbps

Reply #160 –
Well, what we have so far is:

LAME 3.98 -V5
FhG 4.1 mode 4 with the high quality flag set
iTunes 7.4.3.1 128 VBR, highest quality (7), smart & filter enabled

What I still don't know:
Gogo - what setting?
Helix - what encoder, what setting? I have no problem with installing RealPlayer on a VM in case we choose that. The CLI version offers more fine tuning but nobody (not even the developers - contacted them during the last discussion) can recommend anything special, so maybe Real chose the best setting already.

MP3 Listening Test at 128 kbps

Reply #161 –
I second AlexBs setting:
  • Gogo 3.13 -a -b 135
  • Helix CLI -X2 -V60
Gogo is based on Lame 3.88, and Gabriel pointed out already that at that time Lame VBR mode was in a rather early state.
As for Helix I think most members here - if interested in using Helix at all - prefer a CLI version from within foobar or other tools usage than use the Real GUI.
We should't be too ambitious towards the meaning of such a listening test outside of HA.
lame3995o -Q1.7 --lowpass 17

MP3 Listening Test at 128 kbps

Reply #163 –
Sorry, no real opinion about Gogo -q parameter (would have to dig through its source code to be able to answer).

MP3 Listening Test at 128 kbps

Reply #164 –
I'm just reading this thread but haven't seen the actual test results (and couldn't find them with a quick search) bit figure that the test was completed awhile back since the last post to this thread was five months ago - can someone post a link to the test results? Thanks.
God kills a kitten every time you encode with CBR 320

MP3 Listening Test at 128 kbps

Reply #165 –
The test never started.

Now that things got back to normal on my end, I could finally organize the test if people are still interested. However, I could only do so at weekends since I come back at 7 PM from work.

MP3 Listening Test at 128 kbps

Reply #166 –
Quote from: Sebastian Mares on
So people are interested after all in an MP3 test... Problem is that we never agreed on what settings to use for Helix / Real for example.

Could use -X2 -V65 which was used on guruboolez last test and avgs to around 130kbps. But I tried it on a CVS 2005.08.09 build, which I found on rarewares. For some reason it sounds really bad on a couple tracks I tried it sounds like it was encoded on Blade or a old version of L3ENC.
"I never thought I'd see this much candy in one mission!"

MP3 Listening Test at 128 kbps

Reply #168 –
Quote from: Sebastian Mares on
The problem is that not even developers know what to recommend and choosing some "weird" settings without doing listening tests first can lead to unfairness.

Also a lack of documention on all the switches on the Helix encoder does not help at, ATM I found -HF -V150 to sound fine but not transparent, I just trying to look for a low-pass filter switch, to use on V65 and use a low-pass simaler to LAME -V 5 filter, to make it more fair.
"I never thought I'd see this much candy in one mission!"

MP3 Listening Test at 128 kbps

Reply #169 –
Could we not just drop this implementation from the list of contenders?

MP3 Listening Test at 128 kbps

Reply #171 –
To be honest, I would personally use Real instead of dropping the encoder just because we cannot agree on parameters. Real uses Helix and doesn't offer any special settings that might mess things up more than they help.

MP3 Listening Test at 128 kbps

Reply #172 –
I have uploaded a sample that Helix really chokes on at -V65.

Replica Sample
"I never thought I'd see this much candy in one mission!"

MP3 Listening Test at 128 kbps

Reply #173 –
Ye gods! 

LAME 3.97 beats that hollow at VBR -V4 with only an 8% increase in filesize!

Cheers, Slipstreem.