Hydrogenaudio Forums > LAME 3.98 bad quality with replaigain-accurate switch ?

Full Version: LAME 3.98 bad quality with replaigain-accurate switch ?

Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech

JonTHn

Aug 14 2008, 17:31

Hello,

I was converting some files of my FLAC collection in MP3 with LAME 3.98 binary from rareware for OSX.

And for the conversion I use the commandline

CODE

-h -V 0 --replaygain-accurate ...

And I noticed for a song from Queen "Bohemian Rapshody" that the end of the song has many artifact (if that's the name of this 'noise') and in a strange way without "replaygain--accurate" these artifacts are gone.

Has someone any idea what's going on ?

Here are the samples :

Moderation: Links removed.

I did not ABX anything, these artifacts are really easy to hear moreover the full encode of this song has many more.

Nick.C

Aug 14 2008, 18:31

Could it be that the Replay Gain information has been tagged to the end of the file and your player does not recognise it as a tag and "plays" it instead?

JonTHn

Aug 14 2008, 18:45

I tried 2 players : Toolplayer (OSX) and fb2k under Wine. And I got the same output with the twice.

And I can recognize the song but it doesn't sound good a.k.a not at all transparent.

Also I saw that with replaygain-accurate the avg bitrate for the sample (the last 40seconds of this song) is 144k but without it jumps to 200k.
And for the complete song with replaygain-accurate I get 211k and without 236k

robert

Aug 15 2008, 13:02

If there is some problem with LAME, it should happen with any file. I can not reproduce your problem here. In case mpglib and lame were configured with different meanings for mpglibs data type REAL, then this could be a source of trouble.

[JAZ]

Aug 15 2008, 13:24

Mmmm... so it looks we're dealing with a problem with the OSX compile, with the mpglib that is able to decode FLAC, which shows a problem when using the --replaygain-accurate setting. Is it?

If so, robert, how come the analysis of replaygain can affect the encoded bitrate at all, as per JonTHn's post?

robert

Aug 15 2008, 13:51

Since when does mpglib decode FLAC?

When using replaygain-accurate, the just encoded mp3 data will be decoded by mpglib and the resulting PCM gets replaygain analyzed. If there is something misconfigured, there could be a buffer overflow corrupting data.

JonTHn

Aug 15 2008, 14:17

So I tried to to roll my own build of lame and I get a 32bit version instead of the 64bit version from rareware (I didn't try to get a 64bit version)

And with the 32bit version I don't get this issue with the replaygain-accurate switch.

Here again a short clip sample (~10s) to hear the problem. Hope it doesn't break TOS.

http://rapidshare.com/files/137514823/accu...64bits.wav.html

And while my start file is a FLAC version I first decode it to WAV and there after i encode it into mp3

[JAZ]

Aug 15 2008, 14:24

QUOTE (robert @ Aug 15 2008, 14:51)

Since when does mpglib decode FLAC?

Ouch!!!! I just confused mpglib with libsndfile!

2Bdecided

Aug 15 2008, 14:35

Oh dear, that's clearly audible!

Can you cut the original file down to ten seconds, encode it, and still get the problem? If so, you could supply that cut down original for others to test.

Cheers,
David.

JonTHn

Aug 15 2008, 14:42

QUOTE (2Bdecided @ Aug 15 2008, 05:35)

Here is approximately the same ten seconds.

http://rapidshare.com/files/137520050/original.wav.html

And with this sample I can reproduce the problem.

/mnt

Aug 15 2008, 15:27

omg, there is a drop out and warbling like artifact at mid 0:02 to mid 0:03. But the orignal sample starts early then the lossy edit, which makes doing a fair ABX kinda arkward.

2Bdecided

Aug 15 2008, 16:21

/mnt,

I don't think it's worth ABXing something this obvious.

I asked for the sample so that other people could try encoding it and report if there were similar problems when encoding on their machine/build.

Cheers,
David.

robert

Aug 16 2008, 10:24

@krmathis
How was the 64 bit version of LAME configured?

JonTHn

Aug 20 2008, 16:51

I tried to compile a 64bit version with a command-line like such :

CODE

./configure CC='gcc -arch x86_64 -Wconversion -mmacosx-version-min=10.5 -Wshorten-64-to-32 ' CXX='g++ -arch x86_64' F77='gfortran -arch x86_64' FC='gfortran -arch x86_64'

with the help of this webpage : http://developer.apple.com/documentation/D...-CH208-BHCHDAFB

And also compiled a 64bit version of LAME 3.97 with the same command-line.

With the 3.97 version I get no artifacts (at least from what I can hear) whereas still the same problems with the 3.98 version.
And also I found a new sample that get the same problems (Pachelbel - Canon D) and this time it's clearly audible at the beginning of the track.

Is there anything more I can try ?

Slipstreem

Aug 20 2008, 18:27

I suppose you could just stick to your 64-bit compile of LAME 3.97. There have been no group tests to suggest that 3.98 gives any significant advantage over 3.97 yet.

Cheers, Slipstreem.

robert

Aug 21 2008, 00:20

QUOTE (JonTHn @ Aug 20 2008, 17:51)

I tried to compile a 64bit version with a command-line like such :

CODE

./configure CC='gcc -arch x86_64 -Wconversion -mmacosx-version-min=10.5 -Wshorten-64-to-32 ' CXX='g++ -arch x86_64' F77='gfortran -arch x86_64' FC='gfortran -arch x86_64'

I assume you get the same problem when using --replaygain-accurate. Can you send me your config.log and config.h files?

JonTHn

Aug 21 2008, 15:57

QUOTE (robert @ Aug 20 2008, 15:20)

QUOTE (JonTHn @ Aug 20 2008, 17:51)

snip-snap 64bits....

I assume you get the same problem when using --replaygain-accurate. Can you send me your config.log and config.h files?

Yes when using replaygain-accurate the bitrate goes down. Like this :

standard replaygain :

CODE

jonthn$ frontend/lame -h -V 0 ../Pachelbel\ -\ Canon\ In\ D.wav ../no_accurate.mp3
LAME 3.98 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding ../Pachelbel - Canon In D.wav to ../no_accurate.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
   411/411   (100%)|    0:00/    0:00|    0:01/    0:01|   16.201x|    0:00
32 [  1] *
40 [  0]
48 [  0]
56 [  1] *
64 [  0]
80 [  0]
96 [  0]
112 [  0]
128 [  8] *****
160 [ 27] ***************
192 [111] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
224 [250] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
256 [ 12] %%%%%%%
320 [  1] %
----------------------------------------------------------------------------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  209.6       90.5   9.5        99.6   0.2   0.1
Writing LAME Tag...done
ReplayGain: +15.4dB

replaygain-accurate :

CODE

jonthn$ frontend/lame -h -V 0 --replaygain-accurate ../Pachelbel\ -\ Canon\ In\ D.wav ../accurate.mp3
LAME 3.98 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding ../Pachelbel - Canon In D.wav to ../accurate.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
   411/411   (100%)|    0:00/    0:00|    0:00/    0:00|   25.108x|    0:00
32 [204] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
40 [ 42] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
48 [ 32] %%%%%%%%%%%%%%%%%%%%%%
56 [ 29] %%%%%%%%%%%%%%%%%%%%
64 [ 34] %%%%%%%%%%%%%%%%%%%%%%%
80 [ 44] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
96 [ 11] %%%%%%%%
112 [ 11] %%%%%%%%
128 [  4] %%%
160 [  0]
192 [  0]
224 [  0]
256 [  0]
320 [  0]
----------------------------------------------------------------------------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
   48.3       90.5   9.5        99.6   0.2   0.1
Writing LAME Tag...done
ReplayGain: +15.4dB

@robert : I've sent the files you've requested via PM.

@Slipstreem : Yes I can use 3.97 but I would also like to find where is the problem for 3.98 or at least help to achieve that goal

krmathis

Aug 21 2008, 20:36

QUOTE (robert @ Aug 16 2008, 11:24)

@krmathis
How was the 64 bit version of LAME configured?

Its been a while, but I am quite sure I used these flags (using GCC 4.0.1):

CODE

--enable-static --disable-shared CFLAGS="-O2 -march=nocona -pipe -arch x86_64"

rbrito

Aug 22 2008, 05:05

QUOTE (robert @ Aug 20 2008, 20:20)

QUOTE (JonTHn @ Aug 20 2008, 17:51)

I tried to compile a 64bit version with a command-line like such :
(...)
Is there anything more I can try ?

I assume you get the same problem when using --replaygain-accurate. Can you send me your config.log and config.h files?

I can try a 64 bit version on Linux (only 32 bit MacOS X here, sorry). I will try to post the results that I get, but I have a very bad hearing

. Just to isolate the problem, it would be a good thing if people using x86-64 versions of Windows could also post their results, so we can rule out the 64-bit thing.

Let's see if the problem is something related to Apple's instrumented GCC compiler or not (keep in mind that they make changes that are only effective on their platforms).

Regards, Rogério Brito.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.