libmad mp3 distortions

[Andriy Gapon]

I can reproduce the following on two very different machines: one is older Intel
CPU/chipset, i386 stable/7; the other is newer AMD CPU/chipset, amd64 head.
When I play certain MP3 files with any player that uses libmad for MP3 decoding,
there are some very loud distortions from time to time. Something like what
happens when too strong signal gets clipped.
Examples of the programs: audacious2, mpg321.
On the other hand, mpg123 plays the same files without any quality problems.

I wonder if anybody else sees this too and if, perhaps, this is a known problem.

I can privately share an MP3 file that demonstrates the problem (upon request).
This is what 'file' has to say about it:
Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 192 kbps,
44.1 kHz, JntStereo

P.S. i am quite surprised, because while googling I've seen that there was a sound
distortion problem with mplayer and in that case they worked around it by
switching to libmad for mp3.

[Alexander Leidinger]

Post by Andriy Gapon
I can reproduce the following on two very different machines: one is older Intel
CPU/chipset, i386 stable/7; the other is newer AMD CPU/chipset, amd64 head.
When I play certain MP3 files with any player that uses libmad for MP3 decoding,
there are some very loud distortions from time to time. Something like what
happens when too strong signal gets clipped.
Examples of the programs: audacious2, mpg321.
On the other hand, mpg123 plays the same files without any quality problems.
I wonder if anybody else sees this too and if, perhaps, this is a known problem.

Have you tried to play it with "madplay -v -a -6"? This will lower the
volume by 6dB. IIRC this is still with the sound before the
conversation to PCM. If this prevents the clipping, then it is normal.
The reason is that because of rounding (and other operations) the
value of a sample can be higher (or lower) than originally. If it was
at the max level before, it can now exceed the max -> clipping.
madplay is following the rules very strictly (and IIRC working with
higher precision and bitsize), while other players have bigger
mathematical errors. This would explain then, why you see this with
madplay but not with other players. The problem I describe is not in
the decoding step, the problem is at the encoding level.

Bye,
Alexander.

[Andriy Gapon]

Post by Alexander Leidinger
Have you tried to play it with "madplay -v -a -6"? This will lower the
volume by 6dB. IIRC this is still with the sound before the conversation
to PCM. If this prevents the clipping, then it is normal. The reason is
that because of rounding (and other operations) the value of a sample
can be higher (or lower) than originally. If it was at the max level
before, it can now exceed the max -> clipping. madplay is following the
rules very strictly (and IIRC working with higher precision and
bitsize), while other players have bigger mathematical errors. This
would explain then, why you see this with madplay but not with other
players. The problem I describe is not in the decoding step, the problem
is at the encoding level.

Alexander,

thanks a lot! madplay -a -6 does indeed produce correct sound.
Bad news: despite the magnitude of configuratios options related to 'gain' and
'pre-amp' in audacious2 (all global, nothing specific to mad plugin), I couldn't
get it work the same way as madplay. Sound gets quieter but the distortions are
not fixed.

[Ariff Abdullah]

On Fri, 18 Sep 2009 14:10:37 +0300

Post by Andriy Gapon

Post by Alexander Leidinger
Have you tried to play it with "madplay -v -a -6"? This will lower
the volume by 6dB. IIRC this is still with the sound before the
conversation to PCM. If this prevents the clipping, then it is
normal. The reason is that because of rounding (and other
operations) the value of a sample can be higher (or lower) than
originally. If it was at the max level before, it can now exceed
the max -> clipping. madplay is following the rules very strictly
(and IIRC working with higher precision and bitsize), while other
players have bigger mathematical errors. This would explain then,
why you see this with madplay but not with other players. The
problem I describe is not in the decoding step, the problem is at
the encoding level.

Alexander,
thanks a lot! madplay -a -6 does indeed produce correct sound.
Bad news: despite the magnitude of configuratios options related to
'gain' and 'pre-amp' in audacious2 (all global, nothing specific to
mad plugin), I couldn't get it work the same way as madplay. Sound
gets quieter but the distortions are not fixed.

It is time for mp3gain/replaygain . You have to retrain your hearing
and listening comfort.

Search for "Loudness War".


--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
and confusing for us idiot ***** users :P ........

... Going with the standard and orthodox
is the death of intellect ..............

[Andriy Gapon]

Post by Ariff Abdullah
It is time for mp3gain/replaygain . You have to retrain your hearing
and listening comfort.
Search for "Loudness War".

Thank you for pointing me in the right direction!
It looks like the files already have Replaygain data in APE format (looks to be
produced by mp3gain).
Unfortunately there were two issues:
1) there seems to be a bug in audacious madplug (MPEG/MP3 plugin), because of
which it doesn't correctly parse APEv2 header;
2) the files also contains another APE header (without Replaygain data) that
confuses some players that do not have the same bug as audacious

Anyway, by "applying" Replaygain parameters to MP3 data iself I became a happier
man :-)
Thanks!

[Alexander Leidinger]

Post by Andriy Gapon
thanks a lot! madplay -a -6 does indeed produce correct sound.
Bad news: despite the magnitude of configuratios options related to
'gain' and 'pre-amp' in audacious2 (all global, nothing specific to
mad plugin), I couldn't get it work the same way as madplay. Sound
gets quieter but the distortions are not fixed.

Probably audacity is doing this after decoding with libmad. At this time
the clipping already happened.

Bye,
Alexander.

[Andriy Gapon]

BTW, something that I've noticed while investigating this issue.

During libmad configure stage on amd64:
...
checking host system type... amd64-portbld-freebsd9.0
...
checking for architecture-specific fixed-point math routines... DEFAULT
configure: WARNING: default fixed-point math will yield limited accuracy
...

We do not specify explicit --enable-fpm option.
configure seems to have some auto detection logic, but it won't properly work on
amd64 platform, probably because linux guys call it differently - from configure.ac:
if test -z "$FPM" && test "$GCC" = yes
then
case "$host" in
i?86-*) FPM="INTEL" ;;
arm*-*) FPM="ARM" ;;
mips*-*) FPM="MIPS" ;;
sparc*-*) FPM="SPARC" ;;
powerpc*-*) FPM="PPC" ;;
# FIXME: need to test for 64-bit long long...
esac
fi

On i386 configure auto-picks "INTEL".