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: LAME 3.98.2 -r flag error (Read 3709 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.98.2 -r flag error

Okay, lets start from the beginning. Sorry for the ensuing giant wall of text; I'm a little drunk.
For the longest time I have been trying to rip MP3s in LAME and have been getting the same damned problem. At the start of every file there was this very audible click. Almost like a bad popping sound from some old vinyl. I started downloading some really poorly done precompile from a shady site (I'm reformatting that computer soon) and got so annoyed I actually installed VS .Net to compile LAME for myself.
No matter what I always got this damned click. Hardware made no difference.

The whole time I'd been tweaking flags trying to fix it, and improve quality. Now before solving this problem my flags looked like this:
-r -s 44.1 --bitwidth 16 -V 0 -q 0 --replaygain-accurate --clipdetect --priority 3 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d
(Note: EAC to LAME)

I was trying -V and -q as likely suspects, as they actually did something.

Now I know LAME will auto detect the raw PCM input that -r denotes, but at the time it seemed more intelligent to just tell it that the CD was PCM at 44.1kHz and a bitwidth of 16.
Just made sense to not have it detect this.

Long story short -r, for whatever reason, causes the output file to start with a freaking loud popping sound.

Also I think -r is actually slower than having LAME detect input on it's own.
FML.

Anyways, just thought I'd give everyone here a heads up.

LAME 3.98.2 -r flag error

Reply #1 –
It’s happening because you’re telling LAME that something that isn’t raw PCM is raw PCM.

“It’s not a bug, it’s a feature.”

LAME 3.98.2 -r flag error

Reply #2 –
Just remove "-r -s 44.1 --bitwidth 16" switches because EAC doesn't send raw data to LAME.
Also "--replaygain-accurate --clipdetect --priority 3" switches are quite useless IMO.

LAME 3.98.2 -r flag error

Reply #3 –
Almost all of these switches are either totally useless (-q0, -replaygain-accurate, --clipdetect) or simply unnecessary.

-V0 %s %d

This is all that is really necessary since EAC can tag mp3 files.

LAME 3.98.2 -r flag error

Reply #4 –
Quote from: NeoRenegade on
It’s happening because you’re telling LAME that something that isn’t raw PCM is raw PCM.

“It’s not a bug, it’s a feature.”

Ahh, that will teach me to gloss over the research. I was under the impression .wav was PCM. Stupid me.

Also; do --replaygain-accurate --clipdetect and -q0 actually do nothing? They seem to have documentation behind them.

LAME 3.98.2 -r flag error

Reply #5 –
Just to clarify, wav files nearly always consist of a header plus PCM data. A RAW PCM file is just the PCM data, no header. By adding the -r switch you were telling lame that ALL of the contents of the wav file were PCM data, so the header was encoded as though it were more audio data, making a loud noise at the start.

LAME 3.98.2 -r flag error

Reply #6 –
1) LAME calculates track replaygain value and stores it in LAME header in mp3 file. It slows encoding down, and almost all programs never use this value. It can be better to use --noreplaygain instead of --replaygain-accurate --clipdetect.

2) for LAME 3.98 there is no difference between -V0 and -V0 -q0.