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: VBR-MTRH and Dibrom\'s new compile (Read 5344 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

VBR-MTRH and Dibrom\'s new compile

Dibrom is valiantly trying to overcome some limitations of older lame encoders, and all of us should be thankful for his efforts! 

I. VBR-MTRH:

One significant change that is forthcoming is the switch to vbr-mtrh, which I believe is 2.5x faster than the vbr-old.
However, this speed currently comes at a quality price, which is why Dibrom did not use it in a preset in his older compiles.

I am curious how many "problems" vbr-mtrh has...

John V has supplied two:
-----------------------------------------------------------------------------------
"[1] One problem ... is that vbr-mtrh doesn't have all the noise measurement methods vbr-old has.

[2] Also vbr-mtrh's noise measurement methods are technically implemented a bit differently than vbr-old's, so separate tweakings (or at least testings) must be done for both vbr-modes."
-----------------------------------------------------------------------------------

I am wondering if there are any other problems with vbr-mtrh that Dibrom has to overcome?

I am also curious as to how vbr-mtrh achieves more speed...what sacrifices, if any, are made?

II. -X9 (NOISE MEASURING)

Another significant change that is forthcoming is a new noise measuring algorithm, which, I believe, actually combines several older methods in different ways...

I believe it will provide both Higher quality AND a smaller filesize! 
I read somewhere that 15 kbps lower on average is desirable (cdrw.org)...but I am not sure if Dibrom commented on whether or not this is a reasonable expectation.

Any other commentary on issues I have missed here that Dibrom is trying to overcome is greatly appreciated!!

Thanks,
RD

VBR-MTRH and Dibrom\'s new compile

Reply #1
Quote
Originally posted by RD
However, this speed currently comes at a quality price, which is why Dibrom did not use it in a preset in his older compiles.


This is partially correct, though not entirely.  vbr-mtrh doesn't really sacrifice accuracy for speed, it just hasn't in the past been very accommodating towards providing a maximum noise measuring function which works well with nspsytune.  It does feature 2 different max noise modes, but they increase the bitrate more than the vbr-old counterparts... but they do actually work and provide roughly the same level of quality.

Quote
I am curious how many "problems" vbr-mtrh has...
"[1] One problem ... is that vbr-mtrh doesn't have all the noise measurement methods vbr-old has.


This is similar to above.  vbr-old basically allows average noise measuring, max noise measuring, and total noise measuring.  However... it only allows these effectively across all scalefactor bands at once and not actually per scalefactor band seperately.  vbr-mtrh allows average, mostly max, true max, and 2 other faster modes.  All of the vbr-mtrh modes measure noise per scalefactor band though.  The effective difference though is not actually the noise measurings themselves, it is instead that vbr-old allows for more criterion for deciding what to actually do with those measurings.

Quote
[2] Also vbr-mtrh's noise measurement methods are technically implemented a bit differently than vbr-old's, so separate tweakings (or at least testings) must be done for both vbr-modes."


This is correct, except for the fact that I will not be implementing these tweaks in vbr-old (at least for now). One of the key reasons I decided to switch over to mtrh is because the per scalefactor measuring it features (which vbr-old doesn't as I stated earlier) is critical to the idea.  It should be possible add code to allow vbr-old to do this, but since I wanted to switch to mtrh eventually anyway, it just made sense to go ahead and do it now.  Also, you can't quite define the criterion for deciding what to do with the noise measurings quite to the same degree that you can with vbr-old.  Practically though, this makes little difference and in fact I think the vbr-mtrh approach is better anyway once you get used to it.

Quote
I am wondering if there are any other problems with vbr-mtrh that Dibrom has to overcome?

I am also curious as to how vbr-mtrh achieves more speed...what sacrifices, if any, are made?


Part of the reason for the speed difference (besides just more optimized code) is that vbr-old uses more of a trial and error approach where vbr-mtrh is much more direct in determining bitrate/quality/etc while encoding.  I think the latter can actually be more effective in terms of achieving quality, it just may have been in the past that overall mtrh was not quite tuned as well as vbr-old... over the past few months this has changed though.

Quote
II. -X9 (NOISE MEASURING)[/b]

Another significant change that is forthcoming is a new noise measuring algorithm, which, I believe, actually combines several older methods in different ways...


This has changed somewhat.  Since I've started trying to work with mtrh instead the approach is a little bit different.  Instead of actually using different types of noise measuring themselves to provide the necessary quality, I use different methods of noise measuring, compare the differences, and then decide what to do after that.  At least that is what I'm currently looking at.

Quote
I believe it will provide both Higher quality AND a smaller filesize!  I read somewhere that 15 kbps lower on average is desirable (cdrw.org)...but I am not sure if Dibrom commented on whether or not this is a reasonable expectation.


Yeah, this is the idea and I think it should be possible.  Basically, I believe that in most music encoded with --dm-preset standard, there is probably on average, on most "easy" music, about 15kbps to maybe even 30kbps headroom before quality starts to roll off significantly.  The problem is that if you remove this headroom, then on the difficult tracks they will sound that much worse.  What I'm trying to do is use a more adaptive approach to where you can remove that bit of headroom from most easy music, and actually increase it beyond what it normally was for difficult tracks.  This in addition to a few other tweaks, if they work, should provide higher quality with a lower average bitrate.  I actually want tracks like fatboy, short, castanets, death2, etc to increase in bitrate though if necessary.  So this is basically why I talk about trying to increase flexibility.

I believe the largest bitrate savings though will probably come when encoding stuff like metal or extremely heavily distorted noise/experimental electronic music, etc as this is the type of music which suffers the most from bitrate increases while just using a straight maximum noise measuring mode.  Much of this has to do with the high energy content this type of music has over 16khz and this is why I initially had to implement --ns-sfb21 to attempt to control this increase somewhat.  It should be possible to eliminate the need for that switch entirely from the --dm-presets though if the rest of these modifications work out since it is somewhat related to the whole process.

VBR-MTRH and Dibrom\'s new compile

Reply #2
 Thanks for the great reply, Dibrom 

It sounds like this next compile is going to be a truly SIGNIFICANT leap in progress!

Since I encode a lot of metal music, the lower average bitrate will be greatly appreciated!

Also, I thought the -ns-sfb21 switch was here to stay...but that shows how mistaken I was...

Now I wonder if -b 112 will be necessary... or maybe we can go lower? or eliminate it altogether one day?

Any tweaks to naioki's special joint-stereo mode?

I wonder what other parts of the standard command line will change, if any,....

Thanks,
RD