I have seen no discussion here on the effect of decoders. Case in point:
I have made several comparison MP3 encodes of the Finale of Mahler's Second Symphony.
These were made out of a nagging feeling upon encoding several classical orchestral recordings using EAC/Lame 3.93 first, then 3.92, and finally 3.90.2, settings --alt-preset standard, then --alt-preset extreme, --r3mix, and --alt-preset CBR 256, that something was amiss.

In all three the effect was the same:
In massed string passages there would be a sort of "white cloud" of treble frequencies hovering about the center of the image. In addition, the recordings appear to have lost a lot of "space". The low level background reverberation information that is so vital in reproduction of acoustic instruments wasn't there. What some others in this group have called. "Transparency" Same thing.
There was very little difference between the aforementioned versions of Lame, or preset-settings. Alt-preset extreme was a little better in the "space" department but not much. The sound in general appeared grainy and dry.

I listened to the piece in my Panasonic PV 47 DVD drive, with a Denon 2802 receiver and B&W 600 series speakers, my iRiver MPX350 player with Bose Quiet Comfort headphones, and my computer. Of the three the effect was most pronounced in the Stereo setup, and equally pronounced in the MP350, but almost inaudible in the computer using WMP and BA-635 speakers.

The same recording came through with much better sense of space and much less grainy when encoded using the standard ECDC 5.0 Platinum encoder, which I assume to be a licensed FHG encoder used at 256 kbps. There was no cloud, and stereo imaging was practically indistinguishable from the CD. Of course, the file is 40% larger but we knew that was going to happen.

I recorded the piece again using stereo by adding the -ms to the presets. The white cloud in the center dissapeared, but the imaging problem was still there. The sound was still grainier and dryer than the FHG 256. The file was slightly larger than the alt-preset file.

Given the extensive discussion here on the superiority of Lame and joint stereo, and having read the treatise on how the joint stereo in Lame works, I have no doubt that properly applied it should work correctly and not produce the white cloud or the loss in imaging that I experienced.

I do not know what effect the different decoders could have on this. I have assumed again, that the decoders in both the iRiver and the Panasonic are FHG licensed decoders. What effect could they have?
Is it possible that what I hear is a decoder problem. How do these commercial decoders respond to Lame? or Lame JS?

Would like to hear from all the experts on decoders

Regards

Manuel

Post a clip, otherwhise it is impossible to determine whether this is a real problem, 'bad luck', or simply your imagination (after reading the post I tend to the latter).

Decoders will make no audible difference, unless they have bugs.

No. My imagination is not that consistent. I have made two files of Mahler's Adagietto from Symphony No. 5 one using EAC/Lame 3.90.3 --alt-preset standard and one using ECDC 5.0 FHG 256. Unfortunately I either don't know or can't attach them to this message. I can post them if you will tell me how.

Regards

Manuel

http://mp3decoders.mp3-tech.org/

*WAY* out of date

I believe that most transcoders just use the LAME decoder, but how does this compare to the MAD decoder?

Really?
I think most decoders, although are now of newer versions, still performs basically the same. For instance, the FhG decoder in Winamp has not changed much since 2.666.

Maybe you are right about the info on the mp3 decoders. But some of the other information on the site is clearly out of date. eg. the recommendations in the conclusions on mp3 to audio. [though i may be wrong - I'm a relative newbie here]

There is also no mention of Foobar - which really should be mentioned here.

The Mp3 -> CD audio burning part is clearly missing EAC. It is true that this part should be updated.

Including foorbar2000 is impossible if you check the "last updated" date

BTW, why does LAME skip samples when decoding?
There's a msg reading "Skipping first x samples (Encoder-Decoder delay)".
What is this?

http://www.hydrogenaudio.org/forums/index....topic=11183&hl=

Latest change is (experimental) handling of gaps in 0.7b21. /EDIT\ 0.7b22 has reverted on this \EDIT/
Besides that, last change which affects MP3 decoding quality was at version 0.61a - dithering bugfix.
So, testing 0.667 quality should be safe.

At least it should be better than mpg123...

In fact, they shouldn't change anything if they're already good (perfect).
Winamp 2.666 is good, why should they change it?

http://mp3decoders.mp3-tech.org/intro.html
"However, the MPEG standard sets out the requirement for a decoder exactly – a given MPEG-1 layer 3 stream (typically an .mp3 file on a PC) should always decode to a certain uncompressed digital audio signal (typically a .wav file on a PC). Apart from rounding errors in the last bit (i.e. +1 or -1 on a scale ranging from –32768 to +32767 for 16-bit audio) the output should be exact.
Every decoder should produce the same result. "

Note that if anyone tests FB2K's decoder in the way of David Robinson's decoder test (mp3-tech links above), they should do so with "no noise shaping" dither or no dither and with ReplayGain and clipping prevention turned off and DSP turned off in the diskwriter. FB2K's MPEG layer 2/3 decoder support was based around reasonably good open source libraries, and I have no reason to doubt that it works properly.

You can ftp a sample to:

ff123.net
userid: anonymous@ff123.net
password: use anything you like
upload to incoming directory

after uploading, the incoming directory will not refresh

It is unlikely that you are hearing a decoder difference. People mean different things when they say "consistent." The standard definition in statistics, though, is 95% confidence. So, 9 times out of 10 total trials would qualify at that level, for example.

For the level of subtlety involved in detecting decoder differences, you must make sure that both files are time-aligned (and also volume matched; that probably isn't a problem here).

ff123

Hello, Madman1153

Let me see if I understood you :

You are hearing problems in MP3 files. Since you believe what this board claims (i.e. that these kind of problems should not appear with the alt-preset settings) you ask if they can be caused by the decoder, since the encoder shouldn't cause them ?

1 - Perform blind tests à la ABX. 9 times out of 10, when I hear a problem in the sound, it appear that it is also in the original. Or sometime the difference just vanish as I prepare for the test listening to A and B, or even after the test I see that I got all wrong while I was convinced of the opposite. Only one time out of 10 I succeed and can post a problem sample.
By the way (off topic) what is the probability of getting one ABX success in 10 tests ?

2 - If you can reliably tell the difference in a blind test, then convert your Mp3 into wav using Lame, and burn the wav on CD. If the problem is audible on the CD, it comes from the encoding. Otherwise it comes from the hardware decoder.

I think Garf and FF123 are going too fast. We won't listen to any sample before you run a blind test. It is the rule here.
The FAQ of the board features links to ABX software.
Here's an example of blind test performed without software : http://www.hydrogenaudio.org/forums/index....=75#entry114968

I have alread done the clips, but PIO 2001's suggestion #2 is worthwhile to try. I will do this and post the clips later
Madman

I did Pio2001. suggested testing, decoding the clips I had made of Mahler's Adagietto from the Fifth Symphony - and the resukts were ... TADA!

Almost indistinguishable. I did not detect any clouds or loss of imaging from the LAME encoded clip. THis was not an ABX double blind test, I suspect in a double blind test I would not have been able to tell the samples from each other.

Which leads me to the conclusion that what I heard was either mass illusion or problems with the Panasonic PV 47 and the iRiver MP3 hardware decoders.

Which was my original question.

I also made spectrum graphs from the three samples to compare the frequency response. The LAME --APS graph was essentially flat down to 0 Hz but exhibited a sharp -20dB dropoff at about 16kHz. To my surprise the frequency response of the FHG 256kb/sec was very ragged, with a broad peak at around 400 hz and a 3db/octave bass roll-off starting at about 120 Hz. The FHG also exhibited the sharp drop at 16kHz.

I tip my hat to LAME, but what am I to do about my hardware decoders??

I can post the graphs I made if anyone is interested.

Madman

I'm still wondering about using the Winamp MAD decoder and its disk writer. Does LAME have the same high-precision calculation as MAD?

It's probably not the precision of LAME's calculations that are the issue (they're floating point). It was within one bit of the MAD output, according to David Robinson's mp3 decoder test of that version, I believe (mp3 tech site), and I think it can output in 24-bit resolution, which requires 256 times the precision of 16-bit anyway.

The MAD output differs in the last bit sometimes because of dither. Dither adds deliberate very low level noise to avoid truncation distortion and make the signal behave in a more analogue manner, which is entirely correct and desirable (if done properly - see AstralStorm's doubts about MAD below), though there's still doubt whether anyone can ABX it on 16-bit audio for real music (old MAD challenge thread). In many MP3's other parts of the signal may well usually provide enough variation in the rounding calculation that truncation distortion might rarely a problem.

Like MAD, Foobar2000 also dithers its output for all formats, but unlike Winamp it isn't restricted to working internally at 16 bits, so it theoretically does a better job by only having to dither once (in preparing the signal for the output bit depth, be it 8, 16 or 24 bits).

LAME decoder doesn't attempt to dither the output, so there's the possibility of truncation distortion. LAME decoder also has no option for noise shaping dither, which can reduce the audibility of the dither noise in Foobar2000 and MAD and improve their perceived dynamic range or signal-to-noise ratio (especially good for old 8-bit soundcards!), though noise shaping dither isn't recommended if you ever intend to process the signal further (especially pitch-shifting DJing).

[Edit: Correction of MAD's dither capabilities, see below. I presume that some dither is better than none, but I'm guessing MAD doesn't use the full 0.5 bit dither theoretically required, judging by the concerns below]

Sorry, but MADs dither isn't good (but it's better than no dithering).
Just try it with very quiet sounds with reasonable equipment - weird distortions!
MAD doesn't offer noise-shaped dither.

My apologies, I was mistaken. Good spot AstralStorm!

I haven't seriously used Winamp for a while, and had a mistaken recollection that MAD had dither. I realise now that I'm probably thinking of zZzZzZz's out_ssrc.dll resampling output plugin, which did have good dither (rectangular, triangular, gaussian pdf), as I'd expect from Peter (but only a simple triangular noise shaping option), as I remembered setting up my Mum's old PC with 8-bit soundcard to use dither in Winamp some time ago before I put in an old 16-bit card.