LAME 3.98.2 VBR bitrate test, all -V settings in 0.5 step increments Options

[Alex B]

Over three years ago I tested the LAME 3.97b1 VBR bitrates (link). For that test I gathered a set of 25 various "reference" tracks. The tracks were specifically selected so that they could more or less represent an average large media library of pop/rock/jazz etc genres. Since then the same set has served well in many occasions. During the preparations of the new public 128 kbps VBR MP3 listening test I gathered another set of classical tracks.

Now I have tested all LAME 3.98.2 VBR settings (in 0.5 step increments) using these two reference sets. For this test I encoded 1050 MP3 files (21x50). I analyzed the files with EncSpot Pro v.2.1 and prosessed the exported data with Excel.

Here are the results:

Some general details: (the frequency values are kHz)


Bitrates "Various":


Bitrates "Classical":


Average Bitrates:




The test tracks:


EDIT:
The classical track #4 has a slightly incorrect name in the table. It should be "Berlin Radio Symphony Orchestra - Mahler, Symphony No 8, 2. Ewiger Wonnebrand".

The source data is available here: http://www.hydrogenaudio.org/forums/index....st&p=601002 (Excel sheet)

This post has been edited by Alex B: Dec 3 2008, 11:03

[guruboolez]

Excellent and useful work. This table should appear on the wiki.

On my own classical music test set (bigger: 150 tracks from different discs / 16 hours of music), results on the few settings I tested before are very similar:
-V5: 133.55 kbps (+2.7 kbps)
-V4.5: 145.36kbps (+2.8 kbps)

[Alex B]

On my own classical music test set (bigger: 150 tracks from different discs / 16 hours of music), results on the few settings I tested before are very similar:
-V5: 133.55 kbps (+2.7 kbps)
-V4.5: 145.36kbps (+2.8 kbps)

Interestingly the average values that EncSpot reported directly are even closer to your values:
Classical -V5 133.1 kbps
Classical -V4.5 144.7kbps

I noticed that the average values calculated by Excel always differed slightly from the EncSpot averages. Probably that is caused by rounding. EncSpot may internally use greater precision than it shows for individual tracks. I could have used the EncSpot averages, but it would have looked odd if the average values could not have been verified by calculating them from the given track values.

In any case this kind of a test can only give a rough estimation, so the exact precision does not matter that much.

This post has been edited by Alex B: Nov 24 2008, 20:20