Ive been trying many different settings with Lame encoding to get the best sound from my cd/mp3 player.
But this is not where i found an apparent problem.

The problem happens only on a couple of particular settings, one of which i have
noted and can reproduce .
Here are the settings Im using:
lame.exe -q 0 --vbr-new -V 0 -b 256 -B 320
the wave file im encoding is one I got from a website which was made for testing
mp3 encoders. In the encoded mp3 in a waveform view it has a few 'mounds',
where the original wav is a completely straight line. [ the flaw is most obvious in
waveform view ] in a spectrum view it looks like some anomaly mainly effecting
the 100Hz-800Hz region, and it is very slightly audible [thats why I called it
a 'small' problem]
the flaws are obvious at these 3 places:
@0.370sec, @2.452sec, and the biggest glitch is @2.988sec

This is my first post here, i hope these links are allowed.
The original WAV
Resulting MP3

Maybe Im doing something wrong,
but these seem like perfectly normal settings to me.
Ive tried it with joint-stereo option on [ -m j ], Filter off [ -k ] and also [ -F ]
..the same results.

edit P.S the [ -k ] option doesnt work on 3.94beta, it wont even encode the file
with this switch set.

I found this problem on Lame 3.93.1 first a couple of days a ago, then tried it on
3.94beta to see what happens, still same.
Switching to --vbr-old DOES fix the problem, but at the price of about 2.5x the
processing time, the problem doesnt happen in CBR 256, or CBR 320. so it seems
to have something to do with the new vbr alg. only.
I hope this is helpful for guys working on developing lame, its an excellent
encoder

Effect

Uh...... has it occured to you to just use --alt-preset insane rather than that commandline? Sure, it won't be VBR, but it will provide better sound quality and hardly larger files.

Yes,
this isnt a setting that I am likely to use, but I do use VBR,
and it is possible to imagine that with different material (wav files) being encoded with different bit rate settings, that these type of problems will also occur, just that
this setting and wav file happens to flag the problem.

Effect
PS the -k option seems to only be a problem when using --vbr-new

that's a pretty whacky command line, indeed.

@Effect,

Several helpful pointers to consider...

1.) If you are looking to encode with the highest possible quality, use the --presets, not homemade command lines. The --presets have been tuned with quality in mind. --preset standard is usually 99% transparent to most listeners and results in bitrates of ~200kbps. This will give you a VBR encoding of higher quality than anything you will get from your commandline. If you want extra assurance, try --preset extreme, though you will most likely not be able to hear a difference.

2.) Psychoacoustics is about sound, not graphs. A graph can look great, i.e. like "a straight line" and still sound like absolute shit, and vice versa. Little about an encoder's efficiency can be inferred from a graph without a corresponding listening test. Can you actually HEAR the problem you describe? Moreover, can you detect a difference in a blind comparison (e.g., not just "I think I hear a difference"). If not, it is probably of no concern.

3.) Never use the -k switch, as it disables all filtering, which will cause ringing. Also, in 3.94b, -q3 is the default for high quality, not -q0, which is an experimental mode; don't use -q0. Again, see suggestion #1.

Hope this has been of some help.....use the "search" function to learn more, and happy encoding!

I have now tried encoding with the options:
Lame.exe -m j -V 0 -b 256 -B 320 -q 3 --vbr-new

It still makes these anomalies, only more of them, and in different parts of the file.

I will look at using presets, but just thought this was worth discussing on because it may help the developers.
Effect

Well you will have to wait and see what the LAME developers say, but I doubt it is usful testing whacky command lines. Just use the good settings --alt-preset standard . . . . or did they make it --preset standard this time? Whatever.

Did you discern the anomalies by comparing graphs, or comparing the encodes to your original wavs by ear?

EFFECT: Lame is designed to give the best quality WITH --PRESETS and NOT WHIT YOUR CUSTOM COMMAND LINES!!! So DON'T USE THEM AND STICK WITH PRESETS...hope you understand now

Effect, obviously you've reported your findings because you want to help improving lame. Thanks for that. There are some points that make your report less useful than it could be, some of them are already mentioned. I'll summarise:

• Lossy encoding of audio is aimed be as close to the original as possible audibly, not visibly, so comparing graphs is rather useless.
• Taking reports like yours seriously means spending valualbe time (especially for developers). To increase the chance that this spent time is a valuable 'invenstment", it's necessary that someone who reports problems,
  • checks his playback chain (DSPs like Winamp EQ disabled, make sure that no clipping occurs by using replaygain, use resampler to 48kHz on playback if soundcard used resamples internally in a crappy way etc.)
  • performs double blind tests (ABX) (details see FAQ)
  • reports as detailed as possible where the difference is audible and what it sounds like
  • provides a lossless compressed sample of the original (as you've done).
• Lame's --alt-presets (or --presets for 3.93.1 and later) have been tuned for best possible quality. It's recommended to use them. If you run into problems with custom commandlines most likely noone will pay much attention.
• The goal is to give best possible quality on real music, not on artificial problem samples. I can't tell how useful your sample is as I don't know of "real" music containing similar sounds, though.

All these points have been discussed multiple times here, most (if not all) of them are covered by the FAQ.

Regarding the "question" of whacky command lines,
the last settings i gave as example:
Lame.exe -m j -V 0 -b 256 -B 320 -q 3 --vbr-new
were all settings you can set in
RazorLame, except for the "--vbr-new"
I believe --vbr-old is the default for the encoders at this version.
switching to vbr-old with all the same switches gives no problem.

But im sure if I was developing this software eventually I would want to get
any bugs out of the vbr-new, because it is more than 2x faster to encode, yet
seems to be similar in quality.
Maybe not now, but eventually this information might be useful to developers.

tigre, i can see your point with this sample being artificial, but on the other hand
there are some types of music that can have square waves much like what is
causing some of the problems for the encoder here. (eg techno)
As for the audibility of the problem, it is very subtle, and I believe I can hear
the difference, but I havent done a double blind test yet.

anyway, lets see what the developers say.

If you suggest that someone should use the presets you should also recommend that he use them together with a tested version of the lame encoder (3.90.3 as of now). 3.94b seems to behave somewhat differently and has not been thuroughly tested yet. You can not expect to get the same results.

Effect: please do a proper double blind test to verify that you actually hear a difference especially since the difference is subtle as you say. As you can see, people won't bother with the actual problem until you do.

Guys, have you noticed, that Effect uses 3.94, where everything is "preset like" (most usual switches are mapped to presets)? Also, he stated that the problem is audiable.
Proper ABX tests would still be useful though. And may be trying "fast" presets could give the same result -- they use new vbr, I guess.

-Eugene

ok, after great demand, ive put in some time and made another test wav
which more clearly highlights the problem, yet has a peak value of -6dB.
(so as to reduce the chance of it being a clipping problem)

AND Ive done 2 double blind tests using the suggested WinABX prog.
AND I used less "whacky" command lines to still create similar
flaws which I think even the tone deaf could hear.

here are links to the new test files:
Original WAV file
Good MP3 [using default vbr-old]
Not so good MP3 [using vbr-new]

the command lines used to make the 2 mp3s are
lame.exe -V 0 -b 128 -B 320
lame.exe --vbr-new -V 0 -b 128 -B 320
in that order.

I did 2 sets of ABX tests on myself
Test 1, had 15/15 correct for comparison of .wav to vbr-new.
Test 2, had 15/15 correct on comparing the 2 mp3 files.

Regards Effect

I have listened to your files and easily abxed both against the original and against each other. And yes, vbr-old sounds better than vbr-new.

Either way, you are pretty much screwed with mp3 here. The artifact is still abxable at alt-preset insane and it won't get much better with mp3. It's just a limitation of the format that it can't handle such sharp impulses very well. A wonderful display of the Gibbs phenomenon.

On a side note: there are also at least two other things which don't like these impulses: your tweeters and your ears. Handle with care.

Gecko yes vbr-old seems as flawless as any good mp3 encoder.

eltoder good thinking, I have now tried the fast presets:
--preset fast standard
and --preset fast extreme,
and it does create the same problems encoding my last test tone:
Original WAV file
..it looks as though "fast" does invoke vbr-new.

The good news is I havent had 1 flaw from vbr-old yet.

Effect

I would be interested to know how MPC handles this sample. I'd test it myself, but I'd rather hear from those that are better trained in these matters.

I just tested the sample from this post with mpc 1.14 at q5 xlevel (dunno if I am better trained than you, indybrett). I thought the mpc file sounded like it had been lowpassed. I was certain of it and abxed away. When I unhid the results it turned out I had been guessing. --> To me mpc is transparent on this sample.

You're STILL using WHACKY COMMAND LINES! FFS!

You HAVE TO USE --PRESET STANDARD!!! WAKE UP!

@ Fr4nz : Not only your two posts in here were pretty rude, but also your 2nd post was completely unnecessary, as you seem you've missed the post that is 3 places before yours.

Also, since your posts are separated by two days, I wouldn't say that you're "just in a bad mood today", and that's why I reply.

This is a knowledge community, and we want to know. We do NOT want just to be told this and that. We know the presets are tuned, ok, but LAME is envolving, concretely, this thread is about LAME 3.94b.
If we know the presets are ok and "the only thing to be used", then, why is LAME being changed? huh? If we don't need it, why is it being done? Why should we test it if we know we have the presets?
That's pretty nonsense, right? So, next time you open your mouth, Please, wait a few seconds and realize what you're going to say.

Thanks.

It's worth noting that in LAME 3.94, Gabriel has made the presets the default. I.e. -V2 is now the same as --preset standard. I believe the best way to improve LAME is to try a default command line ("lame -V0", for instance) and if any bugs are found, report any command lines that may fix them.

FWIW, I did a quick test.

LAME 3.90.3 -aps was easily ABXed
Vorbis GT3B1 -q6 I was not able to ABX

I maybe way off base because I haven't been following 3.94 development too much becuase I've been way too busy, but aren't the presets not even being worked on yet and therefore regular command lines supposed to be used for testing at this point? Or is that 4.xx that I'm thinking of?

You're rather talking about 4.xx. 3.94 has been worked on and tested here somewhat during alpha stage, including presets (mostly lower bitrate than standard though). Therefore testing (with real music and/or known problem samples) especially preset standard (and higher) would be a good idea to find out how it performs compared to recommended lame version. I'm not sure though if developers would be interested in the results right now.

Gecko said:

I can hear the artifacts in all settings Ive used so far,
BUT that isnt what Im talking about.
What Im talking about are anomalies that are intermittent along the same repetitive wave cycle, and can be corrected even by using a lower cbr setting, or
by using the "non-fast" presets
here are the problem settings, YES PRESETS ! :

--preset fast standard
--preset fast extreme

Here is the test tone I used:
Original WAV file

Have a listen, especially try some lower cbr settings anyone, and tell me if you
think this result Im getting with the presets mentioned above is due to a limitation
in the format, I cant see how.

Effect

Yeah, I was making a more general statement. Sorry, if I didn't express myself clear enough. I can abx your sample at alt-preset insane without difficulty. I don't know why the fast presets sound worse than the regular presets (or vbr-old vs vbr-new for that matter), but in general the fast presets are considered to be a tad lower in quality. You just discovered an extreme case where this is true.