I have tried to encode this song to MP3 for distribution (this is my own song, I composed it) but I find that the encoded song is always ABXable, even if I tried CBR 320, which AFAIK is the highest bitrate for standard MP3. I have tried disable lowpass but that didn't help, the encoded hi-hats sound blurry.

For the record, the Lame version I've tried is v3.97 and v3.98b8. Both -V0 and -b 320. I get straight 20/20 in ABX test because it's so obvious (notice how short the time it took me).

Here are some of my test results:





Is there a way to improve Lame for this sample? Or is it the limit of MP3? I don't find any artifact in other codec (OGG, AAC, MPC) for this sample (except lossyWAV, which is also very easy to ABX but that's off topic) but other codecs are not suitable for distribution. I'd like to put it on a website through flash player but flash only support WAV and MP3.

Here is the sample:
Click to view attachment

Can you point out which seconds you are hearing an artifact? I heard no difference between WAV and V0.

I heard the difference in the hi-hats, right there at the beginning of the song.
Maybe because it's my own song that I can spot an artifact right away.

Yes, there is something wrong with the hi-hats at v0 and CBR 320.
I only did 4 tests, but the problem was pretty clear to me.

All I can hear is some kind of pre-echo. (ABX 8/8). But it isn't annoyable.

Did you master this? The WAV is too aggressive anyway...

Which lossyWAV quality option did you use?

.... and as development is still ongoing, did you use 1.0.0b or one of the subsequent beta versions?

Try using ABR@320, not CBR. Also try encoding in an older LAME version, 3.96 for example.

I use 1.0.1s and I use foobar2000 converter setting from the lossyWAV thread so it is -q 0. The artifect is clearly present at 0.09-0.10 where the drum is sampled repeatly (I don't know how to describe it). The lossyWAV file introduces higher level of hiss. Here is my ABX result:



However, I have running nose today and I feel so dizzy I don't think I can do any test now.



Why would ABR provide better result to CBR 320. Is Lame using difference switch internally?
Which older version version would you suggest and where can I find it. ReallyRareWares seems to have only up to 3.93.1. Anyway, I will have to do a test later because I'm not very well today.

You can find 3.90.3 and 3.96.1 here: http://homepage.ntlworld.com/jfe1205/LAME/. But don't expect too much.

Thanks a lot for your test.
-q 0 sure is a setting full of compromises not really in line with what is intended with lossyWAV.
Something like -q 1.5 is the minimum where good results can be expected.
It should definitely be very good (though not necessarily perfect) when using the --portable quality.
Quality should be perfect with quality setting --standard.
It would be nice if you could try a higher quality setting than -q 0 if you have the time and feel like that.

Back to the topic:
It's quite interesting comparing different Lame versions even though a priori it is not expected that things will improve with older versions as 3.98b8 is very good IMO especially with respect to pre-echo behavior.
In case you give 3.90.3 a try: it may be useful to test the older gpsycho model as well which was often said to have the better pre-echo behavior. You get a gpsycho result when using 3.90.3 -b 320 -h. It would be interesting to see how it compares to the nspsytune result of --preset insane.

If you like to it would also be interesting to see how the Fraunhofer mp3 encoders are behaving. A FhG mp3 encoder is available for instance with WMP11, dBPoweramp, or as a free CLI surround encoder version which can be downloaded from All4mp3 (oh: I've just seen there is new version out if I remember well the version I downloaded recently).

But I'm afraid that with mp3 we have to accept the fact that quality can be restricted even with highest bitrate.

The foobar2000 setting in the thread is my fault - I've amended it to --standard in the thread. Thanks for your ear-time and I hope you shake your illness quickly .

Nick.

Oh, at first I thought the -q setting works like Lame's -V that lower means better. I've just downloaded 1.0.1t and tried the --standard setting and I cannot ABX that, I get like 5/12.



Tried both 3.90.3 and 3.96.1 with CBR 320 (-b 320 -h) and 3.90.3 with --alt-preset insane (3.96.1 gives the same mp3 file as CBR 320). All is ABXable (I got 12/12 for all of them). Then I've tried ABR 320 for v3.96.1 but this time, maybe because I'm ill or because my ears are getting fatigue, I miss once but still got 14/15.

But is it possible for ABR to outperform (quality-wise) CBR at 320?

Here's the result for v3.96.1 ABR 320:





Fraunhofer is far worse. (I use dBPoweramp)




Oh, almost forget, even tried Freeformat at 550 with Lame v3.96.1. I've tried higher bitrate but the result cannot be decoded correctly, always get MAXFRAMESIZE not large enough. Anyway, foobar2000 doesn't support Freeformat so I have to get Lame to decode them first. It's still ABXable and I've got 11/12, here is the result:




So if it's even ABXable at 550, I think maybe this is a killer sample for Lame. Do you think Lame can be further tuned to handle these cases, or is this the limitation of MP3 format itself?

Many thanks for the additional ABX'ing, I'm glad that --standard is still transparent with this sample and it's interesting that the --standard lossyFLAC version comes out at 501 kbit/s.

I know that this isn't an answer and I also find it ABXable, but if you're only distributing the MP3 version then nobody else will have anything to ABX it against, so it won't be ABXable. I personally still find it perfectly listenable encoded with LAME in VBR at -V3. Apart from yourself (and us), who's going to know the difference?

Cheers, Slipstreem.

You did a lot of tests with various encoders, so your sample should be considered a mp3 killer sample.
I think there's always a certain room for improvement (and Lame 3.98 did improve on the very bad pre-echo sample eig), but pre-echo is something where we can't get perfection with each sample.

As far as I've seen it from the posts here your sample is abxable, but it is not really annoying. Guess that's what we can expect at best from such samples.

Thanks for your lossyWAV test using --standard. Glad everything's fine.

Usually not. There's a very slight chance that restrictions on 320 kbps frames (relevant for the newer Lame versions in order to be compatible with WMP11's mp3 decoder) can reduce the effective audio bitrate on certain frames. At least in theory using unrestricted 256 kbps frames can locally produce a higher audio data bitrate than 320 kbps frames.
So using CBR 256 or ABR in the same bitrate region can locally outperform CBR 320.
In practice this is not expected to be of significant relevance. Moreover there shouldn't be a significant audible difference no matter whether you use CBR 256, CBR 320, or ABR with a bitrate in between (with my personal favorite being ABR 270).
And as you've seen going extremely high in bitrate using freeformat doesn't solve your problem. guruboolez encountered the same experience with castanets which he also was able to abx at >400 kbps.

MP3 format has several limitations indeed (for example, length of short block is 192 samples). What can you say about "Everything is green" sample (eig.wv). Does it has the same kind of artifact as your own sample?

Yes, 0:09-0:10 has a sharp pulse sequence that reminds me of "EIG.WV". there is a pre-echo but I don't find it annoying. I wouldn't even notice it was there If I wasn't told.

It seems like a strong brick wall filter was used, since the highest freqs' attacks aren't sharp at all, they're smeared considerably. Still short blocks are used when appropriate, it even trips older versions of lame with --alshort enabled. It probably has something to do with the smeared high freqs playing with psychoacoustic computations with the lower freqs. Then again, maybe I'm taking theories too far, as I often do...

This weekend I bought Magix Cleaning Lab 2007 for little money, and I found the included mp3 encoder quite interesting as it gives an astonishing good result for the very bad pre-echo sample eig.

I used 256 kBit, stereo, encoder quality: highest, padding-mode: ISO padding, and: allow mid/size stereo encoding. Encspot says it's a FhG encoder (fastenc or mp3enc), and - typical for FhG encoders at this bitrate - it doesn't use joint stereo though I explicitly allowed for it. Using 320 kbps BTW yields the usual bad result for eig.

This encoder's result for Enchanting__sample is here.
It would be interesting to learn about the quality. To me personally is fine (but it has been fine with Lame at pretty mediocre bitrate as I'm pretty deaf towards this problem).

Yes, it has the same artifact.



There is an obvious change in the encoded file, it's like it has some filter applied to it. Definitely very easy to ABX and it's not even about the pre-echo thing.

Sorry, looks like Magix Cleaning Lab has some default 'cleaning' active and I didn't manage so far to get rid of it.
I've found a way to circumvent the issue. There's a separate music editor within the software where effects have to be given explicitly. So it's possible to just encode the track. You can use the old link to download the encoding produced this way. Maybe you want to give it a try. I've tried all 'my' problem sample with this encoder, and I'm pretty impressed by the quality.

I still can ABX it, but impressive quality indeed. But I can't ABX it from Lame encoded so I can't say which is better.

Sounds like you're not too much bothered by the in this case restricted quality of mp3. Glad to also hear that Lame's quality seems not to be too bad for you and this sample.

Other than that I've been more in to this software now and the best way to do it is use a batch mode from within Magix Cleaning Lab to do the encodings.
It's all a bit strange however as the results seem again to be a little bit different (they are excellent to me). I've uploaded the result for your track one last time though I don't expect a significant difference.

Interesting, I wonder just out of curiosity how ogg, aac and mpc handle this piece

thx
/me slaps head in keyboard