IPB

Welcome Guest ( Log In | Register )

Sample specific discussions: sample #2, Public MP3 listening test @ 128 kbps
Alex B
post Nov 26 2008, 14:45
Post #1





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



As I said in the test results thread I would like to discuss about each sample separately. The overall results were tied and all encoders seem to be equal. In closer inspection it seems that each encoder had problems with at least some samples.

It would be useful to analyze each sample separately in order to find out what kind of problems the testers noticed and how severe they are. The discussion would help to understand the test results and probably also help the codec developers in their work. This has not been done before, but I think the outcome would be valuable.

Some testers added comments to the result files. Those comments are useful if the tester intends to revisit a saved session later. Unfortunately the comments in the result files are quite hidden and they cannot be easily evaluated and compared. That's why I didn't add comments to my results (expect the some unfinished, partially wrong comments in one of my first result files - I meant to delete them, but I forgot to do that.)

This thread is for the Sample #2. Please try to keep the discussion on topic. If you want to discuss about any other sample feel free to start a new thread for it. I am hoping that eventually we'll have 14 separate threads - one for each sample. I'll add them by myself if others have not done that before me.


Sample #2 - Vangelis_Chariots_of_Fire

The overall results:



The results from the individual testers:



I sorted the testers so that the most critical tester is the first on the left.

Since Sebastian already removed the test sample links I uploaded the first two sample packages to RapidShare so that anyone can listen to the actual samples: http://rapidshare.com/files/167567675/Samples_01_and_02.zip (7.5 MB)


I'll check my results and relisten to the samples later today. I'll post my personal comments after that.

This post has been edited by Alex B: Nov 26 2008, 15:11


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
 
Start new topic
Replies
Alex B
post Nov 26 2008, 22:42
Post #2





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



My results:
iTunes: 3.80
LAME 3.98: 2.60
Low anchor: 1.40
FhG: 2.80
LAME 3.97: 2.20
Helix: 3.10
Lame 3.97 suffers from the sandpaper problem.
LAME 3.98 has pronounced high frequency hiss. (I don't know why that bothered me so much when I tested this sample. The other encoders seem to have similar hiss problems. I would probably now give LAME 3.98 something like 3.3 - 3.5)
FhG is noisy and has some sandpaper problem too.
Helix is constantly a bit distorded.
iTunes is the cleanest. I didn't notice the problem Pio2001 mentioned. (I still don't, even though I tried)


The bitrates from Sebastian's bitrate table:
CODE
iTunes   LAME 3.98.2   l3enc (Low Anchor)   Fraunhofer   LAME 3.97   Helix
-----------------------------------------------------------------------------
117      149           128                  121          126          110


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
robert
post Nov 29 2008, 16:57
Post #3


LAME developer


Group: Developer
Posts: 783
Joined: 22-September 01
Member No.: 5



QUOTE (Alex B @ Nov 26 2008, 22:42) *
My results:
iTunes: 3.80
LAME 3.98: 2.60
Low anchor: 1.40
FhG: 2.80
LAME 3.97: 2.20
Helix: 3.10
Lame 3.97 suffers from the sandpaper problem.
LAME 3.98 has pronounced high frequency hiss. (I don't know why that bothered me so much when I tested this sample. The other encoders seem to have similar hiss problems. I would probably now give LAME 3.98 something like 3.3 - 3.5)
FhG is noisy and has some sandpaper problem too.
Helix is constantly a bit distorded.
iTunes is the cleanest. I didn't notice the problem Pio2001 mentioned. (I still don't, even though I tried)


The bitrates from Sebastian's bitrate table:
CODE
iTunes   LAME 3.98.2   l3enc (Low Anchor)   Fraunhofer   LAME 3.97   Helix
-----------------------------------------------------------------------------
117      149           128                  121          126          110

By just looking at the bitrates from all encoders and LAME's output, it seems LAME uses alot more short blocks on this sample than other encoders. Maybe too much pre-echo tuning triggered by /mnt? Without using short blocks, LAME would encode it at about 123 kbps, which would be more in line with all others.
Go to the top of the page
+Quote Post
halb27
post Nov 29 2008, 22:57
Post #4





Group: Members
Posts: 2414
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (robert @ Nov 29 2008, 17:57) *
...Maybe too much pre-echo tuning triggered by /mnt? Without using short blocks, LAME would encode it at about 123 kbps, which would be more in line with all others.

Just a thought:
I know it would make Lame usage more complicated (not mentioning development), but would be a specific option useful taking into account the specific needs of individual users?
For instance I am pretty insensitive towards pre-echo but I dislike tonal distortions. And I don't care about problems which are more more or less related to metal or hard-rock music or hard-core electronic music. People like /mnt may feel the other way around. Encoder development has always to make compromises. While the last sentence will remain true for any useful encoder it might be advantegous for advanced users to have an option which takes some care of specific needs.
Is it possible?

This post has been edited by halb27: Nov 29 2008, 23:00


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th April 2014 - 12:12