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

MP3 at 128kbps public listening test

Reply #75 –
Quote
Would you consider Gogo as well? I've heard a lot of people recommend it because its fast and probably better then fhg, but i have no idea how good it is.

I have no doubt that Gogo is worst than FhG.

Quote
Are you absolutely sure iTunes does not use one of the fhg codecs listed above?

I think that iTunes is using an evolution of SoundJam. But if there are doubts, we could ask developpers.

MP3 at 128kbps public listening test

Reply #76 –
Quote
I think fastenc should be CBR to compare the quality against lame -ap128 most of what I have read & tested shows fastenc is the best FhG encoder & performs better using CBR.

f123 what are your thoughts about an optimal FhG encoder & which settings?

Perhaps a pre-test would be in order to try to determine if FastEnc CBR is significantly better or worse than FastEnc VBR.

If anybody has the iTunes encoder, try encoding the clip:

http://lame.sourceforge.net/download/sampl.../main_theme.wav

with both iTunes and FastEnc.  FastEnc has a problem with this sample, and so should iTunes, if it is FastEnc based.

ff123

MP3 at 128kbps public listening test

Reply #77 –
Quote
I have no doubt that Gogo is worst than FhG

So let's test it and see then...
//From the barren lands of the Northsmen

MP3 at 128kbps public listening test

Reply #78 –
Quote
QUOTE 
I TOTALLY AGREE!



OMG! Caps lock.

You are very observant:) But don't worry, eventually you'll have keyboards with that ability in Brazil too...
//From the barren lands of the Northsmen

MP3 at 128kbps public listening test

Reply #79 –
Hmm... can't seem to get this quote thing to work...

MP3 at 128kbps public listening test

Reply #80 –
Quote
Quote
I have no doubt that Gogo is worst than FhG

So let's test it and see then...

Yeah, let's do Gogo!!

MP3 at 128kbps public listening test

Reply #81 –
I was under the impression that it was a well known fact that GOGO was made for speed as opposed to quality.  I for one think it should be left out.  However for the sake of #8 TOS I will conduct a quick listening test if anyone argues this.
gentoo ~amd64 + layman | ncmpcpp/mpd | wavpack + vorbis + lame

MP3 at 128kbps public listening test

Reply #82 –
I've had people tell me 192 gogo sounds the same as LAME.  I think it should be tested.  Particularly if its so bad, it'd be quite easy to test then.

MP3 at 128kbps public listening test

Reply #83 –
OK I'll start testing right now.
gentoo ~amd64 + layman | ncmpcpp/mpd | wavpack + vorbis + lame

MP3 at 128kbps public listening test

Reply #84 –
Thinking about uploading a sample from one of my Caruso cylinder recordings. After all, we need to know which 128 bit rate mp3 encoder encodes the hiss and distortion of these recordings with the most faithfulness.   
you will make mp3's for compatibility reasons.

MP3 at 128kbps public listening test

Reply #85 –
Both encodes were very easy to tell from the origonal WAV once I got used to it, but to be honest I couldn't tell the one encoded with LAME --alt-preset cbr 128 from the one encoded with Gogo.  Perhaps Gogo has more merit than I thought or, perhaps, I wasn't testing a good clip, I don't know.

A file: E:\Program Files\Encoding\schism.wav
B file: E:\Program Files\Encoding\Samples\Tool - Lateralus - 05 - Schism - 2001 - Metal.wav

15:47:59    1/1  p=50.0%
15:48:34    2/2  p=25.0%
15:49:04    3/3  p=12.5%
15:49:19    4/4  p= 6.2%
15:49:29    5/5  p= 3.1%
15:49:40    6/6  p= 1.6%
15:49:50    7/7  p= 0.8%
15:50:00    8/8  p= 0.4%
15:50:12    9/9  p= 0.2%
15:50:28  10/10  p< 0.1%

A file: E:\Program Files\Encoding\schismlame.wav
B file: E:\Program Files\Encoding\Samples\Tool - Lateralus - 05 - Schism - 2001 - Metal.wav

15:55:12    1/1  p=50.0%
15:55:19    2/2  p=25.0%
15:55:51    3/3  p=12.5%
15:56:07    4/4  p= 6.2%
15:57:54    5/5  p= 3.1%
15:58:07    6/6  p= 1.6%
15:58:20    7/7  p= 0.8%
15:58:27    8/8  p= 0.4%
15:58:35    9/9  p= 0.2%
15:58:43  10/10  p< 0.1%

WinABX v0.23 test report
12/11/2003 15:59:36

A file: E:\Program Files\Encoding\schism.wav
B file: E:\Program Files\Encoding\schismlame.wav

16:04:24    1/1  p=50.0%
16:04:40    1/2  p=75.0%
16:05:57    2/3  p=50.0%
16:06:13    2/4  p=68.8%
16:10:11    2/5  p=81.2%
gentoo ~amd64 + layman | ncmpcpp/mpd | wavpack + vorbis + lame

MP3 at 128kbps public listening test

Reply #86 –
Quote
Both encodes were very easy to tell from the origonal WAV once I got used to it, but to be honest I couldn't tell the one encoded with LAME --alt-preset cbr 128 from the one encoded with Gogo.  Perhaps Gogo has more merit than I thought or, perhaps, I wasn't testing a good clip, I don't know.

i don't need to respond then  ... this is why i think we should compare lame -aps agains 128, and against the others ...

MP3 at 128kbps public listening test

Reply #87 –
OK, let me try to say this one more time:

I won't feature different bitrates at this listening test.


Regards;

Roberto.

MP3 at 128kbps public listening test

Reply #88 –
Quote
Quote
Both encodes were very easy to tell from the origonal WAV once I got used to it, but to be honest I couldn't tell the one encoded with LAME --alt-preset cbr 128 from the one encoded with Gogo.  Perhaps Gogo has more merit than I thought or, perhaps, I wasn't testing a good clip, I don't know.

i don't need to respond then  ... this is why i think we should compare lame -aps agains 128, and against the others ...

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.

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.

ff123

MP3 at 128kbps public listening test

Reply #89 –
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.

ff123

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?

edit: typo
gentoo ~amd64 + layman | ncmpcpp/mpd | wavpack + vorbis + lame

MP3 at 128kbps public listening test

Reply #90 –
Quote
If anybody has the iTunes encoder, try encoding the clip:

http://lame.sourceforge.net/download/sampl.../main_theme.wav

with both iTunes and FastEnc.  FastEnc has a problem with this sample, and so should iTunes, if it is FastEnc based.

ff123

Currently I don't have access to the iTunes encoder & the d/l is 20mb but just in case someone does here is the fastenc encoded version.

MP3 at 128kbps public listening test

Reply #92 –
Quote
    * From: Bill Kincaid
    * Subject: Re: [mp3encoder] MP3 encoder for iTunes?
    * Date: Tue, 21 Oct 2003 09:46:34 -0700

Don't bother.  The iTunes MP3 encoder was written pretty much from scratch,
based on the ISO reference source in distribution 10, as LAME was.  I know,
I was the principal author (it was originally shipped in SoundJam, for
anyone who remembers that far back).

It has been heavily tweaked over the years and doesn't bear much resemblance
to dist 10 anymore...

-Bill Kincaid
iTunes


http://www.mail-archive.com/mp3encoder@min...g/msg01901.html

MP3 at 128kbps public listening test

Reply #93 –
Quote
Currently I don't have access to the iTunes encoder & the d/l is 20mb but just in case someone does here is the fastenc encoded version.

This encode is actually what I refer to as the super slow FhG codec (the -hq option within fastencc.exe).  When I say "FastEnc" I really mean the fast FhG codec.  I'll post an encode of that later.

ff123

MP3 at 128kbps public listening test

Reply #94 –
Thanks for the info, harashin


Edit: I think Harashin pretty much clarified, but here's a real fastenc encode. The command line used was:
fastencc main_theme.wav main_theme.mp3 -br 128000

http://pessoal.onda.com.br/rjamorim/main_t...astencc_128.mp3

MP3 at 128kbps public listening test

Reply #95 –
Quote
Thanks for the info, harashin


Edit: I think Harashin pretty much clarified, but here's a real fastenc encode. The command line used was:
fastencc main_theme.wav main_theme.mp3 -br 128000

http://pessoal.onda.com.br/rjamorim/main_t...astencc_128.mp3

LOL,

Will the real FastEnc encode please stand up?

Roberto, you used fastencc.exe with default quality, which is the buggy (loss of stereo separation) fast codec.

Here is the real fastenc encoding:

http://ff123.net/export/main_theme_fastenc.mp3

which I made with Cool Edit Pro 2.1, using cbr, high quality option.

ff123

MP3 at 128kbps public listening test

Reply #96 –
Quote
Thanks for the info, harashin


Edit: I think Harashin pretty much clarified, but here's a real fastenc encode. The command line used was:
fastencc main_theme.wav main_theme.mp3 -br 128000

http://pessoal.onda.com.br/rjamorim/main_t...astencc_128.mp3

your right rjamorim.

I rated:

main_theme_fastenc__128_-hq, Good

main_theme_iTunes_128, Bad

main_theme_fastencc_128, Worst

Both iTunes & fastenc have a problem with this sample. Would the -hq switch be used with fastenc in your test?

MP3 at 128kbps public listening test

Reply #97 –
And just for fun, here are the listening results showing that FastEnc (FhG fast codec) messes up on this sample:



ABC/HR Version 0.9b, 30 August 2002
Testname:

1R = D:\junk\main_theme_iTunes_128.wav
2R = D:\junk\main_theme_fastenc.wav
3R = D:\junk\main_theme_slowenc.wav

---------------------------------------
General Comments:

---------------------------------------
1R File: D:\junk\main_theme_iTunes_128.wav
1R Rating: 4.0
1R Comment:
---------------------------------------
2R File: D:\junk\main_theme_fastenc.wav
2R Rating: 2.8
2R Comment: very flangy near the beginning
---------------------------------------
3R File: D:\junk\main_theme_slowenc.wav
3R Rating: 3.5
3R Comment: a bit fluttery in the beginning; slightly worse than 1
---------------------------------------
ABX Results:

Edit:  "slowenc" is fastencc.exe using the -hq switch.  I see that my listening results differ from westgroveg's on the iTunes version, but perhaps that's because my high frequency hearing is not all that good.  iTunes spectral view looks like it has dropouts between 13 and 15 kHz, which typically translate into stuff that some people hear.

MP3 at 128kbps public listening test

Reply #98 –
Quote
Both iTunes & fastenc have a problem with this sample. Would the -hq switch be used with fastenc in your test?

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

MP3 at 128kbps public listening test

Reply #99 –
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.

Edit:

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.

Well rjamorim will have the last word but I think it would be good to compare with lame, one too many times I hear people say "why use FhG (at 128) when lame is better" I'd love to stick it in thier face.