IPB

Welcome Guest ( Log In | Register )

4 Pages V   1 2 3 > »   
Reply to this topicStart new topic
Lame 3.99.5z, a functional extension
halb27
post Sep 18 2012, 23:06
Post #1





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



You can download it from here.

Whatís the functional extension?

It offers VBR quality settings -V3+ to -V0+ and -V0+eco (economic version of -V0+).


What are -Vn+ and -V0+eco good for?

They improve pre-echo behavior.
Beyond that, they combine the quality advantages of VBR (regarding pre-echo) with the quality advantages of CBR/ABR (with respect to ringing and other tonal issues).


Lame users can be classified into three categories:

a) Users who donít care about rare quality issues and/or care much about small file size.
The common way for these users to work with Lame is to use -V5, -V4, or similar.

b) Users who donít like to have obvious and especially ugly issues in their music even when theyíre rare but who care about file size as well.
The common way for these users to work with Lame is to use -V2, -V3, or similar.
CBR 192 or similar, or ABR in this bitrate range, is an alternative (but seldom used).

c) Users who want overall transparency or at least a quality which comes close to it, and who donít care much about file size.
The common way for these users to work with Lame is to use -V0, -V1, or similar as a VBR method, or to use CBR 320 or 256. Using very high bitrate ABR is an alternative (seldom used).

For users of group b) and c) -Vn+/-V0+eco offers significant quality advantages:

We have two major issue classes with most of the lossy codecs:
- temporal smearing (pre-echo) issues
- ringing (tremolo) and other tonal issues.

Letís look at the worst samples I know for these classes:
- eig (extremely strong temporal smearing)
- lead-voice (extreme ringing, for instance at sec. 0..2)

With samples like these users of group b) canít be very happy when using -V2 or -V3, because the ringing issues are very obvious and ugly. The temporal smearing of eig is pretty obvious as well, especially around sec. 3. Using CBR/ABR 192 or similar is a good procedure to fight the ringing, but temporal smearing is much worse than with VBR, itís real ugly.
Things donít really change when using slightly increased quality settings.

For users of group c) itís exactly the same thing, with quality requirements and quality received just both on a higher level.

So the traditional way of doing things isnít totally satisfactory.

Users of group b) can use -V3+ or -V2+ (recommended) and get much better results in the overall view.

Users of group c) can use -V1+ or -V0+eco (recommended) or -V0+ (recommended for the paranoid like me) and get transparency or close-to-transparency. Sure itís impossible to prove transparency for the universe of music, but itís true for the samples mentioned. And as these are very outstanding samples within their problem classes and because of the technical details of -Vn+ described below itís plausible that the approach works rather universally.


How is it done?

-Vn+ uses -Vn internally (-V0+eco uses -V0), but the accuracy demands for short blocks are increased. Short blocks are used when the encoder takes care of good temporal resolution. Audio data bitrate is kept rather high also with long blocks which are normally used.
These audio data requirements are helpful for any kind of problem, they are not restricted to ringing or pre-echo issues.
Moreover a strategy is used which is targeting at providing close to maximum possible audio data space for short blocks.


Whatís the price to pay?

Compared to -Vn the increased accuracy demands of -Vn+ raise average bitrate. As -Vn+ is targeting at significant quality improvements compared to -V2 for real bad samples, we need an average bitrate around 200 kbps at least.

-V3+ and -V2+ are designed for users of group b) above, and as such take care of average bitrate not to be much higher than 200 kbps. For my test set of various pop music average bitrate is 205 kbps for -V3+, and 217 kbps for -V2+.

For users of group c) I allow for the full quality resp. average bitrate range mp3 can offer.
-V1+ takes an average bitrate of 257 kbps for my test set, -V0+ takes 317 kbps.
-V0+eco (economic version of -V0+) takes 266 kbps. So -V0+eco comes nearly for free as -V0 takes 260 kbps for my test set.

Unlike versions I published before, mp3packer isnít really needed any more to squeeze the unused bits out of the mp3 file (with the exception of fractional settings like -V0.5+ between -V1+ and -V0+).
mp3packer brings average bitrate down by only 1 kbps maximum for -Vn+ between -V3+ and -V2+, by 1 to 2 kbps for -Vn+ between -V2+ and -V1+, and by 2 kbps for -V0+ and -V0+eco. So I think we can forget about mp3packer with these settings.


Options

--adbr_short x
sets the minimum audio data bitrate for short blocks to x [kbps] when using -Vn+ or -V0+eco, with x in the range 150..450.
Defaults are 360,370,420,440,440 kbps for -V3+,-V2+,-V1+,-V0+eco,-V0+ resp.

--adbr_long x
sets the minimum audio data bitrate for long blocks to x [kbps] when using -Vn+ or -V0+eco, with x in the range 110..310.
Defaults are 160,170,215,220,290 kbps for -V3+,-V2+,-V1+,-V0+eco,-V0+ resp.

--frameAnalysis
prints detailed information for each frame (L/R or M/S representation, blocktype of both granules, available audio data bits, audio data bits used, etc.). Works for both -Vn and -Vn+.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
GeSomeone
post Sep 26 2012, 20:17
Post #2





Group: Members
Posts: 921
Joined: 22-October 01
From: the Netherlands
Member No.: 335



I think you forgot to mention the lowpass values that are lowered compared to the defaults.
I like the fact that you made an effort to support the range -V 3 - 0 with this version, as the "y" version of this was useless to me. I will try this for the occasions where I hear a good recording but still decide to go lossy (and not lossyWav).
I do admit I am surprised by the bitrates for short blocks, I assumed they were the same as for normal blocks.

edit: short blocks

This post has been edited by GeSomeone: Sep 26 2012, 20:21


--------------------
In theory, there is no difference between theory and practice.
Go to the top of the page
+Quote Post
solidornot
post Oct 6 2012, 18:13
Post #3





Group: Members
Posts: 2
Joined: 22-December 11
Member No.: 95958



Thank you. I have used the extension since last Dec and appreciate the contribution. If I may, a couple questions.
First, for those who use -V0+, is there any significant difference between this version ("z") and the prior version ("y").
Second, what is the functional difference between -V0+ and -V0+eco? From the default values of the parameters for minimum bit rates I can see that the minimum bit rate for long blocks is considerably lower for the eco level (220 vs. 290), but are there other differences as well?
Again, Thanks.

.... Solidornot
Go to the top of the page
+Quote Post
halb27
post Oct 6 2012, 22:07
Post #4





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



The main difference between -V0+eco and -V0 is the minimum audio data bitrate for long blocks as you found out.

There's a bit (not much) of internal details however which I didn't report about. In 3.99.5z (not in 3.99.5y) minimum audio data bitrate for long blocks depends a bit on the energy in the frame. The defaults I gave with the --adbr_long description are valid for a frame of rather moderate loudness. For quiet music the minimum audio data requirements are lowered. For louder music the requirements are increased but only up to a certain limit. With -V0+eco this limit for a further audio data bitrate increase is very restricted (~15 kbps IIRC - I can't look it up at the moment as I am on vacation). With -Vn+ this limit is higher (though this doesn't really apply to -V0+ with its close to 320 kbps minimum audio data bitrate).

3.99.5y -V0 corresponds to 3.99.5z -V0+eco. It's not identical but I can't imagine that there's a noticeable difference. No need to re-encode, but maybe you prefer the new possibilities for new encodings.

This post has been edited by halb27: Oct 6 2012, 22:10


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
solidornot
post Oct 8 2012, 02:28
Post #5





Group: Members
Posts: 2
Joined: 22-December 11
Member No.: 95958



QUOTE (halb27 @ Oct 6 2012, 16:07) *
The main difference between -V0+eco and -V0 is the minimum audio data bitrate for long blocks as you found out.
......
3.99.5y -V0 corresponds to 3.99.5z -V0+eco. It's not identical but I can't imagine that there's a noticeable difference. No need to re-encode, but maybe you prefer the new possibilities for new encodings.


All very clear. Much thanks.
Go to the top of the page
+Quote Post
Dynamic
post Oct 8 2012, 17:10
Post #6





Group: Members
Posts: 796
Joined: 17-September 06
Member No.: 35307



...and for future use (not existing encodes), the 'z' version, since it no longer needs mp3packer, is much more usable.
Go to the top of the page
+Quote Post
soundping
post Oct 8 2012, 19:34
Post #7





Group: Members
Posts: 36
Joined: 3-February 12
Member No.: 96900



3.99.5z doesn't work with dBpoweramp R14.3.

I'm not using the command line. I just replaced LAME 3.99.5 app.
Go to the top of the page
+Quote Post
halb27
post Oct 8 2012, 21:08
Post #8





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



Maybe just the VC10 runtime library is missing which I packaged together with 3.99.5z.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
n8er11
post Oct 9 2012, 11:35
Post #9





Group: Members
Posts: 1
Joined: 25-June 09
Member No.: 70958



Worked ok for me on DBPowerAmp...replaced the original lame.exe and copied the included VC10 Library to the folder as well, added -V0+eco to the Additional CLI. No problems so far..
THank you
Go to the top of the page
+Quote Post
soundping
post Oct 9 2012, 16:55
Post #10





Group: Members
Posts: 36
Joined: 3-February 12
Member No.: 96900



The version that's packed with 9.99.5z is "Microsoft Visual C++ 2010 x86 10.0.30319.1"
I have the updated versions installed x64 & x86 10.0.40219.

I am running Win7 64bit.

This post has been edited by soundping: Oct 9 2012, 16:57
Go to the top of the page
+Quote Post
halb27
post Oct 9 2012, 18:49
Post #11





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



Lame3.99.5z is a 32 bit exe (which works with 64 bit Windows7) and is supposed to need a 32 bit VC runtime library. OK, sounds like you have it installed. Can you try the older version instead of 10.0.40219 to see whether or not this is the problem?

This post has been edited by halb27: Oct 9 2012, 18:53


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
lvqcl
post Oct 9 2012, 19:12
Post #12





Group: Developer
Posts: 3336
Joined: 2-December 07
Member No.: 49183



lame3995z.exe + msvcr100.dll 10.0.40219.325: works here.
Go to the top of the page
+Quote Post
soundping
post Oct 10 2012, 08:46
Post #13





Group: Members
Posts: 36
Joined: 3-February 12
Member No.: 96900



That's weird. The regular LAME 3.99.5 works just fine.
Go to the top of the page
+Quote Post
BFG
post Oct 22 2012, 03:09
Post #14





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



Unfortunately, I wasn't able to get 3.99.5z to work with Exact Audio Copy, while 3.99.5 does. (3.99.5z returns a Missing DLL error.) Perhaps EAC uses a version of LAME that was compiled differently than the "standard" LAME? Any suggestions?
Go to the top of the page
+Quote Post
halb27
post Oct 22 2012, 07:39
Post #15





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



In which folder is the msvcr100.dll?


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Oct 22 2012, 09:52
Post #16





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



I took it as an occasion to install EAC1.0b3 on my Windows7 system. 3.99.5z works fine. I used
-V0+eco --noreplaygain --silent --pad-id3v2 --ta "%artist%" --tt "%title%" --tg "%genre%" --tl "%albumtitle%" --ty "%year%" --tn "%tracknr%" %source% %dest%
as the command line option for the user-defined encoder lame3995z.exe.
I have the msvcr100.dll in Windows\System32. Did you run vcredist_x86.exe provided in the zipfile?


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Oct 22 2012, 19:22
Post #17





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



QUOTE (halb27 @ Oct 22 2012, 03:52) *
I have the msvcr100.dll in Windows\System32. Did you run vcredist_x86.exe provided in the zipfile?

Hmm, that's probably my mistake. I'm using a different version of that distributable, so while I have msvcr100.dll, it's not in the system32 folder. Thanks.
Go to the top of the page
+Quote Post
BFG
post Oct 23 2012, 00:38
Post #18





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



QUOTE (BFG @ Oct 22 2012, 13:22) *
QUOTE (halb27 @ Oct 22 2012, 03:52) *
I have the msvcr100.dll in Windows\System32. Did you run vcredist_x86.exe provided in the zipfile?

Hmm, that's probably my mistake. I'm using a different version of that distributable, so while I have msvcr100.dll, it's not in the system32 folder. Thanks.

I finally figured it out. I had the 64-bit C++ redistributable installed, and so didn't install the 32-bit version that came with 3.99.5z. Lesson learned!

This post has been edited by BFG: Oct 23 2012, 00:38
Go to the top of the page
+Quote Post
nastea
post Oct 23 2012, 01:43
Post #19





Group: Members
Posts: 39
Joined: 30-July 12
Member No.: 101867



Is it already possible to use wildcards with LAME?

the last time I checked LAME, it wasn't possible to do this:

lame -V0 *.wav

or

lame --decode *.mp3


Maybe it's possible now, but I don't know where I can download the latest LAME version.
Go to the top of the page
+Quote Post
BFG
post Oct 23 2012, 02:26
Post #20





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



QUOTE (nastea @ Oct 22 2012, 19:43) *
Maybe it's possible now, but I don't know where I can download the latest LAME version.

The latest (non-variant) LAME version is available from http://sourceforge.net/projects/lame/files/lame/3.99/ .

Go to the top of the page
+Quote Post
BFG
post Oct 23 2012, 02:28
Post #21





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



halb27, can you help me understand: What is the advantage of using VBR -V0+ over CBR 320, when the resulting file sizes are virtually the same? Does -V0+ use more accurate short frames than the standard CBR mode?

EDIT: Also, what are the short frame and long frame bitrate targets for the standard -V0?
EDIT 2: From a quality perspective, is there any problem with using -V0+ but setting the --adbr flags to the minimum allowed? Theoretically, wouldn't that allow LAME to use the full range of available bitrates for a short or long frame, and decide to use the smallest one that allows for high quality transparency?

This post has been edited by BFG: Oct 23 2012, 02:47
Go to the top of the page
+Quote Post
Aleron Ives
post Oct 23 2012, 04:15
Post #22





Group: Members
Posts: 174
Joined: 22-March 10
From: California
Member No.: 79208



QUOTE (nastea @ Oct 22 2012, 17:43) *
Is it already possible to use wildcards with LAME?

the last time I checked LAME, it wasn't possible to do this:

lame -V0 *.wav

LAME doesn't support wildcards, but you can use a FOR command to perform batch operations from the command line, e.g.

FOR %1 IN (*.wav) DO lame.exe -V 0 %1 %1.mp3

would encode all WAV files in the cwd into MP3 files with the same filenames.
Go to the top of the page
+Quote Post
halb27
post Oct 23 2012, 08:52
Post #23





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



QUOTE (BFG @ Oct 23 2012, 03:28) *
halb27, can you help me understand: What is the advantage of using VBR -V0+ over CBR 320, when the resulting file sizes are virtually the same? Does -V0+ use more accurate short frames than the standard CBR mode?

EDIT: Also, what are the short frame and long frame bitrate targets for the standard -V0?
EDIT 2: From a quality perspective, is there any problem with using -V0+ but setting the --adbr flags to the minimum allowed? Theoretically, wouldn't that allow LAME to use the full range of available bitrates for a short or long frame, and decide to use the smallest one that allows for high quality transparency?

a) The audio data creation process of CBR is different from that of VBR. VBR audio data can be very different even if bitrate is similar. Yes, -V0+ provides the more accurate encoding for frames with short blocks in them. CBR 320 doesn't do a very good job at impulse-like spots in the music (compare for instance eig using CBR320 against -V0+). Moreover there is some suspicion that CBR is flawed a bit.

b) There is no frame bitrate target at all with standard -V0.

c) There is not much sense in setting the --adbr flags to the minimum values allowed. This would get you more or less standard -Vn behavior. You can't totally rely on the VBR mechanism to provide top quality (though not much is left, and from pre-tests I expect robert to get us significantly closer to perfection with Lame 3.100). In case we could perfectly rely on VBR there'd be no room for the functional extension. The essence of the functional extension is to bring a user-selectable amount of brute-force safety to VBR the way most people expect it from using CBR.
However in practical terms using -V0+eco comes close to your idea as average bitrate is very close to that of standard -V0, and you get a significant amount of better quality needed on occasion more or less for free.

This post has been edited by halb27: Oct 23 2012, 09:34


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
BFG
post Oct 24 2012, 01:50
Post #24





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



QUOTE (halb27 @ Oct 23 2012, 02:52) *
A bunch of stuff

Ah! I think I finally understand now. Thanks.
Essentially, the various VBRs better utilize the available bitrate (up to 320kbps) than equivalent CBRs/ABRs, at least at the higher quality end. 3.99.5z, meanwhile, adds an option to strictly enforce the minimum size of long frames and (more importantly) short frames, while the standard 3.99.5 does not have such a restriction, and so - depending upon the algorithm and the quality setting selected - may choose to use frame sizes that are too low, leading to preecho and other problems.

One last question, and I think I'm done. -V0+ doesn't actually make changes to the psychoacoustic model or any of the 3.99.5 algorithms, does it? It simply forces the higher minimum frame sizes and raises the lowpass filter, forcing the existing algorithms to "work harder" to achieve the required accuracy?


On a different note - this discussion kind of makes me wonder why someone hasn't just built a "best possible VBR-quality accuracy under a 320kbps constant frame size" model. In other words, use the VBR approach, but continue to recalculate each frame, increasing the accuracy requirement each time, until a constant 320kbps is achieved. The bit reservoir could be utilized to provide additional accuracy to adjacent frames which are more complex. This would mean that some frames would be more accurate than others, but theoretically, such an approach would yield the most accurate possible ISO-compliant MP3s. (I suspect, BTW, that -V0+ comes close to this.)
EDIT: I'm sincerely hoping this isn't a question simply borne of my ignorance of LAME smile.gif

This post has been edited by BFG: Oct 24 2012, 02:10
Go to the top of the page
+Quote Post
halb27
post Oct 24 2012, 08:41
Post #25





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



Yes, you understand it very well. -Vn+ resp. -V0+eco doesn't change the psychoacoustic parts of Lame. As you said it forces the existing algorithms to work harder (to achieve minimum bitrate requirements, seperately for long and short blocks), and it takes some care to provide close to maximum possible audio data space (important for short blocks) which includes restricting extremely high frequencies to 17.5 kHz.

As for your CBR idea: robert told me that he plans to use the audio data creation process which is used for VBR for CBR as well. So probably you will get that. ATM you can use -V0+ and repackage this into the CBR framework by using mp3packer in case you really need CBR. Audio data won't change of course, so from pure audio considerations there's no use in it.

This post has been edited by halb27: Oct 24 2012, 09:02


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post

4 Pages V   1 2 3 > » 
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: 29th July 2014 - 13:07