Adjustements to medium and medium1
Very small adjustement to standard.
Tuning of extreme.
I'd appreciate feedback about medium and medium1, as I do not know which one to choose.
Where can the binary be found please ?
Where can the binary be found please ?
At my 'Other' page at Mirror 1, link at foot of main page.
John, why use ICL6? Your own tests with oggenc showed that ICL7 is usually faster and produces results that are closer to the "reference" vc6.
FWIW, I definitely prefer --medium over --medium1. M1 has this metallic harshness to it that M doesn't. M on the other hand is a little more flat, but that's not nearly as objectionable.
John, why use ICL6? Your own tests with oggenc showed that ICL7 is usually faster and produces results that are closer to the "reference" vc6.
FWIW, I definitely prefer --medium over --medium1. M1 has this metallic harshness to it that M doesn't. M on the other hand is a little more flat, but that's not nearly as objectionable.
That was with the P4 optimised versions. In all other cases, so far, I've found the ICL7 versions compiled against the VC7 libs to be slower, and the ICL7 versions compiled against the VC6 libs to be no different. Worse, there are some instances where there is clear evidence that ICL7 is not as well integrated with VC7 as Intel would have you believe.
What would make more sense really, would be for me to compile all LAME versions against ICL4.5!!
I encountered the following error message in the log file after encoding a track with --alt-preset standard:
Command: C:\Temp\Downloads\lame.exe --alt-preset standard "C:\pulp\Pulp - Disco 2000.wav" "C:\pulp\Pulp - Disco 2000.mp3"
LAME version 3.94 MMX (alpha 11, Feb 9 2003 11:16:20) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding C:\pulp\Pulp - Disco 2000.wav to C:\pulp\Pulp - Disco 2000.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
RazorLame encountered an unknown message from LAME while trying to encode "C:\pulp\Pulp - Disco 2000.wav"!
Encoded 0 files in 0:04:18
There was an unexpected LAME message for one file, please check log for error messages.
Despite saying that it encoded no files, it did completely encode the track, and it sounded fine.
Filesize of the MP3 was 7,479,416 and averaged at 219kbps.
With my usual LAME version, 3.92, using --alt-preset standard, the filesize is 7,994,548 and averages 234kbps.
the reason of that is because of the frontend.
As it says clearly, it has read a sentence that it doesn't expect. It might perfectly be this one "warning: alpha versions should be used for testing only" although I'm not sure.
For the general rule, don't use frontends for testing versions, and of course, don't use testing versions for real encodes.
Nah, I was testing.
Yeah, I realised that it might be the case after I posted it... thought I'd leave it up just in case, though. If it's just the usual alpha message that RL is not recognising then no problems.
Not sure if this will be of use to decide, but I've made some comparisons.
I can hear differences between standard and medium (haven't spent the time on ABX'ing, don't get this for sure, but I seem to hear a little bit of flanging on a cymbal and more noisy on a saw sound).
When trying to find differences between medium and medium1, I haven't succeeded (on this file, music made with PC and software synths).
And bottom line : Will the speed improve? It's half the speed now!
-3.90.2 -aps :
8252/8255 (100%)| 1:20/ 1:20| 1:21/ 1:21| 2.6866x| 0:00
32 [ 1] *
128 [ 544] %%%%**************
160 [ 988] %%%%%%%%%%***********************
192 [1361] %%%%%%%%%%%%%%%%%%%%%%%%*********************
224 [1949] %%%%%%%%%%%%%%%%%%%%%%%%%%**************************************
256 [2037] %%%%%%%%%%%%%%%%%%%***********************************************
320 [1375] %%%%%%%%%%%%%%%******************************
average: 228.6 kbps LR: 2893 (35.05%) MS: 5362 (64.95%)
3.94a11 -aps:
8252/8254 (100%)| 2:24/ 2:24| 2:24/ 2:24| 1.4877x| 0:00
32 [ 1] *
96 [ 150] %%*
112 [ 134] %**
128 [ 263] %****
160 [1288] %%%%%%%%%%%************
192 [3753] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%************************
224 [1836] %%%%%%%%%%%%%%%%%****************
256 [ 646] %%%%%%******
320 [ 184] %%**
average: 196.9 kbps LR: 4453 (53.94%) MS: 3802 (46.06%)
3.94a11 -ap medium :
8252/8254 (100%)| 3:12/ 3:12| 3:12/ 3:12| 1.1227x| 0:00
32 [ 88] %%
40 [ 14] %
48 [ 6] %
56 [ 16] %
64 [ 25] %
80 [ 81] %*
96 [ 158] %**
112 [ 410] %%******
128 [ 888] %%%%%************
160 [3489] %%%%%%%%%%%%%%%%%%%%%%%%******************************************
192 [2315] %%%%%%%%%%%%%%%%%***************************
224 [ 574] %%%********
256 [ 154] %**
320 [ 37] %
average: 166.0 kbps LR: 2747 (33.28%) MS: 5508 (66.72%)
3.94a11 -ap medium1 :
8252/8254 (100%)| 3:01/ 3:01| 3:01/ 3:01| 1.1903x| 0:00
32 [ 1] *
80 [ 135] %%**
96 [ 207] %****
112 [ 542] %************
128 [1205] %%%%%%***********************
160 [2840] %%%%%%%%%%%%%%%%%%%%%%%*******************************************
192 [1811] %%%%%%%%%%%%%%%%%%%************************
224 [1039] %%%%%%%%%%***************
256 [ 374] %%%******
320 [ 101] %**
average: 170.6 kbps LR: 2709 (32.82%) MS: 5546 (67.18%)
Hmmm, it seems as though the -b 128 (except for silence) has also been omitted from the --aps in this latest alpha. This results in an incredibly low average bitrate for one of my favourite tracks. Unkle - Rabbit In Your Headlights, comes out as averaging 138kbps! I've abxed it against my current 3.92 --aps encode, and can't tell the difference though, so I suppose there is no need to worry, at least for me. Here's a grab of the bitrate allocation for reference. I couldn't help but be surprised at the amount of 112kb frames used; although the track can be quite quiet in places, there is no silence (apart from the usual small segments at the very beginning and end of the recording, which I assume is where those 32kb frames come in).
(http://flaps.netfirms.com/rabbit394a11.jpg)
This is the allocation for the same track encoded with 3.92:
(http://flaps.netfirms.com/rabbit392.jpg)
Quite a difference. I've read most of the previous threads on the alpha, and know that the VBR presets are undergoing changes, so I'm not panicking; just posting results to make sure that the changes are all as intended.
I prefer just medium. Both are not transparent so it is just a preference to me... Abx for preference Medium1 v medium 12/15.
What are your plans for the current dm presets? Will they stay or be ommited? And r3mix?
My vote is to include dm-radio and dm-portable omit dm-medium and include r3mix. It doesn't make sense to include 2 medium presets. I think r3mix should stay just because it provide fairly good quality at a much faster speed than any of the other presets.
dm-xxx presets were just experiments from Dibrom, and were not final. They are used as one of the many sources of information by me, and will not be part of the release (in agreement with Dibrom)
I'd appreciate feedback about medium and medium1, as I do not know which one to choose.
Medium fares better than medium1 in most of the cases I've tried. It is almost always higher in bitrate, however.
Medium needs the -b 128 switch added.
Try it with this clip: First seconds of Steve Ray Vaughn's Crossfire (http://mywebpages.comcast.net/mithrandir/crossfire.flac).
Encode with --preset medium and --preset medium -b 128. The latter has better noise control and increases filesize (the whole 4:11 track) by only 0.3% or 0.5kbps.
From this I take it you plan to create a portable and/or radio presets.
Removal of the dm-xxx presets is a good idea in this light.
Are plans for tweaking of extreme planned?
And R3MIX? I am still of the opinion it should stay in the codec. Perhaps with a note : Use preset standard for higher vbr quality.
@LordofStars
if you need more speed you could try "--preset fast standard" instead of "--r3mix"
I have. R3mix is still much faster. I only use it for my portable anyway. And half the time I use gogo at b192 anyway.
Still its a pretty well tuned preset although deprecated its pretty much the best quality you can acheive with standard switches. Alot of people still use it and just switching it on them will tweak alot of noses. I believe adding a note that aps is better quality should be sufficent.
Still its a pretty well tuned preset although deprecated its pretty much the best quality you can acheive with standard switches.
I have to disagree with this on both counts.
--r3mix was never really "well tuned". Many problem issues were simply ignored, and most testing was not rigorous or even blind (Roel was not an advocate of abx testing). What's worse is that the "newer" --r3mix that uses nspsytune is likely worse in many ways than the old version. We'll never know exactly how much though because there was overall very little testing utilized in deciding upon switches. Furthermore, Roel always favored using switches that affected bitrate
first and quality
last -- he simply felt that most quality issues were rather irrelevant. If this is how you feel also, that's fine, but that doesn't make --r3mix a "good" or even a "well tuned" preset in comparison.
And finally, I've
proven that the second part of your statement is false (best quality available with standard switches) with the original dm-presets.
Thanks for the clarification. Apparently I am still under the r3mix stigma. I had seen some tests floating around the web about r3mix vs dm-xtreme and others, but was under the impression that the dm presets used code level tweaks. Since this is not the case I would be interested in seeing the documentation about what switches the old dm presets used. Of course if you are willing to share this info. Perhaps if you do not have time you could tell which version the dm presets were in and I could check out the source and look at the switches myself.
Thanks for the clarification. I am greatly considering my plans for r3mix continued use. In fact I will probably just continue using apextreme for quality and gogo for speed and drop r3mix.
And with the second part of my statement I meant best quality at that bitrate with standard switches. Sorry for the mixup, but perhaps there was a dm preset that was better quality at that bitrate as well.
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?
ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?
ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.
...but surely that would be needless, as we have --alt-preset XXX already?
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?
ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.
...but surely that would be needless, as we have --alt-preset XXX already?
--alt-presets are tweaked for non-alphas. You can get better results than --alt-preset XXX or --alt-preset CBR XXX, by using some other and new settings.
I agree with mithrandir that some ABR setting should be tested against medium-VBR preset.
Ahhh I see, thanks.
But I'm still not really clear... if we had an --alt-preset (whatever), which produced an ABR 180 file, then we'd have the somewhat confusing situation where there would be two presets for the same bitrate (i.e. ABR 180), only one would be better... if the --alt-preset XXX can be made better, then why not do that?
Knowing how much mithrandir and John know, I dare say I'm missing something, though
...And having said all of that, out of principle I do agree that we should test some ABR settings against the "lower" VBR presets. I use the ABR presets with a custom lowpass a lot for radio recordings, and the predictability of the filesize is fantastic.
But I'm still not really clear... if we had an --alt-preset (whatever), which produced an ABR 180 file, then we'd have the somewhat confusing situation where there would be two presets for the same bitrate (i.e. ABR 180), only one would be better... if the --alt-preset XXX can be made better, then why not do that?
Before 3.94 is released, the --preset xxx switch needs to be revised so that it leverages the new tweaks. For instance, as the desired ABR bitrate increases we should have the preset scale the --shortthreshold switch from 4.5,15 to 3.5,15. If the ABR presets are left alone, they will all use the default value. This is suboptimal.
Presumably, if --preset medium produces a 180kbps ABR file then it would be ideal if --preset 180 would produce the same exact file. This kind of thing is possible because unlike Dibrom's --alt-presets, the new presets are packaged commandlines (at least I believe this is the case). They are "just" shortcuts.
It would be nice if LAME had a sliding quality scale like Vorbis and MPC and adding dynamic switch value logic to the ABR presets would be a fine, though admittedly complex, solution.
180 kbps ABR files as medium preset will often produce bigger files than preset standard with classical works. Especially with some quiet tracks. Maybe not a good idea...
The --preset medium, with lame 3.93.1, turns around 150-155 kbps, with my music. Sometimes below 140.
Yes, abr/cbr presets need some work.
I'll probably work on them this weekend, so next week you will be able to compare medium against abr.
And no, if preset medium is reaching on a specific track xxx bitrate, it should absolutely not produce the same output as --preset xxx. That would totally defeat the purpose of true vbr compared to abr.
Btw, I'm still waiting for opinions about this:
Which one seems better: medium or medium1?
180 kbps ABR files as medium preset will often produce bigger files than preset standard with classical works. Especially with some quiet tracks. Maybe not a good idea...
The --preset medium, with lame 3.93.1, turns around 150-155 kbps, with my music. Sometimes below 140.
I think gazzyk1ns meant 180kbps arbitrarily. If medium is mapped to an ABR commandline, the target bitrate would probably be in the 160-170kbps range.
I think ideally the worded presets would be all VBR...not because VBR is necessarily superior to ABR, but because you can always use --preset [xxx] to get ABR...and with music like orchestral/chamber/monophonic, ABR uses bits whether you need to spend them or not.
An action plan:
1) establish a very good medium VBR preset commandline
2) integrate the new switches into the ABR preset logic
The second task could be incredibly difficult IF you wanted every decision to be based on objective testing (i.e. you'd have to test --preset 80, --preset 96, --preset 112, etc. individually to make sure each uses the most transparent settings) but I think the team will end up making educated guesses.
And no, if preset medium is reaching on a specific track xxx bitrate, it should absolutely not produce the same output as --preset xxx. That would totally defeat the purpose of true vbr compared to abr.
Btw, I'm still waiting for opinions about this:
Which one seems better: medium or medium1?
We were talking that IF --preset medium were ABR instead of VBR (which isn't the case now) AND --preset medium was targetting 180kbps, --preset medium and --preset 180 would ideally be the same thing. But if the worded presets will remain all VBR, this doesn't apply.
Again, I'd have to give the nod to medium over medium1. I don't think I've found a case where one artifacts and the other doesn't, but medium often sounds better than medium1 when artifacting.
And just to make sure I'm not losing my mind, did you change the shortthreshold value for medium between a10 and a11? It looks like the value went from 3.5 to 4.25 across versions.
When will there be a LAME version which will totally improve on version 3.90.2?
Hydrogenaudio has been recommending 3.90.2 for ages now... Can we expect
anything exciting from the LAME front in the foreseeable future?
I'm just asking because I have a mass ripping & encoding session planned and
I'm wondering if there's a reason to postpone it in the event of a LAME 3.94
release...
When will there be a LAME version which will totally improve on version 3.90.2?
Hydrogenaudio has been recommending 3.90.2 for ages now... Can we expect
anything exciting from the LAME front in the foreseeable future?
I'm just asking because I have a mass ripping & encoding session planned and
I'm wondering if there's a reason to postpone it in the event of a LAME 3.94
release...
Not much reason to postpone if you use --alt-preset standard -Z with 3.90.2. Currently 3.94a --preset standard does not have as good pre-echo control, and if no tweaking is done, I suppose it will stay that way. If you use -Z with 3.90.2 --alt-preset standard, you either avoid completely or diminish the known problems very clearly with relatively small bitrate increase.
Also 3.90.2 --alt-preset performs better with serioustrouble (http://static.hydrogenaudio.org/extra/samples/test_samples/seriousTrouble.flac) and such (less ringing/dropouts).
In order to compensate --alt-preset standard's code level tweaks in this case, alpha imo needs switched to adjust mid/side masking and ms/lr switching separately. At the moment, if mid/side resolution is increased, it also gives more lr-frames and it leads to clearly higher bitrates, which takes most of the quality/size benefit away.
People with good pre-echo hearing can easily hear that 3.90.2 --alt-preset standard is better than a11 --preset standard for example with bassdrum (http://static.hydrogenaudio.org/extra/samples/test_samples/bassdrum.flac), and it's no wonder when you look the following bitrate distribution graphs:
Lame 3.90.2 --alt-preset standard
average 207.7kbps:
(http://sivut.koti.soon.fi/julaak/APS.png)
Lame 3.94a11 --preset standard
average 172.2kbps:
(http://sivut.koti.soon.fi/julaak/A11Std.png)
Not much reason to postpone if you use --alt-preset standard -Z with 3.90.2.
I've never used -Y or -Z with the --alt-presets before. Is there no down side
to using -Z?
I'm sure the experimental switches have been discussed before, but I'd like to
know if they make any difference...
Can -Z be used with ape and api too?
I've never used -Y or -Z with the --alt-presets before. Is there no down side
to using -Z?
No quality down sides with using Lame 3.90.2 --alt-preset standard -Z what so ever, only positive quality effects. But a bit higher bitrate sometimes. And using -Z here is not experimental, Gpsycho has always used noise shaping type 1, which is quality wise safer choice. Noise shaping type 2 is used with nspsytune vbr only because of one reason: to increase quality/size ratio by lowering bitrate, but it does not work 100%. erhu (http://static.hydrogenaudio.org/extra/samples/test_samples/erhu.flac) is a good example, where ns-type 2 fails badly.
Can -Z be used with ape and api too?
Do not use it with api, since it already uses noise shaping 1, and you don't want to switch it back to 2. But it's ok to use it with 3.90.2 ape.
Thanx John V
I've never used -Y or -Z with the --alt-presets before. Is there no down side
to using -Z?
No quality down sides with using Lame 3.90.2 --alt-preset standard -Z what so ever, only positive quality effects. But a bit higher bitrate sometimes. And using -Z here is not experimental, Gpsycho has always used noise shaping type 1, which is quality wise safer choice. Noise shaping type 2 is used with nspsytune vbr only because of one reason: to increase quality/size ratio by lowering bitrate, but it does not work 100%. erhu (http://static.hydrogenaudio.org/extra/samples/test_samples/erhu.flac) is a good example, where ns-type 2 fails badly.
Can -Z be used with ape and api too?
Do not use it with api, since it already use noise shaping 1, and you don't want to switch it back to 2. But it's ok to use it with 3.90.2 ape.
Interesting; Dibrom of the preset settings say that the -z switch is not needed for the alt presets:
Copy&paste from topic http://www.hydrogenaudio.org/forums/index....t=ST&f=16&t=593 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=593)
-
JohnV about covered the rest, but I'll just add a small comment here about this issue. First, the --alt-preset switches have been tuned to a level to where -Z is no longer needed.
-
I am talking about version 3.90.2; I know this is a bit off-topic..................
Mithrandir:
Thatnks for the clarification about the --preset medium settings, I see exactly what was meant now.
I just commited some updated abr/cbr presets. That way you can now compare abr against medium (I'd suggest you to wait tommorow in order to be sure that new compiles have the new abr presets).
I did not want to bump the alpha, as I'd like to take care of the pre-echo regression for standard before.
Btw, now that you pointed it, it seems obvious to me that current standard should regress in pre-echo compared to previous versions.
Damn, all this tuning is awfully time-consuming.
This is my first post ( but as i've been playing with LAME versions since 3.70, I don't consider myself a real newbie )
I've tried --preset medium with a collection of 50 of my favorite songs (50 diferent autors, music of very different kinds) and i've obtained an average bitrate of 172 kbps; which i think it's the ideal target bitrate for the medium preset. Not to low (at 150 kbps the quality can suffer a lot); neither to high (for such a high bitrate we already have --preset standard); it seem to me like the perfect equilibrium for portable players.
As a reference, LAME 3.90.2 goes to 203 kbps on the same collection of songs.
Gabriel, on some of those songs -- preset medium sounds to me a little better than medium1, but i haven't done a real blind test, so don't take it as something serious. I'll wait for the abr-tunned version to compare with --preset 172.
Hope that helps...
New win32 binaries uploaded and available at my 'Other' page at Mirror 1 (link at foot of homepage).
Note: Takehiro commited some changes during the week-end that are increasing bitrate by 2% on average.
John33
At your webpage the link is lame 3.94 alpha 11 bundle with a DATE = 2003-02-16
BUT the contained lame.exe has a version output: lame --version as: LAME version 3.94 MMX (alpha 11, Feb 9 2003 11:16:20) (http://www.mp3dev.org/) ; the same as your previous build. The filesize is also the same: 243.200 bytes.
Is this a coincidence? Haven't I found the correct link to the new binaries?
John33
At your webpage the link is lame 3.94 alpha 11 bundle with a DATE = 2003-02-16
BUT the contained lame.exe has a version output: lame --version as: LAME version 3.94 MMX (alpha 11, Feb 9 2003 11:16:20) (http://www.mp3dev.org/) ; the same as your previous build. The filesize is also the same: 243.200 bytes.
Is this a coincidence? Haven't I found the correct link to the new binaries?
You have the correct version. The problem arises, I think, because I only recompiled the changed modules, not a complete recompile. I'll do a full recompile and upload again just to avoid confusion. Give me about 10 mins. The recompile will carry today's date, ie. 17 Feb.
I know this is kind of an irrelevant question but I didn't want to start a new thread
over it:
Is there any way to make Windows XP display the bitrate of VBR mp3 files correctly?
I've encoded many files with the --alt-presets and when I open a folder with my
mp3s, the bitrates in the "bitrate" column are all wrong (and exaggerated). Can
this be fixed?
I'll do a full recompile and upload again just to avoid confusion. Give me about 10 mins. The recompile will carry today's date, ie. 17 Feb.
THANKS!!!!Well; it's not THAT important. It's only a doubt I had. But thank you; you guys are doing a really good job with this.
Is there any way to make Windows XP display the bitrate of VBR mp3 files correctly?
I've encoded many files with the --alt-presets and when I open a folder with my
mp3s, the bitrates in the "bitrate" column are all wrong (and exaggerated). Can
this be fixed?
Not that I know of.
Just finished testing a lot of "medium vs. meduim1" samples in ABC/hr.
I agree with most people here, --preset medium is slightly better. --preset medium1 tended to sound rather "swishy" at the top end, for a good example encode "Common People" by Pulp, and what I mean should be fairly obvious. I can provide a flac if anyone needs it.
One thing I was a little uneasy about was that to me (again, using ABC/hr) --alt-preset 192 sounded much better than --preset medium... and bearing in mind that I found --preset medium produced many encodes which averaged at around 180, --ap192 is by far the preferable option.
are the options to control sfcsi or scale factor included in this version? I read something about them on lame dev but haven't been able to remember them exactly. What about the replaygain patches? Have they been applied or ... ? When are they planned to be included.
Thanks
Lossy
One thing I was a little uneasy about was that to me (again, using ABC/hr) --alt-preset 192 sounded much better than --preset medium... and bearing in mind that I found --preset medium produced many encodes which averaged at around 180, --ap192 is by far the preferable option.
I'm not totally suprised because --alt-preset 192 (er, are you using 3.90.2 or 3.94a11 for this?) is ABR and at this bitrate, ABR is generally very good all around.
Much better? I'm not so sure about that one but maybe your musical choices have something to do with that. If --preset medium is giving you 180kbps, then you've tried more "difficult" music. If you start encoding a lot of music (like hundreds and hundreds of files), you'll find medium averages around 165kbps. Then one could easily say 165kbps vs. 192kbps is not a fair comparison.
An ABR medium preset will be added in a12 so you should find this addition interesting. (I assume Gabriel will choose something in the 160-170kbps range).
Yeah, I deliberately chose music I thought would be quite hard to encode for the purpose of testing the new alpha. And yup, I'm using the Feb 17th Alpha 11.
In hindsight, saying that --ap 192 was much better may have been an exaggeration, but it was certainly "significantly" better, i.e. more or less transparent where the 181kbps --preset medium had some fairly prominent artefacts.
I will post a couple of flac samples tomorrow when I can use a friend's webspace to host them, that way you can see what I'm talking about. I take it there are no copyright issues etc. with posting a few differently encoded versions of a 10 second sample?
I agree that abr192 should be better than preset medium.
Medium is targetted to 165kbps, and I think that overall, it really fits into this target.
It seems to me that abr 170 would be more fair to compare with preset medium.
any idea when v3.94 will become beta and/or final?
this is a alpha version now lame 3.94 alpha 11 .
I have been testing the medium vs. medium1 presets in the latest alpha11 (28th Feb 03), and I can hear a difference between the two but in my tests, medium1 has more definition - more 'sparkly' high-frequencies if that makes any sense - but it doesn't seem to sound worse than medium in any other respect. This seems to fly in the face of everyone elses opinion, so I'm wondering if anyone could provide a couple of test encodes that show medium sounding noticeably 'better' than medium1.
The only difference I can hear is that there is more treble definition in medium1, whereas medium is more flat but tends to make 'busy' tracks sound muddy and undefined. I dunno, maybe its just me...
just tested 3.94 Alpha11. Although i can't ensure that its the same exact quality as 3.90.2, i couldn't tell the difference on my expensive sony headphones (using both aps presets). The lame.exe was a 100 or so kb bigger than 3.90.2's lame.exe however, it cut down considerably from 5.41mb to 5.1xish. And the speed was noticably faster. Since the Dos prompt was showing bitrate levels too fast to catch on, i compared both mp3s with EncSpot. I got these results:
3.94 a11.:. <1 - 32kbps, <1 - 96kbps, 1 - 112kbps, 5 - 128kbps, 17 - 160kbps, 22 - 192kbps, 32 - 224kbps, 19 - 256kbps, 3 - 320kbps, AVERAGE BITRATE -208 kbps
3.90.2.:. <1 - 32kbps, 6 - 128kbps, 18 - 160kbps, 21 - 192kbps, 21 - 224kbps, 22 - 256kbps, 12 - 320kbps, AVERAGE BITRATE -218 kbps
Very close bitrates with both compiles although the 224kbps, and 320kbps were somewhat different.
My final conclusion of 3.94 a11 is that the sound quality is the same/less quality than the 3.90.2 compile. The filesize is considerably cut down for similar quality results, and speed seems to be cleaned up to be a bit faster. It seems like LAME is getting out of the 3.93 chaos situation and is really analyzing the sucess and downfalls of previous compiles. They definitely are programming in the right direction and if this does become final anytime soon, I believe it won't improve the sound quality over 3.90.2 but, definitely will cut down processing times and mb size. Hope this was somewhat useful research for you guys. Thanks for the link to download it!!
*alpha13 is what i meant i suppose (at least thats what the rar i got off john33 says)
good god. getting smaller filesize at the same quality level = better quality at a reduced filesize
thats not necessarily true