HiMD Renderer - Wrong LAME VBR encoding

[pincholas]

HI! Excuse me if this have been discussed anywhere anytime but I have found no topic related to it.

I'm using excelent Marc's HiMD Renderer 0.54 to convert OMA files to MP3 but I'm afraid Marc's program is doing something wrong when Lame VBR encoding. I have done some testing and let me show you the results.

Size of an oma file for testing purpouses: 57.547.296 bytes

Version of LAME used: 3.97 (lame_enc.dll of HiMD Renderer has been replaced with v.3.97)

This oma file has been encoding with HiMD Renderer + Lame 3.97 dll and it's corresponding wave file also encoded with EAC + Lame 3.97 dll and with Lame 3.97 (exe version) for verifying size.

Case 1. Lame parameters CBR / 224 kbps / q=3

HiMDRenderer mp3 size: 9.136.256 bytes

Exact Audio Copy mp3 size: 9.132.881 bytes

Lame.exe mp3 size: 9.140.508 bytes

Case 2. Lame parameters ABR / 224 kbps / q=3

HiMDRenderer mp3 size: 8.917.120 bytes // final average bitrate: 218kbit

Exact Audio Copy mp3 size: 8.914.803 bytes // final average bitrate: 218kbit

Lame.exe mp3 size: 8.919.132 bytes // final average bitrate: 218kbit

Case 1 and 2 show similar resulting mp3 files, I don't care too much about those small diferences, for me it's ok.

Case 3. Lame parameters VBR / Preset Extreme (V=0) / q=3

Exact Audio Copy mp3 size: 9.151.650 bytes // final average bitrate: 224kbit

Lame.exe mp3 size: 9.155.574 bytes // final average bitrate: 224kbit

And now, let's compare what HiMDRenderer produces with different VBR options:

Case 3.1 VBR / Max 320 kbps / Min 32 kbps / V=0 / q=3

HiMDRenderer mp3 size: 5.929.088 bytes // final average bitrate: 145kbit

Case 3.2 VBR / Max 320 kbps / Min 192 kbps / V=0 / q=3

HiMDRenderer mp3 size: 7.796.864 bytes // final average bitrate: 191kbit

Case 3.3 VBR / Max 320 kbps / Min 224 kbps / V=0 / q=3

HiMDRenderer mp3 size: 9.103.488 bytes // final average bitrate: 223kbit

So, what's doing HiMDRenderer with VBR options? I'm not sure... case 3.1 is so weird!! The closer we can get to EAC and LAME.EXE results is by rising minimun bitrate up to 224 kbps, and that makes no sense.

What's more, mp3 files from case 3.2 and case 3.3 show no bitrate variation when playing with Winamp, info say they are VBR but behave, mainly, like CBR files.

Is Marc's program sending wrong parameters to Lame's dll?

For VBR encoding what Lame needs to know are, mainly, just two parameters:

1) -V n quality setting for VBR. default n=4

0=high quality,bigger files. 9=smaller files

2) -q = 0...9. Default -q 5

-q 0: Highest quality, very slow

-q 9: Poor quality, but fast

For CBR encoding it goes like LAME.exe --preset cbr -q

For ABR encoding it goes like LAME.exe --preset -q

For VBR encoding it goes like LAME.exe -v -V -q

Messing with maximun and minimun birates is no a good idea, imho.

I have tried to override this situation, as I always use Extreme VBR encoding, by using a mod of lame_enc as avaliable form rarewares.com which uses a ini file for Lame configuration but I cannot make it to work, nor with HiMD Renderer neither with Eaxact Audio copy.

No matter what parameters I put on the ini file it always uses Preset Standard.

Anyway, Marc, could you please verify how are you using lame_enc when VBR encoding?

Thanks for your attention.

[marcnet]

There are two VBR algorithms in LAME - Old and new. Perhaps this option is the cause of the inconsistancy between encoding apps and HIMDRenderer.

I am not sure which algorithm HIMDRenderer uses, and what the default on Lame.exe is. I shall investigate further.

[pincholas]

Well, version 3.97 uses OLD method by default, I have read that next version, 3.98, will use NEW method by default. Anyway, I have checked your program with both OLD and NEW VBR methods with similar (wrong) results.

In the other hand, and this is only my humble opinion, I suggest you to simplify the options you show for MP3 encoding. There are thousands of topics on the net about command line parameters for LAME encoding but what is generally suggested is to use presets.

CBR encoding: only bitrate is needed. No more no less.

Example: --preset cbr 'bitrate' OR -b 'bitrate'

ABR enconding: only bitrate, as for cbr, is needed.

Example: --preset 'bitrate'

VBR encoding: only vbr quality is needed.

Example: -V 'quality' --vbr-old (for old method)

Example: -V 'quality' --vbr-new (for new method)

or just use presets

Example: --preset 'preset' (for old method)

Example: --preset fast 'preset' (for new method)

An additional parameters that can be usefull for CBR, ABR and ¿VBR? is quality (-q). Lame 3.97 defaults quality=3 (-q 3) and thou it ranges from 0 to 9 only two values and really usefull, -q 2 (known as Quality High) and -q 7 (known as Quality Fast). So a drop-down with three values, High, Default, Fast should cover all needs. (Default value should not specify any -q value)

I think, imho, that any other option (like max and min bitrate, 0..9 range for quality) will only lead users to confussion.

I hope this may help. Thanks for your attention.

Further reading: http://wiki.hydrogenaudio.org/index.php?ti...ncoder_settings

[marcnet]

The LAME library I use does not use standard command line parameters... its a bit more complex that that via the LAME library SDK.

The LAME options presented to the user via HIMDRenderer are simply copied more or less directly into the LAME library SDK.

I will investigate further into this issue when I get a chance.