IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
lame3100g, a functional extension
halb27
post Dec 9 2012, 21:33
Post #1





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Dec 10 2012, 00:02
Post #2





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Dec 9 2012, 14:33) *
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 smile.gif 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?

This post has been edited by BFG: Dec 10 2012, 00:02
Go to the top of the page
+Quote Post
halb27
post Dec 10 2012, 00:19
Post #3





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (BFG @ Dec 10 2012, 00:02) *
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.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Kamedo2
post Dec 15 2012, 20:24
Post #4





Group: Members
Posts: 219
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



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?
Go to the top of the page
+Quote Post
BFG
post Dec 15 2012, 23:13
Post #5





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE (Kamedo2 @ Dec 15 2012, 13:24) *
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.
Go to the top of the page
+Quote Post
halb27
post Dec 15 2012, 23:21
Post #6





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Dec 15 2012, 23:31


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Dec 15 2012, 23:29
Post #7





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (BFG @ Dec 15 2012, 23:13) *
...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.

QUOTE (BFG @ Dec 15 2012, 23:13) *
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?

This post has been edited by halb27: Dec 15 2012, 23:42


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Dec 16 2012, 00:26
Post #8





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Dec 15 2012, 16:29) *
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!
Go to the top of the page
+Quote Post
BFG
post Dec 16 2012, 03:41
Post #9





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



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%

This post has been edited by BFG: Dec 16 2012, 03:43
Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 11:48
Post #10





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Dec 16 2012, 12:26
Post #11





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Dec 16 2012, 04:48) *
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 biggrin.gif
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.
Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 12:35
Post #12





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Dec 16 2012, 12:43
Post #13





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Dec 16 2012, 05:35) *
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.
Go to the top of the page
+Quote Post
shadowking
post Dec 16 2012, 13:28
Post #14





Group: Members
Posts: 1527
Joined: 31-January 04
Member No.: 11664



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


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
[JAZ]
post Dec 16 2012, 14:11
Post #15





Group: Members
Posts: 1783
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



QUOTE (BFG @ Dec 16 2012, 12:26) *
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
*/

QUOTE (BFG @ Dec 16 2012, 12:26) *
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.
Go to the top of the page
+Quote Post
Kamedo2
post Dec 16 2012, 14:28
Post #16





Group: Members
Posts: 219
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



QUOTE (halb27 @ Dec 16 2012, 07:29) *
QUOTE (BFG @ Dec 15 2012, 23:13) *
...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).
Go to the top of the page
+Quote Post
BFG
post Dec 16 2012, 19:51
Post #17





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



QUOTE ([JAZ] @ Dec 16 2012, 07:11) *
QUOTE (BFG @ Dec 16 2012, 12:26) *
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.

This post has been edited by BFG: Dec 16 2012, 20:43
Go to the top of the page
+Quote Post
IgorC
post Dec 16 2012, 20:59
Post #18





Group: Members
Posts: 1572
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



halb27,
Nice to see the work in progess. Thank You as always. smile.gif

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.

This post has been edited by IgorC: Dec 16 2012, 21:01
Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 21:13
Post #19





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (Kamedo2 @ Dec 16 2012, 14:28) *
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?


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 21:32
Post #20





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (IgorC @ Dec 16 2012, 20:59) *
... 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?

This post has been edited by halb27: Dec 16 2012, 22:05


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Dec 16 2012, 22:58
Post #21





Group: Members
Posts: 1572
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



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). unsure.gif

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.

Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 23:10
Post #22





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Dec 16 2012, 23:14


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Dec 16 2012, 23:17
Post #23





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (IgorC @ Dec 16 2012, 22:58) *
... 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.

This post has been edited by halb27: Dec 16 2012, 23:19


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Dec 17 2012, 00:49
Post #24





Group: Members
Posts: 206
Joined: 22-July 12
Member No.: 101637



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.

This post has been edited by BFG: Dec 17 2012, 00:50
Go to the top of the page
+Quote Post
Kamedo2
post Dec 17 2012, 03:03
Post #25





Group: Members
Posts: 219
Joined: 16-November 12
From: Kyoto, Japan
Member No.: 104567



QUOTE (halb27 @ Dec 17 2012, 05:13) *
QUOTE (Kamedo2 @ Dec 16 2012, 14:28) *
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.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th September 2014 - 16:06