Hi,

I've previously used LAME 0.96 with excellent results. I use -V 3 --vbr-new -h , which gives me files around 175 kbps, consistent with the wiki. Since upgrading to LAME 0.97, my files are much smaller, using the same options.

For example, ripping three test songs using LAME 0.96 resulted in 175, 177, 173 kbps. LAME 0.97 now gives me 100, 98, 100 kbps. Trying to isolate the bug, I've tried various permutations of the options, for the first test file, with the following results:

100 kbps:
-V 3 --vbr-new -h
-V3 --vbr-new -h
-V 3 --vbr-new

108 kbps: I don't know why this is different – isn't --vbr-new meant to be default?
-V 3 -h
-V3 -h
-v -V 3 -h

109 kbps:
-V 3

164 kbps: different -V setting.
-V 0 --vbr-new -h

Oddly enough, I get 164 kbps with the least-compressed option (-V 0), a file which is still more compressed than my initial rip (-V 3) using LAME 0.96! This is also much lower than the target 245 kbps from the wiki.

For frontends, I previously used iTunes-LAME (with LAME 0.96), but have tested LAME 0.97 with the lastest two version of iTunes-LAME (2.0.8 and 2.0.9) and also with iLAS. I rip from CD through iTunes.
Mac Mini 1.25 GHz
OS X 10.4.10
iTunes 7.4.2

Any help is much appreciated!

I think you mean versions 3.96 and 3.97.

Something is wrong with the frontend mappings or some option has been enabled that changes quality. Can you try --r3mix with 3.97 and see if the bitrate is right ?

-h with vbr new doesn't do anything.

This is not odd. The least-compressed option normally and logically yields the highest kbps.
Also, the -V0 file is not more compressed than the -V3 file. This is only an illusion. Something else is going on here.

Regards,
Madrigal

EDIT: formatting only

If you could provide some samples (up to 30secs) of those files which still reproduce the problem, we could see if there's really something going wrong, or is jut being more efficient (although the jump is substantial).

It would help also, if you would do an ABX test between one 3.96 and one 3.97 encode, to help identify an audible problem.




@ Madrigal:

I think you didn't read his post correctly... -V 0 encoded with 3.97 is giving him a *lower* bitrate than -V 3 encoded with 3.96, for the same file.

I've had the same experience:
Same file encoded by Lame 3.96 and Lame 3.97 with the same quality settings gives a smaller size with 3.97 (lower bitrate) than with 3.96.

I interpreted this as that 3.97 is capable of packing the same amount of info as 3.96 in a smaller space. The result: same quality for less space. At least I hope that's somewhere near the truth after all, one would imagine 3.97 is an improvement of 3.96.

Sorry it's taken me so long to reply; I think there is some issue with receiving notifications of new posts...

@ Piffles:
I did assume that 3.97 would be more efficient than 3.96, but I thought it was a surprisingly substantial drop in file size. Also, my 3.96 results was consistent with the wiki, which suggested that -V 3 aimed for 175 kbps. I assumed 3.97 would follow these target bitrates rather than audio quality directly.

@ shadowking: --r3mix also resulted in a 100 kbps file. Are there any other tests to see if mappings are ok? I'm not 100% sure if this is what you mean, but I tried two different interfaces with LAME (iTunes-LAME and iLAS), with both returning the same 100 kbps file.

@ [JAZ]: unfortunately, I am currently not in possession of any audio gear which is good enough to identify this differences at this order of compression. (I did work in a studio, but have since moved on.) What kind of sample could I provide? Any kind of music (i.e. can you analyse the meta data directly)?

Thanks to all for your help.

Here is my output for v3 vbr new. sample: http://www.rdrop.com/~mulara/sounds/mike1.wav

V3.97 = 169.7 k
v3.96 = 155.3 k

Please post your results.

I meant if you could provide 30 seconds or so of that concrete track that was showing this problem (the important difference in bitrate)

Also, i asked you if you tried to ABX to find out if the quality was worse or not: http://wiki.hydrogenaudio.org/index.php?title=ABX

Could it simply be some near-mono signals that compress better with 3.97 ??

I've had the same experience. I currently have 478 tracks (mostly rock music) encoded with LAME 3.97 -V 3. Foobar2000 reports that the average bitrate for these tracks is 154kbps. I am happy with the bitrate and I'm not really worried about the quality of these tracks which is why I didn't encode them at a lower -V setting.

@ shadowking:
I attempted compression of your wav file with "-V 3 --vbr-new", resulting in the following:
v3.97 -> 57 kbps
v3.96.1 -> 60 kbps
I seem to have deleted my old copy of v3.96, and could only find this version (v3.96.1) on the net. It still produces 175 kbps files of my original test file (similar to my old v3.96), but compression of your new test file is also surprisingly large now!
As far as near-mono signals go, you may be on to something... my test files were probably mono (Chuck Berry). I'll try a range of other files and report back.

@ [JAZ]:
What I meant was that my current audio equipment was not good enough to identify differences in an ABX test. I will upload some sample files in a few hours.

Something else is interfering. You are using some gui right ?

Try --r3mix -b32 -B320 -mj

@ shadowking:
those latest options also resulted in a small 100 kbps file.

I also attempted compression of a heavily stereo file, just in case. The original (v3.96) compression resulted in a 177 kbps file. Compression with v3.97 resulted in a 178 kbps file! I tested a couple of other files and they seem around the 175 kbps mark as well (and consistent with my previous v3.96 files too)... I suppose mono is the key. I guess I should have tried a few different files previously.

I am still confused as to why we get different results on your sample wav, although those odd results were also replicated by me with v3.96.1. I don't know if that's a good thing. I can upload my file if it would help (any hints on where to do this?).

P.S. I am using a gui, but I (sporadically) run replicates using different GUIs.

You must get the same results otherwise quality is gone for sure. Can you use the commandline instead of the gui ?

I'd like a screenshot of :

lame --r3mix mike1.wav

LAME version 3.96.1 (http://lame.sourceforge.net/)
CPU features: MMX (ASM used), SSE
Using polyphase lowpass filter, transition band: 17960 Hz - 18494 Hz
Encoding /home/ng/Desktop/mike1.wav to /home/ng/Desktop/mike1.wav.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
101/103 (98%)| 0:00/ 0:00| 0:01/ 0:01| 3.0326x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 1] *
64 [ 0]
80 [ 0]
96 [ 0]
112 [ 0]
128 [ 11] **********
160 [ 89] %*******************************************************************************
192 [ 1] *
224 [ 1] *
256 [ 0]
320 [ 0]
average: 155.3 kbps LR: 1 (0.9615%) MS: 103 (99.04%)

Hmm... I'm not sure that I can use the command line. I'm not 100% sure on LAME via command line, but I don't think I can. I'm using a mac, and don't have XCode installed. I guess command line would be the best way to debug.

Do you have any other hints? Otherwise, I could probably get the 1GB XCode in a week or two...

Something tells me the gui is mapping the Vx presets wrong.. Please post your version of mike1.mp3 to megaupload

www.megaupload.com

copy the URL they give you and post it here.

My v3.97 "-V 3 --vbr-new" file is here.

File Name : sus-mike1.mp3
File Path : C:\windows\profiles\ng\My Documents\Desktop\sus-mike1.mp3
Subsong Index : 0
File Size : 112KB (115 015 bytes)
Last Modified : 2008-01-27 17:37:24
Duration : 0:15.940 (351469 samples)
Sample Rate : 22050 Hz
Channels : 1
Bitrate : 57 kbps
Codec : MP3
Codec Profile : MP3 VBR V3
Encoding : lossy
Tool : LAME3.97
Tag Type : id3v1
<ENC_DELAY> : 576
<ENC_PADDING> : 1619
<MP3_ACCURATE_LENGTH> : yes
<MP3_STEREO_MODE> : mono


Obviously the gui is changing things like samplerate and stereo. You need to a different gui or to force:

-V3 --vbr-new --resample 44 -mj

note -mj not --mj

It could also be a lowpass problem:

-V3 --vbr-new --resample 44 -mj --lowpass 18

hmm.. I had a look at your original wav, and it seems that this was already mono and 22.05 kHz?

Yes you are correct, My apologies. Your sent file was identical to mine.

So what should we conclude, user error?

We should try a stereo sample..then.

No problem. Does that mean the other compression variations also resulted in identical bitrates to your files?

ok, here is a stereo sample. I get the same bitrate (167 kbps) with both 3.97 and 3.96, using -V 3 --vbr-new.

I got 167.9 / 167.7 k with 3.96.1 / 3.97

Hmmm. I guess there's something a bit odd here. Do I understand correctly that our compressed files should match *exactly* in size, etc.? I've uploaded my file anyway, which was compressed with v3.97 using -V 3 --vbr-new.

Did we actually have discrepancies in size in the previous mono examples (of mike1.wav), or were they actually ok?

Cheers!

I also get a match with up.wav - 170 k

Sorry, I don't quite understand. Are you saying that the compressed file that I uploaded (up.mp3) is identical to your compressed file?

They are the same bitrate, though I didn't do a bit comparison yet.

Bitrates should be quite close, but files could be different. Different compilers are producing some slightly different binaries, which are not producing bit-identical results.
(that's what happen when you are using floating point)

Okay, thanks. That pretty much means the unexpected results must have arisen from much better compression of mono signals by v3.97.

Great, at least I know my copy of LAME is working!

Thanks for all your help, guys.
Cheers shadowking, I really appreciate all of your help!!