Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lame3100g, a functional extension (Read 14407 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame3100g, a functional extension

I know, alpha versions can't be recommended, but due to the very promising experiences with 3.100a2 so far I couldn't resist porting 3995f to this 3100g variant of 3.100 alpha2.
I personally don't care too much about the alpha state and will use 3100g for several CDs I have to encode. I want to share this version so everybody can try. You can download lame3100g from here.

What’s the functional extension?

It offers additional VBR quality settings -V5+ to -V0+ which cover the average bitrate range from ~176 to ~300 kbps.

What is it good for?

Lame’s moderate VBR quality settings like -V5 or -V4 usually yield a very good quality. That’s why many users are happy with these settings. Sometimes however tracks contain spots which are not encoded well. Many users want a better quality also for these rather rare events. From current experience Lame3.100 alpha2 seems to scale well quality of tonal problems with -Vn level, but temporal resolution can still be an issue.

-Vn+ uses -Vn as the encoding basis, but adds a certain amount of brute-force safety by forcing audio data bitrate to a target bitrate which depends on -Vn+ level. Moreover care is taken to always provide maximum possible audio data space for the encoding of short blocks which are used when the encoder thinks it is appropriate for a good temporal resolution.

Emphasis is on issues with temporal resolution, but tonal problems are tackled as well.

In a sense -Vn+ combines the quality advantages of both VBR and CBR.

Recommendations

Users who don’t like rather obvious issues in their music even when they’re rare but who also care about filesize are best to choose from -V5+ to -V2+ according to their needs.
Average bitrate for pop music goes from ~176 kbps (-V5+) to ~224 kbps (-V2+) in steps of 16 kbps.
Best care of temporal resolution is taken even with -V5+. For a significant potential for improving tonal issues -V3+ (~208 kbps) or better is recommended.

Users who don’t care much about filesize but much more about universal top quality are best served by using -V1+ (~256 kbps) or V0+ (~300 kbps), or anything in between.

Installation

lame3100g.exe was compiled with Visual C++ 2010. For this reason it is necessary to install the Microsoft Visual C++ 2010 Redistributable Package vcredist_x86.exe. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=8328

lame3100g.exe uses the fast and lossless mp3packer tool internally to squeeze the otherwise unused bits out of the mp3 file. You can download mp3packer from http://www.hydrogenaudio.org/forums/index....st&p=282289. Put mp3packer.exe into the same folder where lame3100g.exe is located. Many thanks to Omion for this great tool.
In case there is no mp3packer.exe in lame3100g.exe’s folder lame3100g.exe will work, but the mp3 files will be somewhat larger than necessary.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #1
I know, alpha versions can't be recommended, but due to the very promising experiences with 3.100a2 so far I couldn't resist porting 3995f to this 3100g variant of 3.100 alpha2.

And here, I was just getting ready to ask you to do precisely that  Thanks, as usual, halb27!
I'm reripping my albums to FLAC right now but will try some 3.100 -V0+ encoding later and let you know what results I have.

EDIT: Have the LAME authors ever explained why they don't just include your functional extensions in the main binaries?

lame3100g, a functional extension

Reply #2
Have the LAME authors ever explained why they don't just include your functional extensions in the main binaries?

No. I guess it's a question of priorities, and robert is mainly improving the psy model.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #3
I'm considering an ABC/HR test of your extension, but which version should I test? 3100g or 3.99f?
If I were to test lame3100g, I'm going to use:

Encoder,Option,Average bitrate of samples I'll use,Average bitrate of albums
3100g V2+ 235.0k 223.1k
399.5  V1  227.5k 224.6k
398.4 CBR 224.6k 224.1k
Helix V146 221.3k 225.2k
Blade CBR 224.1k 224.0k
I'll be free from 2013-01-07, so I'm going to start the listening test around that day.

And one more thing. I'd be happier if I could use commands like -VBR224, rather than to use a magic number like -V2+, even when I sometimes get 220kbps, 232kbps, or 199kbps.
Is it possible to implement the function?

lame3100g, a functional extension

Reply #4
And one more thing. I'd be happier if I could use commands like -VBR224, rather than to use a magic number like -V2+, even when I sometimes get 220kbps, 232kbps, or 199kbps.

Perhaps a better way to do this would be to key -V0+ through -V5+ to each standard frame size.  EG -V0+ is keyed to ~320kbps, -V1+ to ~256kbps, -V2+ to ~224kbps, etc.


On another note, halb27, I wanted to notify you of some strange behavior.  If I pass the option --lowpass -1 -V0+, encoding fails.  But -V0+ --lowpass -1 works as expected.

lame3100g, a functional extension

Reply #5
a) If it's up to me, I prefer lame3100g over lame3995f, but it's all because I beleive 3100a2 has major overall advantages compared to 3.99.5 despite its alpha status, and because eventual minor flaws of the alpha state (in which I don't beleive) are overcome by the principles of the functional extensions.

b) A setting -VBR<kbps> would suggest a universal target bitrate for this setting. Average bitrate of the track depends on the specific track however, even though the bitrate variation of the functional extension is smaller in many cases than the original VBR method. Especially, average bitrate is genre dependent. So to me a VBR setting which suggests a target bitrate doesn't make sense.
I had listening tests in mind when deciding upon the details of version 3.100g, and designed the average bitrate for my test set of various pop music to vary in 16 kbps steps for -V5+ to -V2+ from 176 kbps to 224 kbps. It was only a minor change compared to the details of 3995f, but this way -V4+/-V2+/-V1+ are adequate candidates for 192(224/256 kbps average bitrate listening tests.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #6
...Perhaps a better way to do this would be to key -V0+ through -V5+ to each standard frame size.  EG -V0+ is keyed to ~320kbps, -V1+ to ~256kbps, -V2+ to ~224kbps, etc.

That's exactly what I did with 3100g. Please note that the average bitrate of the audio data of CBR320 mp3 files is usually around 305 kbps, not much more than the average bitrate of -V0+. If requested for, I could make it exactly equal to the the CBR320 average bitrate, but because that's a minor deviation I preferred the 'round' number of 300 kbps ATM.

On another note, halb27, I wanted to notify you of some strange behavior.  If I pass the option --lowpass -1 -V0+, encoding fails.  But -V0+ --lowpass -1 works as expected.
I tried to reproduce the error, but did not succeed. My 3100g and 3995f --lowpass -1 -V0+ encodings from the cmdline were fine. Can you give me more details, please?
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #7
I tried to reproduce the error, but did not succeed. My 3100g and 3995f --lowpass -1 -V0+ encodings from the cmdline were fine. Can you give me more details, please?

How very strange.  I now am not able to reproduce the issue either.  If it occurs again, I will let you know!

lame3100g, a functional extension

Reply #8
Halb, I have ripped and encoded around 25 of my CDs with 3.100g, and so far have encountered no transparency issues whatsoever.  (That said, I have not done any formal ABX tests yet.) Thank you!

That said, I am curious why you added a lowpass filter on -V0+ and the other stronger settings, when standard -V0 does not have one.  I know that a lowpass results in better encoding on lower bitrates, but I haven't heard an advantage to applying one on -V0 or -V0+ yet.  Then again, I haven't done any formal ABX, and my hearing is not great.
On a related topic, have you considered adding a highpass filter?  If you're going to use a lowpass, it would make sense to me to include a highpass as well - perhaps at 8Hz or 5Hz.

Other thoughts:
--  Would you recommend changing the -X setting?
--  It might be interesting to see what a -V0+ --nores setting does.
--  Have you considered expanding your variant's functionality to freeformat MP3?



Current settings (in EAC): -q0 --replaygain-accurate -V0+ --lowpass -1 %islow%--adbr_long 0%islow% %source% %dest%

lame3100g, a functional extension

Reply #9
a) What is the -X switch?
b) Why would you want to disable bitreservoir? Short block behavior of the functional extension relies on it.
c) freeformat is CBR AFAIK, and the functional extension is about VBR, but I wouldn't support freeformat anyway. If I hadn't run into real world restrictions I'd use lossyWAV | FLAC as my absolute favorite lossy encoding procedure, but I returned to mp3 because of its universal usability. freeformat wouldn't help me here, and I guess there'll be hardly somebody who could make good use of it. I wouldn't like to do something for pure academic reasons.
d) As for the lowpass: With former Lame versions there had always been a lowpass even with -V0. The new sfb21 behavior allows for not using a lowpass. Maybe I'm just a bit conservative, but as I can't imagine that a 18.2 kHz lowpass can be an issue to anybody, and because I've seen situations where Lame -V0(+) was running into an out of audio data space situation without the lowpass, I like having a lowpass. I raised the lowpass frequency already from 17.5 to 18.2 kHz. As for a highpass I've never heard of an advantage concerning this.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #10
Response


a) -X is the "Change Quality Measure" switch.  It controls how LAME searches for, and decides upon, the best quantization.  You'll find it in LAME's commandline documentation.
b) This was purely for curiosity's sake.  I can't think of any GOOD reason to disable the bit reservoir...I just wanted to see what would happen
c) That makes sense...I am a fan of FLAC as well.
d) I assume that adding a highpass would very slightly decrease frame complexity, so could result in a further very slight improvement in the resulting encoding.  But that of course would need to be tested.

lame3100g, a functional extension

Reply #11
I've read the -X documentation: that's nothing for me. As it's not in the --longhelp: is it really working?
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #12
I've read the -X documentation: that's nothing for me. As it's not in the --longhelp: is it really working?

It may not be working.  I've never found any noticeable difference in the resulting MP3 when switching between the various -X options.

lame3100g, a functional extension

Reply #13
The -X is automatic . The switch itself has been disabled for a long time since not most users didn't understand its function.

lame3100g, a functional extension

Reply #14
a) -X is the "Change Quality Measure" switch.  It controls how LAME searches for, and decides upon, the best quantization.  You'll find it in LAME's commandline documentation.

That page shouldn't be there any longer. It is from the older documentation.
Current documented switches are here

Said that, the switch still exists in the source code:

   case 'X':
   /* experimental switch -X:
   the differnt types of quant compare are tough
   to communicate to endusers, so they shouldn't
   bother to toy around with them
   */

d) I assume that adding a highpass would very slightly decrease frame complexity, so could result in a further very slight improvement in the resulting encoding.  But that of course would need to be tested.


The internal LAME filter acts in frequency domain (i.e. directly over the  MDCT, or at least that's what I undesrtood). That's the reason why the lowest highpass filter applicable is around 400Hz at 44Khz sampling rate.  (See note at the detailed information)
Also, take in mind that a filter at 5 or 10Hz would be quite a step filter, so not easy to make either.

lame3100g, a functional extension

Reply #15
...Perhaps a better way to do this would be to key -V0+ through -V5+ to each standard frame size.  EG -V0+ is keyed to ~320kbps, -V1+ to ~256kbps, -V2+ to ~224kbps, etc.

That's exactly what I did with 3100g.

Is it possible to select the bitrate instead of the -Vx+? I mean, if I used commands like -224, -V2+ is applied automatically. if I use -240, -V1.5+ is applied. It should be handy, one does not need to carry a V vs bitrate table, and more readily understandable. I sometimes forget as I increase the V or q number, whether the bitrate increase (like faac, neroaac, helix) or decrease(like LAME).

lame3100g, a functional extension

Reply #16
a) -X is the "Change Quality Measure" switch.  It controls how LAME searches for, and decides upon, the best quantization.  You'll find it in LAME's commandline documentation.
That page shouldn't be there any longer. It is from the older documentation.
Current documented switches are here

Thanks for that.  I didn't realize I was using an out-of-date reference.

Reading through the current documentation, I think I will experiment with a -V0+ --lowpass -1 -Y setting.  (Can anyone tell me the specific frequencies -Y affects?)
This documentation also confirms what you are saying about the highpass filter - effective minimum highpass is 1.0887% of the sampling frequency, i.e. 481Hz on a 44.1kHz sample.  Obviously, that would be a bad idea.


EDIT: I think I'm making too big a deal out of the highpass filter.  In an informal test I just learned I cannot hear frequencies over about 16.5kHz and cannot ABX lowpass filters on white noise over about 14kHz.  The only problem: these MP3s are for the family, not just myself.

lame3100g, a functional extension

Reply #17
halb27,
Nice to see the work in progess. Thank You as always. 

It would be great if your extension will support the rates between ~130 kbps and ~160 kbps (VBR).
This poll shows that there is quite a lot of people who will be interested. Hey, and a quality isn't bad at all. 
Also people could provide a really useful feedback because testing at 130-160 kbps is much more affordable while only some experiencied listeners can test at >175 kbps.

I'm pretty sure that there is still a room for improvements as I've tested LAME and Helix at 130 kbps. Both encoders exhibit some (dis)advantages and Helix had a bit higher average score.

lame3100g, a functional extension

Reply #18
Is it possible to select the bitrate instead of the -Vx+? ...

I don't like this idea (see post #6), but it's easy to put to work.
Would an extension of the -V option, say -V xxx, xxx between 176 and 300, help you? -V xxx would mean that -Vn+ is used with n such that average bitrate for my test set of various pop music is xxx kbps.
Any suggestion for another switch instead of extending the meaning of -V x?
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #19
... It would be great if your extension will support the rates between ~130 kbps and ~160 kbps (VBR). ...

We could give away any improvement for long blocks (that is use -V5+ --adbr_long 0), but this results in an average bitrate of 148 kbps for my test set.
We could reduce short block improvements, too, but -V5+ --adbr_long 0 --adbr_short 390 --adbr_startshort 350 has an average bitrate of 143 kbps.
I can work things out for such a -V5 based strategy, but as you can see I probably won't get as low as 130 kbps. Is this what you want? Or do you have other things in mind for the behavior of the functional extension when using very moderate bitrates?

I was just thinking it over:
What about having future -V5+ yield an average bitrate of 144 kbps by reducing mainly long block behavior and to a minor extent short block behavior, and have -V4+ to yield an average bitrate of 176 kbps accordingly?
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #20
Well,  I can do some blind tests and see how it works out. Seems reasonable.

I also have noticed some different behavior of 3.99.5/3.100. It tries to preserves up to 17 kHz at 130-135 kbps (V5). 

I like more Helix (16kHz) and 3.98.4 V 5.7 (15.8 kHz) at 130 kbps. Even state of art AAC encoders have lowpass at 15.7-15.8 kHz at 96-100 kbps and they are at least as good as MP3 encoders  at 130-135 kbps.

It's very likely that 15.8-16 kHz is the most appropriate for MP3 encoders at 130-135 kbps.
It's worth to try.

Sorry, I wanted to talk more but must go and will be busy but later this week I will be glad to help and test your extension.
 

lame3100g, a functional extension

Reply #21
I tried -V5+ --adbr_long 80 --adbr_short 370 --adbr_startshort 360 as a candidate for a future 144 kbps -V5+. Short block behavior is still pretty good and I can see that the functional extension makes sense here, too.
Same goes for -V4+ --adbr_long 130 --adbr_short 400 as a candidate for a future 176 kbps -V4+.

I start to like the idea.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #22
... It's very likely that 15.8-16 kHz is the most appropriate for MP3 encoders at 130-135 kbps. ...

I'm of the same opinion. As I'm modifying lowpass behavior with the highest quality settings I think I should change it with lower settings, too. Default lowpass, of course, so that everybody can override it according to personal needs.
lame3995o -Q1.7 --lowpass 17

lame3100g, a functional extension

Reply #23
I'm definitely seeing the point to a lowpass, even on the highest quality settings, now that I've done some ABX tests.  Interestingly, I'm getting virtually identical results with standard -V0+ versus -V0+ --lowpass -1 -Y.

lame3100g, a functional extension

Reply #24
Is it possible to select the bitrate instead of the -Vx+? ...

I don't like this idea (see post #6), but it's easy to put to work.
Would an extension of the -V option, say -V xxx, xxx between 176 and 300, help you? -V xxx would mean that -Vn+ is used with n such that average bitrate for my test set of various pop music is xxx kbps.
Any suggestion for another switch instead of extending the meaning of -V x?

I'd love to see that function actually working on LAME. It's great! I don't think some bitrate increase/decrease depending on what genre he/she listens to would cause a big problem. But the name may cause some confusion as we go from -V 0 to -V 9 while the quality decrease, and as we go from -V 176 to -V 300 while the quality increase. I'd rather have -b xxx -VBR or -vbr xxx or something. Easier to explain and less confusion.