I have some MP3’s that were ripped at 320 CBR and I wanted to re-encode them to --preset fast standard, with tags. I tried using Monkey's Audio and I noticed that the quality was much lower than if I used EAC to decompress to wav and then re-encode (in which I lost my tags, which is why I decided to try Monkey's). I tried to figure out what was going on and noticed that when I used lame with --decode to create the wav file (which is what Monkey's Audio was doing) the wav file was different from the one I created using EAC. After encoding both wav files to MP3 using the same --preset fast standard, the one using lame's decoder had a lower average bitrate than the one created from EAC. Can anyone explain why it seems lame's decoder is creating lower quality wav files? I even tried foobar and it gave me the same lower bitrate results.
Thanks

Are you sure that in both cases (Monkey's and EAC) you are dealing with a decoded mp3, and are not in fact comparing a Monkey's decoded mp3 against an original EAC rip ? Different decoders do not necessarily yield bit-identical wav files, but the differences should not normally be as great as what you are describing.

Regards,
Madrigal

In one example I tested, I started out with a 320 CBR mp3. I used EAC to decompress it to wav. I then used EAC to compress it to mp3 using the recommended options (-V 2 --vbr-new). I ended up with an mp3 at around 200kbps.
I then took that same 320 CBR mp3 and used monkey to conver it to .ape. Then I used that file in monkey to convert it to mp3. Result was about 180kpbs. That's when I knew something wasn't right. I saw it was using lame.exe to decode to wav and then convert that wav to .ape. So I used lame.exe to decompress that 320 CBR mp3 to wav with the --decode option. I then used EAC to decode that wav file to mp3 and came up with the same 180kpbs, which made me conclude that it had something to do with lame's decoding to wav. I then installed foobar and did the same thing converting that same 320 CBR mp3 to -V 2 --vbr-new and came up with the same 180kbps, so I assume it was using lame.exe to decompress as well as re-compress.
I also used CDex to decompress the mp3 to wav, and used EAC to convert that wav to mp3 with the same options and came up with a 200kpbs mp3, which also made me conclude that there was something going on with lame's decode option.

IIRC, EAC (and possibly CDex too?) use windows ACM mp3 codec to decompress? If so, there might be some differences in decoded wavs. But such big difference in the resulting mp3 bitrate is very strange indeed.

(...Edit: it was a stupid drunk idea here. deleted...)

Can you check more specifically how much of the difference is there between the EAC-decompressed and lame-decoded wavs.
(this may be tricky if two decoded wavs are not aligned)

What version of lame.exe are you using?

Foobar doesn't use LAME to decode mp3s, so you can throw that idea out. I wonder whether lame --decode uses replaygain information when decoding (ie, the decoded wav will have its volume adjusted). That would be one possible explanation of why the resulting mp3s had a lower bitrate. (Also, foobar's converter/diskwriter would apply replaygain if those tags were present and the appropriate options were enabled)

Out of curiosity I just decoded a random mp3 with foobar0.8.3 and with lame.exe 3.97b1. The output was identical up to 1 LSB, as it should be.

(by the way, had to align the wavs: foobar file had 576 more padding samples in the beginning, and lame-decoded file had some extra padding samples in the end)

Here's the version of Lame I'm using:
LAME 32bits version 3.97 (beta 2, Nov 27 2005)

I tried doing a simpler test that would be easier to understand.
I took my original 320 CBR mp3 and made 3 wav files with 3 different programs: lame with --decode, EAC decompress, and CDex decompress. This gave me a wav file for each. I then used the same Lame.exe and converted each one using --preset fast standard. The result was as before. The mp3s from the EAC and CDex wav files were both at 200kbps, and the wav file from lame compressed to only 187kbps.
I used EncSpot to analyze each mp3 and these are my percentages of frames in each bitrate:

(Bitrate) (EAC & CDex) (Lame)
128 4 4
160 19 24
192 36 50
224 23 14
256 11 4
320 4 ~1 (can't see the %)

As you can see, the lame mp3 has a higher percentage of its frames in lower bitrates than the other mp3s.

Edit: I also used foobar to decompress it to wav and then used lame.exe to compress it with the same options as the others and got bitrate percentages that are just about the same as those in the Lame column.

It is hard to tell anything conclusive from the mp3 bitrate distribution.
I may guess that the wavs decompressed by EAC and CDex had some high-frequency noise added for some reason.

It would be more informative if you could examine the differences not bewteen mp3s, but between the decompressed wavs.

oh, and which version of EAC ?

0.95 Beta 3 (Aug 26th 2005)

I finally found out what the problem was! I noticed that while lame was decoding, it said "skipping initial 1105 samples (encoder+decoder delay)". Well I found the options to make it stop doing that and I finally was able to have the lame decoded wav file produce the mp3 at 200kbps. Now the question becomes how do I stop foobar from doing this when I convert it?

I still don't understand what's going on...


What options? Are you using some special compiled lame.exe or regular one?

I found a site that explained why it was skipping the initial 1105 samples when I was doing --decode. It said that in order to stop lame's decoder from skipping them you had to use the commands:
lame --decode --decode-mp3delay -529

That stopped it from skipping the first 1105 samples. I think the mp3 was ripped without a delay so lame was actually skipping 1105 samples of important data and thereby throwing off the encoding process. And it seems foobar is doing the same thing (skipping some samples assuming delay) and I would like for it to not do that since I have no delay in the mp3s I am trying to re-encode.

The delay is built into the mp3 format, you can't encode without it. All you're doing is breaking gapless decoding. Whatever is causing the difference isn't what you think it is.

I can confirm Speed's finding.
Took an mp3 - decoded with plain vanilla lame, and another one with the delay option - then encoded both to -V 2. The mp3 encoded from vanilla-lame-decoded is about 20 kbps smaller than the mp3 encoded from delay-option-decoded.
And the bitrate distribution is different in a way similar to what Speed showed.

This is really really strange!..
Why does it make such a big difference??? It is only a small number of samples, only a couple of mp3 frames. Why the other frames are effected so much???

I should add: both these two decoded wav files are absolutely bit-identical except for the 1105 delay (which is zero silence in my case).
So basically, you take a wav file, add a few zero-samples in the beginning, and you get two totally different mp3 files!

Conclusions we may draw at the moment:

1) decoding of lame.exe is perfectly OK.

2) encoding with lame.exe 3.97b1 -V 2 --vbr-new produces very much different files only due to a few null-samples in the wav. (up to 20 kbps different average bitrate, and different bitrate distribution).


One would think that mp3 encoding, epsically quality based VBR encoding, should be more robust w.r.t insignificant null-samples.

I'm going to try older version of lame and different settings.

lame 3.90.2 APS shows similar differences. The bitrate distribution is strikingly different again.

Well... Maybe it is old news for lame developers, but for me it is just amazing!

By the way, all these mp3s sound the same to me, but I'm not the best person to hunt for artefacts.

Then, assuming that the mp3 should be transparent regardless of the offset-delay of the wavs, then an interesting question is:
if these mp3s have such variation of average bitrate, then perhaps the encoder could analyze the wav, try different sample offsets and encode it with the offset which produces the smaller mp3 file -- huge bitrate saving!
In theory...