OK... here we go.

http://static.hydrogenaudio.org/extra/lame_dm_rev7.zip
http://static.hydrogenaudio.org/extra/lame_dm_rev7-src.zip

Just to summarize everything for people who may not have kept up on some of the massive threads in the past, here is what the current situation is:

1. --alt-preset normal is no more. I removed that. It's back to standard/extreme/insane now.
2. --alt-preset standard has been modified to include many of the changes or tweaks I learned from my experience with --alt-preset normal.

List of What's New in --alt-preset standard and which clips it helps or what it does:

- tweaked block switching thresholds (helps fatboy and florida_seq)

- --nsmsfix 2.13 is used now in addition to internal modifications to masking thresholds of mid-side channels. These two in combination allow for less ss frames (reduced bitrate) in situations which do not seem to need them as much and more where they are necessary (serioustrouble for example)

- added method to switch noise measuring functions on non-normal blocks (start, short, stop) (helps fatboy and other impulse samples)

- added method to switch noise shaping functions depending on athadjust (helps fatboy and other impulse samples)

- added --athlower -1 (decreases bitrate)

- changed --ns-sfb21 3 to --ns-sfb21 3.75 (decreases bitrate)

- changed lowpass to 19khz (decreases bitrate)

- What all this means? That --alt-preset is now lower in bitrate (competitive with --r3mix) and higher in quality than before.

Many of these changes are activated only with --dm-preset standard (appropriate tweaks will eventually propagate to all --alt-presets) as a switch, there are no external switches to turn them on and there will not be any added. The reason for this is because doing such a thing would add quite a few new experimental switches which really should be handled internally in the first place, not to mention most of these modifications are tuned right to the threshold, there's not much room for tweaking without further code level modifications.

Clips which are significantly improved over the old dm-standard include fatboy, ravebase, gbtinc, serioustrouble, and to some extent short.

Many clips now encode to a much lower bitrate with essentially identical quality.

Clips which --alt-preset standard significantly outperforms --r3mix on include:

amnesia
2nd_vent_clip
serioustrouble
death2
castanets
short
ravebase
gbtinc
florida_seq
fatboy
gekkou-intro
velvet
etc..

There a lot more, those are just the ones that come to me off the top of my head. As it stands right now I don't believe I know of any clip where --r3mix is even marginally better sounding anymore. Before --r3mix did a little better on fatboy due to some flaws in masking/noise shaping which I have now compensated for in the new mode.

As with --alt-preset normal, the theme stays basically the same:

- On heavily distorted clips like metal, this preset will often provide a lower bitrate (bitrate may be reduced even more, theres some stuff with the joint stereo that could possibly still be tweaked better).

- On quieter clips this preset should not dip as low, and on quiet clips with lots of transients (such as death2) this preset will scale upwards accordingly instead of sticking with too low of a bitrate.

This preset basically also shouldn't bloat on quieter samples to the degree that --alt-preset normal did. It also doesn't have ath problems -- try encoding the love.wav sample for example... solid frequency encoding all the way up to 16khz, which is higher than --r3mix's (13khz with some speckling upwards) and standard still manages to encode to a lower bitrate!

I'm including the source also, but keep in mind that parts of it are kind of hackish, certain command line settings are overridden internally (sometimes with hardcoded values) at the moment because I haven't had time to implement everything "properly" yet. This will not be the final source. Also, many of these changes seem a tad underwhelming considering how long in the making they have been but keep in mind that it's the tuning that's the hard part.. actually finding out where to make the changes and what actually works.

That's about all I can think of for now...

Oh one last thing.. I'm aware of certain people going back to using sine sweeps to test presets now and I just want to say that that's about the most foolish way to test for quality. In addition, designing presets around sine sweeps is even more pointless. Part of the problem with many of the sine sweeps people are using is that they induce clipping and contain frequencies of such high amplitude all the way to 22khz that they artificially induce artifacts. Udial.wav is a perfect example of this. These samples are totally pointless because you are never going to hear them in real music (the risk of blowing speakers out is too high for one, not to mention they hurt your ears). So if you see someone passing judgement on something based on a single sine sweep test alone, make sure to take that with a grain of salt.

All the presets I work on are tuned with a multitude of extremely difficult samples from real music. They come from all different styles from acoustic, to heavily distorted, to bizarre electronic, to classical and nearly everything in between.

The argument that sine sweeps may be representative of some fringe electronic music is flawed IMO because I happen to listen to quite a lot of the more unusual electronic music (autechre, two lone swordsmen, pan sonic, brume, v/vm, etc just to name a few) and I've never heard a sample like udial.wav or some of these clipping inducing sine sweeps in any of them. Just a bit of perspective there...

Anyway, enjoy the new preset (it might have some bugs but I think it's fairly solid). Feedback is appreciated as always. I'll try to come read and respond to posts here as much as I can but no guarantees on being able to answer rapidly or anything like that.

Yes, sinesweeps seems to be an issue which comes up now and then. It's gotta be understood by people that sinesweeps do not represent in practise anything about the true quality offered by codec or a setting. You should NOT make a choise of codec or setting based on performance with sinesweeps, because most of the time the tester has no idea what is actually happening and why. He/she just sees probably clipping of near full scale sinesweep (or near Lame's lowpass case, distorted) waveform, and then makes decisions/conclusions. Sinesweep test, if even done should be absolute last in the sample testing phase, and should not be given nothing else than theoretical value at most. Unfortunately, because it's so easy to do, and possible clipping etc. easily audible, people use those instead of wide variety of real psychoacoustics stress samples which would show real effects of settings.
In some forums people are actually choosing settings based on performace with something like fatboy and sinesweep test. They have no idea, that a setting could do very much better overall if sinesweep test wasn't the decision maker... Of course with luck anything is possible, but then it's just it..luck.

Heh, recently I actually suggested to Dibrom something regarding sinesweeps, because there are always people who judge and make decisions based on this flawed method. Unfortunate but true.

Wow! great work Dibrom!

Thanks for the comprehensive post with great explanations
and good examples...

I agree with you about sine sweeps...

Yes, thanks for a comprehesive description on the tweaks/updates. Looks good!

It even "sounds" promising!

The short block switching seems more carefull and low diving
with silent parts isn´t a problem anymore.

I once stated alt-normal reminds me on the muffled sound of fhg sometimes,
this is no more the case with this new standard setting as far as i
can tell till now.

Good work!

A "mitiok-quality compile" would crown this thing.


Wombat

Thanks all

I'll just add a few things here in case people are wondering (seems as though there may be some confusion):

1. --alt-preset standard is basically taking the place of what the old --alt-preset normal was trying to achieve. There are a number of reasons for deciding to do things this way. One is that the old preset standard didn't do as well as normal on some clips, but normal was bloating on quiet samples (not much I could do about that because of the way it was designed). This "new" standard should pretty much combine the best of both worlds and discard the worst from each at the same time.

2. --alt-preset standard should now be in the bitrate range of what --alt-preset normal was providing (as well as --r3mix). On quiet samples it will provide a lower bitrate than --alt-preset normal was providing (still without usually going too low) though on some metal it may be encoding to a slightly higher bitrate (maybe somewhere around a 10kbps increase over "normal" on the more worst case scenarios), this really depends though. So overall the bitrate should pretty much even out.

3. --alt-preset standard's previous weaknesses (in the form of impulse handling) should be mostly eliminated now. There is really no need for -Z or -X3 or anything like that. In fact in the current build they won't work anyway since they are overridden internally at the moment since they switch around depending on the situation.

At any rate, the main reason I mention this is so people don't think I totally scrapped the idea behind --alt-preset normal... that's incorrect, I just scrapped the current approach I was taking (which was more complex and didn't work as well overall IMO).

In one word: Outstanding! :flipoff:

I think that I just might have reached what I need with this brilliant design. Yeah it's :insane:

Thanks a lot, Dibrom! How can we repay you for the effort?

regards stoff

And now for some more :listening !

Edit: The hi-hat part in the AQ-Test seems improved. It's more "dry" now. Very nice...

Great news and great job, Dibrom!

Wow,

Feedback (for example, on love.wav) translates into near instant improvements. Very impressive.

ff123

Nothing more I can add! It sounds great, thanks.

john33

Congratulations! I tried rev7 on 4-5 CDs (mostly metal) and it sounds great!



Wow! Absolutely transparent and on a lower bitrate! Excellent!

The short-block behavior didn´t change in relation to lame rev6! Seems to work!

Just to prevent some misunderstanding.

Wombat

Excellent! Thanks to the source being available i could compile this version in both FreeBSD and Linux machines; i finally implemented the line --alt-preset standard -Y --lowpass 16 for the community FM radio i'm helping Just in case somebody wonders, the src in the .zip won't compile out of the box because the execute permission on some files needs to be restored, and all the source text must be converted back from DOS to UNIX style.

I made the corrections and used the source that compiled succesfully in FreeBSD 4.4 and SuSE 7.1. The source fixed to compile out of the box is here if anyone needs it (Oh, i did "make distclean" too)

http://home.dal.net/artemis3/lame_dm_rev7-src.tar.bz2

Compiling is easy, just untar the file and follow the usual method:

tar xjfv lame_dm_rev7-src.tar.bz2
cd lame_dm_rev7
./configure
make (or gmake if freebsd)
su (password)
make install

That's it!.

I hope some or all of Dibrom's efforts make it back to the main lame source.

Thanks for fixing this.



If you have nasm and are running on an x86 platform try this instead:

./configure --enable-nasm --enable-expopt=full

This should provide you with a faster compile.

If you are going to be running the program on a Linux box at the community radio, you also might also want to try out the ICL compiler for Linux.



They should, I just haven't committed this stuff yet cause I wanted to give it some time to be tested first just in case

Dibrom--

Thanks for the great work. As I personally do not have golden ears, it is important for me to try and keep bitrates down as the extra information is often wasted on me. This release does a great job at that! Thanks!

Boston - Dont Look Back:
r3 - 219
dm6 - 235
dm7 - 216

Chicago - I'm A Man:
r3 - 199
dm6 - 238
dm7 - 201

Roberta Flack - Feel Like Makin Love:
r3 - 188
dm6 - 236
dm7 - 199

Anne Murray - Another Sleepless Night
r3 - 143
dm6 - 175
dm7 - 169

Great Improvements. Definately competitive with r3mix bitrates.

Update:

The entire Boston - Greatest Hits album ecodes with an average bitrate of 204 with rev7, as opposed to 225 with rev6, and 202 with r3mix. Interestingly one song, Peace of Mind, actually went up 5kbps from 215 in rev6 to 220 in rev7. I think its interesting because this was one of the few songs where rev6 was actually lower than r3mix which also used an average of 220.

All in all, highly competitive in bitrate to r3mix!

Update 2
Kansas - The Best of Kansas
rev7: 192 (avg)
rev6: 217 (avg)
r3mix: 179 (avg)

Dibrom,

I have some quesions:


Are these block switching tweaks also in --alt-preset extreme? Also, exactly what basic improvements have been added to --alt-preset extreme? Could you elaborate on what is offered in --alt-extreme high or what is changed? And, has the old --dm-standard become the new --alt-extereme?

mp3

Some especially lower volume music can still be quite a bit higher bitrate than r3mix, but anyway rev7 sounds much better.

Here's one nice example, a normal natural trumpet solo. http://sivut.koti.soon.fi/julaak/dr4.flac
rev7 has about 40kbps higher bitrate on this one, but listen at the trumpet sound especially at about 11.5sec (the loud trumpet sound after the break). --r3mix is quite badly distorted and rough, not sounding smooth at all.
So the higher bitrate of rev7 is not in vain here.

Good job Dibrom.

Not yet.



None. Unless specified otherwise, nothing else has changed at the moment.



Same as above, all the other presets should be unchanged from how they behave in the latest official alpha.



No, and this isn't going to happen either. The old --dm-preset standard is gone. It doesn't make sense to move that to extreme because extreme is higher quality in the areas that standard had problems in (which I've now fixed obviously). What will happen is I will apply a few of these things to extreme when I get a chance and I'll try to lower bitrates a tad in that preset also, to make the transition in bitrate from standard to insane more linear again.

Thanks.

About this clip, this would definitely fall under the "not dipping too low" issue I think. ~170kbps (for standard) is really a pretty decent bitrate especially if it offers much higher quality. I'm not really going to be too concerned about the bitrates of quiet music going to high unless they begin to significantly go over 200kbps. Seems like things are mostly under control now though according to TheBashar's results.

At any rate it seems that this preset is averaging bitrates close to ~200kbps (across genres and albums) with a good degree of regularity... probably ranging from around 160-220 on most things

Yeah, standard 173kbps is very acceptable here. r3mix's 134kbps is apparently too low and the distortion is very noticeable, even more so the lower volume you use!

Never actually tested r3mix very much, because it fails somewhat harder clips badly already. I'm not sure what its problem is, but even tweaked 112cbr line handles the 11.5sec position much better than r3mix. If this is a trend in many cases, something should be done...

[edit.] Hmm, now this starts to be more like --r3mix bashing than rev7 quality reporting, but r3mix just gives weird distortion with standard EBU SQAM harp: ftp://ftp.tnt.uni-hannover.de/pub/MPEG/au...am/harp40_1.wav
The first second and the other part (it's played twice) sounds very weird. There's like single "artifact" sound in the backround in the original, but r3mix's first second is clearly very much different, it's distorted all the way (very noisy), same thing around 10sec when it starts again.
Has somebody actually done any serious listening tests with --r3mix??
Problem is that it just isn't even meaningful to do rev7-standard vs r3mix bitrate comparisons when r3mix fails almost every sample I throw at it...

3 things which I think are likely the cause:

1. The ath is probably too low (athtype 3 = athtype 4 + --athlower -6) and it is not directly compensated for with any special techniques (like I did with --alt-preset normal)

2. -X0 instead of -X1 (or in the case of standard, the hybrid adaptive modes)

3. msfix of 3.5. Contrary to popular belief, I have discovered that joint stereo in LAME can still cause some artifacts on occasion but they are not probably what one would normally expect. A long time ago during testing many of us found that --nssafejoint helped with dropouts, pre-echo, and other distortion but until recently, at least I wasn't sure exactly why. Well it appears it has to do with the calculated masking thresholds that msfix adjusts. You don't get stereo field errors exactly, but you can get gaps in the frequency range. I believe some of this may somehow be related to a not well enough tuned spreading function also. Serioustrouble is the perfect example of this. If you encode with --nssafejoint --nsmsfix 3.5 and look at the spectrogram and listen to the file, you will hear the dropouts. If you use --nssafejoint (which without --nsmsfix defaults to msfix 1.0) you see these artifacts are gone. Looking at the layout of the spectrogram it seems likely that masking is not calculated accurately enough in these situations and that the high msfix value makes it much worse.

At any rate, perhaps this dr4 clip creates a similar situation and since I was able to tweak the masking thresholds internally, aside from msfix, --alt-preset standard is unaffected. In fact, with --alt-preset standard, it is tweaked in a way to where when the psymodel decides that the need arises to modify the masking thresholds, where nssafejoint would use msfix 1.0 instead the new standard mode uses msfix .5, so it is actually more conservative in a way in those situations. This seems to allow for the elimination of those dropout issues with a high msfix value, but without bloating the bitrate unnecessarily due to using excessive stereo frames on everything else.

Anyway.. it's probably a combination of all 3 of those things and maybe even some other things. Probably all of the areas that are tuned in --alt-preset standard to outperform --r3mix have an effect of sorts on these types of situations.

Personally though, I don't really see a reason to use --r3mix at all anymore except for encoding speed. This new standard mode really is quite within the range of --r3mix as far as bitrate goes (and it may be tweaked even lower still) and there is no doubt that the sound quality is significantly better.

I just have to say that this should really be significantly emphasized.

This is the [b]exact reason that it has taken so long and has been so hard to get bitrates down to the --r3mix level but without compromising the quality that --dm-preset standard used to offer. If something is using a significantly lower bitrate, but the quality isn't there... then expecting something offering significantly higher quality to match that bitrate is a bit of an unreasonable expectation.

However, that being said.. it does appear that this has been accomplished now And to make things better, the quality of the new standard is even better than before! Who'd have thought...

Dibrom

I encoded an album of Schubert Piano Sonatas using Rev.7 - Standard. The result is a range of 151-165kbps. With 'normal', it was 30-40kbps lower! BUT, considering the gains elsewhere, this is an awful long way from unacceptable. For most of what I have tested 'standard' seems to average around 190kbps with superb quality (for MP3!!).

john33:)

I got this error, using NASM version 0.98.08 on Linux. It looks like scalar.nas isn't compatible with nasm. The other .nas files were processed without any problems.

/usr/local/bin/nasm -f elf -i ../../libmp3lame/i386/ scalar.nas -o scalar.lo -l scalar.lo.lst
scalar.nas:15: error: parser: instruction expected
scalar.nas:16: error: parser: instruction expected
scalar.nas:36: error: parser: instruction expected
scalar.nas:37: error: parser: instruction expected
scalar.nas:69: error: parser: instruction expected
scalar.nas:70: error: parser: instruction expected
scalar.nas:114: error: parser: instruction expected
scalar.nas:115: error: parser: instruction expected
scalar.nas:171: error: parser: instruction expected
scalar.nas:172: error: parser: instruction expected
scalar.nas:240: error: parser: instruction expected
scalar.nas:241: error: parser: instruction expected
scalar.nas:321: error: parser: instruction expected
scalar.nas:322: error: parser: instruction expected
scalar.nas:431: error: parser: instruction expected
scalar.nas:432: error: parser: instruction expected
scalar.nas:433: error: parser: instruction expected
scalar.nas:481: error: parser: instruction expected
scalar.nas:482: error: parser: instruction expected
scalar.nas:483: error: parser: instruction expected
scalar.nas:533: error: parser: instruction expected
scalar.nas:534: error: parser: instruction expected
scalar.nas:552: error: parser: instruction expected
scalar.nas:553: error: parser: instruction expected
scalar.nas:578: error: parser: instruction expected
scalar.nas:579: error: parser: instruction expected
scalar.nas:611: error: parser: instruction expected
scalar.nas:612: error: parser: instruction expected
scalar.nas:651: error: parser: instruction expected
scalar.nas:652: error: parser: instruction expected
scalar.nas:698: error: parser: instruction expected
scalar.nas:699: error: parser: instruction expected
scalar.nas:751: error: parser: instruction expected
scalar.nas:752: error: parser: instruction expected
scalar.nas:819: error: parser: instruction expected
scalar.nas:820: error: parser: instruction expected
scalar.nas:821: error: parser: instruction expected
scalar.nas:867: error: parser: instruction expected
scalar.nas:868: error: parser: instruction expected
scalar.nas:894: error: parser: instruction expected
scalar.nas:895: error: parser: instruction expected
scalar.nas:928: error: parser: instruction expected
scalar.nas:929: error: parser: instruction expected
scalar.nas:964: error: parser: instruction expected
scalar.nas:965: error: parser: instruction expected

This is just what I was about to report! Three different rock-albums - REM Reveal, Placebo's Black Market Music and Neil Youngs Weld I (live) - all hit right about the 190kbps mark. It's almost strange

I should also note that my most bitrate hungry track now tops out at 232.

This is all good news, and I personally don't need more tweaking in order to get the bitrates down when that might compromise quality... IMHO

regards stoff

Hrmm.. not sure exactly what the problem there is, but nasm does compile those files correctly and I've done it before on linux and cygwin as well. Sorry I can't really offer any great insight though.

Ahh.. this is all really good news then

Glad to hear this... and if nothing really seems to come up, I'd say this may actually be representative of the final revision that will make it to CVS.

I've been wanting to try the alt-preset setting for a while.

Thanks for releasing source so us non-Windows folks can have a go! I'm off to give it a whirl on Solaris...

--jth

i'm afraid you have red hat nasm....

change it please

http://homepage1.nifty.com/herumi/soft/petit/nasmsse2.tgz

Just so everyone knows, mitiok has made a really nice and fast compile of this build available here:

http://mitiok.free.fr/lame_dm_rev7-bin_f.zip

Mitiok:

Thanks for the fast compile! Can you explain how you are getting this compile to run so fast? Specific information on compiler versions used and makefile options and everything would really be helpful.

Hi to all!
I just downloaded Mitiok's fast compile and encoded a song to test the speed. For a 5 minute song, encoding time was reduced from 3:48 to 2:45 on my machine. Excellent!
However, I also noticed a slight bitrate increase from 178 kbps to 185 kbps. Is this supposed to happen? Of course the difference in very small but I just think you should know.
I'll go encode some more songs to see what happens


Updated:
I encoded 9-10 more clips and the difference in size remains constantly 6-7 kbps larger for the fast compile

About nasm: it seems that you have a RH 7.2 nasm. Please use another non-RH nasm.

How many of the tweaks works with --alt-preset fast standard ? Is this like before: we can expect slightly higher bitrate but no substantial loss in quality with the higher speed?

/Erik

eb

Just for the record, you get the same problem in Windows if you don't use the right version of NASM. If I remember correctly, the problem is that the correct versions of NASM provide 'Windows' style macros which is what scalar.nas (and fft3dn?) use for directly relating 'C' functions to nasm. The 'wrong' versions of nasm don't recognise this macro construct and report a 'parse' error.

john33

Yes, this is a known issue with the faster compiles. All vbr modes (--r3mix or anything else includes) should produce slightly larger files. That's the price to pay for speed in this case I guess.

None yet. This is what I will probably work on next.. I have some ideas which may work out pretty nicely here but I'm not certain yet.



Hrmm.. probably not quite like this. Faster mode will probably be a little lower in quality, bitrate will probably stay fairly similar.. not sure yet.

another vote of thanks to dibrom for providing the source. i got it compiled and it's running great with "--alt-preset standard" in mac osx v. 10.1.1. nothing special was required to get it to compile. of course, without the source i'd be locked out of the new v7 presets for the time being, so again, many, many thanks!

brett.

Hi Dibrom...

I would like to find out which samples that this otherwise brilliant tweak still doesn't quite cut it on (if any !).

I'm asking because I'm trying to find out how it'll perform in a worst case scenario. If there isn't any hefty artifacts left (to my ear anyway) it'll give me a nice peace of mind.

If you don't have the time to answer demanding questions like this it's really okay though!

Regards stoff

Hi, Dibrom!
Since I'm trying your new rev.7 settings, I'm making some strange experience:

I've encoded some 20 tracks with very complex contemporary classical music using the new standard switch.
I got mp3-files with 160~210 kbit/s that sound great. But when I encode these files with --alt-preset extreme (using the rev7 -compile) I always get smaller files.
I didn't make a listening test on these "extreme" files, but I thought that your intention for your "standard" preset was to produce smaller files than with your "extreme" preset.

"Simpler" material gets bitrates between the r3mix-preset and the extreme setting, often very close to the r3mix-bitrate.

[U]Just added:[U] I'm just going to encode with mitioks fast compile from 112001 with "xtreme" and now I'm getting much bigger files 230~280 kbit/s. So in my opinion there must be an error in your (and mitioks) compile with extreme setting.

Some explanation?

Hey Music Mafia. The answers to all your quesions are in this thread already... Read the 18th. post in this thread...
Extreme & insane dont yet include the techniques used in standard.. but will soon.

Mitiok's fast compile produces larger files with every settings.

Something interesting to the size.

I tried --r3mix with mitioks fast compile (this thing heats up my CPU more than any other compile)
Filesize: 7.957.276

A mitiok standard compile from 20.11.01
Filesize: 7.957.276

Lame_dm_rev_7 dibrom compile
Filesize: 7.642.135

--r3mix doesn´t have changed in the source otherwise mitioks compiles would differ

I used r3mix cause this is the only thing that shouldn´t have changed by these different versions for sure.

edit:
There comes me to mind that i use an Athlon XP.
Could it be that mitiok uses SSE or 3Dnow somehow in all compiles
and the one from dibrom none of it?

:confused:


Wombat

Hi, JohnV!

The results of one of my testfiles: (always "extreme" preset)
12.237.540 Byte (dibroms compile rev7)
12.650.573 Byte (mitioks fast compile rev7)
16.622.419 Byte (dibroms compile rev6)
17.926.190 Byte (mitioks fast compile rev6)

So the last two outputs are just what I expected as "correct" results for dibroms "extreme" setting. There must be an error in rev7!

In dibroms 18th. post of this thread he wrote that nothing changed between rev6 and rev7 regarding the "extreme" preset.

Please clear this!!

Hmm, I didn't know there even was rev6 Mitiok compile. Well anyway, yes there seems to be "issues" with extreme profile and may be even with insane. Latest official Lame alpha --dm-preset xtreme is different than lame rev7 --alt-preset extreme.

Anyway in rev7 Dibrom concentrated on standard preset. I would wait he actually checks extreme and insane out and adds techniques used in standard.

I also noticed Dibrom that official alpha Lame --dm-preset insane encoded fatboy.wav sounds better (less pre-echo durin 2-5sec) than rev7 --alt-preset insane. So there seems to be differene with insane profile also. But lets just wait he checks these out. I suppose nobody has encoded his entire CD-collection with unofficial test version anyway...?

I think you're right, JohnV, I am sure that Rev.7 is the only Dibrom Rev that Mitiok has posted.

If there is anyone out there who is totally committed to using CDex with the Lame DLL and wants to use Dibrom's Rev.7 with the new --alt-presets, I can offer a VERY QUICK AND DIRTY solution!! It is NOT pretty, but it works. It maps to the QUALITY options as follows:
[list] . I don't have a site to post this at but if anyone wants to, go ahead. This is compiled with MinGW32, so it's not that quick, but it does work.

I only did this for fun! Someone further up the thread referred to using the DLL with CDex, so I thought I would go play!

Obviously, there would need to be changes to CDex to make this more elegant, and I don't think I am about to do that!!

john33

To my knowledge, the samples which still may have some problems (and this may not be the case for lots of people) are the ones that exploit the weaknesses in the format itself. Clips like death2, castanets, and fatboy are probably never going to be "perfect" with MP3.. but as far as MP3 goes, this preset does a pretty nice job on those.. better than most other encoders/settings I know of.



I'd suggest trying out those clips I mentioned then. Some of them can be found here: http://www.animus-facticius.org/problem_clips/

Just a quick note to everyone. I do not advise to use rev7 for anything else than --alt-preset standard. No other presets have been updated, and some of the changes I made may have affected other things inadvertently. As I said most of the stuff I just threw together and the source isn't final at all, I just wanted to release something for other people to be able to compile with for the meantime. So if you are using another preset, do not use this compile for now.

O.K.
I'm sorry, but of course I was wrong with mitioks fast rev6 compile - this has to be (probably) dmitris fast compile from 112001 (In those zips I always miss any revision history or even a file_id.diz). But anyway this compile produces exact the same output as the last "official" alpha9 20011201.

The reason for the filesize difference is that my compile was just pure MSVC (I don't have access to ICL at the moment) while Mitiok's compile was ICL. The Intel Compiler produces slightly larger files, that's all.

I'm hoping I can get more details on exactly how Mitiok is making this new faster compile than before though. It would be helpful to have that information so that I could compile my own builds in the same way....

Yeah, there was no rev6 compile from anyone else. As far as I know, the "fast" compile just uses some extra compiler optimizations for speed... but I have no idea what they.

It appears that the one using Mitiok's compile used slight more LR frame than MS. Dibrom, you mentioned that they were some internal changes, perhaps it didn't get imported fully from yours to Mitiok's (I have no prove, just shooting in the dark, please don't laugh at me if this is not true).

Hope this helps...

rev7
average: 209.8 kbps LR: 1876 (68.14%) MS: 877 (31.86%) 2.0778x

mitiok's rev7
average: 215.8 kbps LR: 1883 (68.40%) MS: 870 (31.60%)
2.5624x

rev2 (the lowest kbps one prior to rev7)
average: 222.9 kbps LR: 1131 (41.08%) MS: 1622 (58.92%)
1.1942x

using --dm-preset from lame alpha
average: 200.2 kbps LR: 2660 (96.62%) MS: 93 (3.378%)
1.9941x

Dibrom,
How did you manage to keep the bitrates down, yet increased the frame usage of LR?? Amazing.

Should it be a concern that the --dm-preset standard used more LR frame than the --alt-preset. Are those part of the tweaks that the LR frames are not so noticeable so that they can combined into joint?