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: Autumn 2006 Listening Test (Read 141591 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Autumn 2006 Listening Test

Reply #75
As low anchor it's OK, but not as contender. Decide between Blade and Shine. I would go with Shine.


Hi. I'm still running into new material encoded at Blade 128 so anything that might help to stop its use would be useful. It should make a good low anchor. Shine would too but this is used rarely it seems.


Autumn 2006 Listening Test

Reply #77
Hi. I'm still running into new material encoded at Blade 128 so anything that might help to stop its use would be useful. It should make a good low anchor. Shine would too but this is used rarely it seems.


Blade was already put to shame 3 years ago. I think that's all the argument you need to provide to people willing to listen, as I don't think its quality improved ever since 


I agree with Sebastian, it would be awfully cool to test l3enc 1.0, to see how quality improved since the very first encoder. I always wanted to use it as anchor, but on every test people somehow convinced me to use something else.

Autumn 2006 Listening Test

Reply #78
Roberto, could you ask your Real connections what encoder settings they recommend?

Also, Gabriel, what do you suggest for LAME?

BTW, the encoders featured are going to be: l3enc, LAME, Gogo, iTunes, Helix and WMP FhG. Time to discuss settings now.

Autumn 2006 Listening Test

Reply #79
I tried the oldest version of l3enc a while ago to see the improvements of the MP3 formats over the last 10 years.

L3ENC 0.99a still works but it leaves a pop sound on the begaining of the MP3, I have not tried the other versions through.
"I never thought I'd see this much candy in one mission!"

Autumn 2006 Listening Test

Reply #80
L3ENC 0.99a still works but it leaves a pop sound on the begaining of the MP3, I have not tried the other versions through.


I think it leaves some ancillary crap at the beginning of the file. If the same thing happens on 1.0, it would be wise to chop the first few samples

Autumn 2006 Listening Test

Reply #81
I tried the oldest version of l3enc a while ago to see the improvements of the MP3 formats over the last 10 years.

L3ENC 0.99a still works but it leaves a pop sound on the begaining of the MP3, I have not tried the other versions through.

l3enc v. 1.00 has the same problem. This click makes mp3 files that are encoded from wave source files unsuitable for testing purposes. It makes the measured track volume levels incorrect even if the beginning of the file is excluded in the used ABC/HR configuration. However, raw pcm works fine.

I added l3enc v.1.0 samples (from wave & pcm) here: http://www.hydrogenaudio.org/forums/index....st&p=420360

BTW, l3enc v. 1.0 uses joint stereo, bit reservoir and switches between long and short blocks. It does not sound worse than the other bad encoders with this sample. I guess it is better than Shine.


Autumn 2006 Listening Test

Reply #83
l3enc v. 1.00 has the same problem. This click makes mp3 files that are encoded from wave source files unsuitable for testing purposes. It makes the measured track volume levels incorrect even if the beginning of the file is excluded in the used ABC/HR configuration. However, raw pcm works fine.

Couldn't it be that the encoder always expects raw pcm and that the click is then the as audio encoded wav header?
"We cannot win against obsession. They care, we don't. They win."

Autumn 2006 Listening Test

Reply #84
Did you guys use -wav for encoding?

Quote
1.1 PCM audio input file
The first command line argument specifies the name for the PCM audio
data file. Version 1.00 of the encoder accepts either raw PCM audio
data files or PCM audio data files in RIFF/WAVE format as used by
Microsoft Windows. The samples must be 16 bit signed integer values.
The sampling rate must be 44.1 kHz.
 
A) raw PCM audio data
    By default the input file is assumed to contain raw PCM audio data.
    Stereo audio data is input in interleaved format, the first channel
    beeing the left channel.
      <sample #1 channel #1> <s. #1 ch. #2> <s.#2 ch.#1> <s.#2 ch.#2> ...
    Mono audio data has the format
      <sample #1> <sample #2> <sample #3> ....
    Whether the input file is treated as mono or stereo audio data is set
    by the encoding mode parameter (1.3). Default is stereo.

B) RIFF/WAVE format
    If the '-wav' option is specified, the input file is assumed to contain
    16 bit PCM audio data in RIFF/WAVE format as used by Microsoft Windows.
    Audio parameters are extracted from the Wave header and checked against
    the settings of the encoder. If not supported options are found
    (e.g. 8 bits/sample), the encoding process is aborted. The encoding
    mode (mono or stereo) is determined by the settings in the WAVE header.

Autumn 2006 Listening Test

Reply #85
Actually, the -wav switch didn't work. I had to remove it for making the encoder work with a standard wave file.

However, making pcm copies of the wav samples should not be a problem. I did it with WaveLab.

Autumn 2006 Listening Test

Reply #86
Hmm, true - it says it doesn't understand the format.

OK, I use Audacity to remove the header of my Jethro Tull sample and encoded using l3enc. In this way, I don't have to remove audio samples from the test samples.

Autumn 2006 Listening Test

Reply #87
what about "--abr 128" with Lame?


Autumn 2006 Listening Test

Reply #89
We already proved that setting was transparent. I'd like to test -b 128...

Autumn 2006 Listening Test

Reply #90
I hate to argue but -V 5 --vbr-new is not transparent to everyone.

Still, I think it is appropriate to conduct a 128kbit test using samples at 128kbit.  I don't think it's appropriate to allow one contender to use more than 128kbits to encode a sample and not another because it's CBR.

If it's a test based on quality settings, call it as such.  Reserve 128 kbps for contenders @128 kbps.

...then I suppose there's a case for and against including ABR.

Autumn 2006 Listening Test

Reply #91
I think it'd be interesting to see LAME at 128 CBR.  I think it's well proven that the VBR algorithm is excellent, but how does it stand up without it?

Autumn 2006 Listening Test

Reply #92
Well, this would mean to tie LAME's hands. Also, one argument for running this test will lose its strength: most people who use -V5 --vbr-new wanted to see how faster codecs perform at similar settings. l3enc being CBR only is not a big problem, since it's also supposed to be the low anchor. As for iTunes - developers probably focused on tuning CBR and then moved to AAC because CBR is most popular for their target group.

Autumn 2006 Listening Test

Reply #93
My interest for a MP3-listening-test-only is not very high, but my interest for a MP3 test using CBR or ABR is really low. I'd personally focus on VBR performance of various MP3 encoders. List of possible contenders allowing VBR:
- LAME
- Helix
- Fraunhofer Fastenc
- iTunes
- gogo

It's not really surprising but these encoders are also the most interesting MP3 encoders available. I don't really see the point of testing them at an unefficient setting. If we force LAME to use ABR/CBR then we should logically force all other competitors to use the same kind of setting (otherwise the test will look as a very dubious one).

If I had to perform myself such test (as a personal exercise), I would:
1/ select all encoders mentioned above
2/ build a bitrate table to see if they all offer a setting close to 128 kbps and of course which one may work [three encoders are finely tunable then it shouldn't be a problem; LAME has -V5 which correspong to ~130 kbps; iTunes is maybe harder to include for this reason]
3/ think about the samples
4/ think about anchors


I would try to avoid VBR/CBR confrontation (and as I said, I don't consider a CBR-only test as a useful solution). I'd tend to forget the idea of making a "popular encoders" listening test for that reason (assuming that one at least would be CBR only, like WMP encoder IIRC).

It's just my personal point of view on this subject.


Autumn 2006 Listening Test

Reply #95
If we force LAME to use ABR/CBR then we should logically force all other competitors to use the same kind of setting (otherwise the test will look as a very dubious one).
...
I would try to avoid VBR/CBR confrontation (and as I said, I don't consider a CBR-only test as a useful solution).

Exactly!

I have no problem with a VBR 128-ish test, but I do have a problem with being concerned about tying Lame's hands but not being concerned with tying the hands of the other contenders.  This test does not compare codecs with "similar settings" rather it's quite the contrary.

But if you're going to run a 128-ish VBR test, don't call it 128 kbps.

Autumn 2006 Listening Test

Reply #96
iTunes is said to perform better at CBR than VBR. Forcing iTunes to use VBR was one of Roberto's mistakes in his test.

And people used to repeat LAME's poor performance with VBR at ~130 kbps until well-grounded listening tests proved the opposite
Problem with the mentionned listening test isn't VBR by itself, but the choice of setting (112 kbps + VBR IIRC) which lead Roberto to include iTunes encodings at a significantly lower bitrate (119 kbps on average for 'difficult samples' when bitrate should be higher than 128 kbps using VBR on such material).
I may be wrong and the choice of CBR instead of VBR would make sense if VBR settings are not tuned enough. But are there proofs for this?

 

Autumn 2006 Listening Test

Reply #98
But if you're going to run a 128-ish VBR test, don't call it 128 kbps.

But you can call it as a ~130 kbps listening test as long as all tested settings are leading to ~130 kbps in the long term (e.g. by publishing complete bitrate tables including several hours of various kind of music).