Thread: VBR yes or no?

Is VBR better or is a constant bitrate better? If a constant bitrate is better how do I can this in EAC using LAME?

ABR is better than CBR and VBR is better than ABR.

List of recommended Lame settings :
http://66.96.216.160/cgi-bin/YaBB.pl...num=1004134851

I agree w/Pio but not with the list.

Most/all of those recommended settings incoherently use Joint Stereo.

Why do I say "incoherently"?

Because Joint Stereo is a 'strategy' that values bit conservation over audio fidelity.
This makes sense at lower bitrates, where it's more important to make each bit count
for as much informtation as possible, but makes no sense at the higher bitrates [most
of] these settings produce. It's downright self-contradictory.

From the LAME usage file/manual:

<blockquote>
jstereo means the encoder can use (on a frame by frame bases) either
regular stereo (just encode left and right channels independently)
or mid/side stereo. In mid/side stereo, the mid (L+R) and side (L-R)
channels are encoded, and more bits are allocated to the mid channel
than the side channel. This will effectively increase the bandwidth
if the signal does not have too much stereo separation.

Mid/side stereo is basically a trick to increase bandwidth. At 128 kbps,
it is clearly worth while. At higher bitrates it is less useful.
</blockquote>

I don't know about you, but I've long spent significant resources on
maintaining/preserving the INdependence (maximum separation) between L+R
channels, and I'm sure as hell not about to stop now that it only costs a few bits
more!!!!!!!!!!!

The best way to insure that Joint Stereo never clouds/muddies/slices/dices the stereo
image of your MP3s is just not use it. Why even/ever risk smearing the soundstage
whatsoever just to save a percent or two in file size? That's more insane than using
320 Kbps CBR, IMHO!

I typically use:

-q0 -V0 --athlower 1 --lowpass 20 -b160 -p

per your last question, hth (it's what I'm still using)

Why the best presets don't use pure stereo is explained here :

http://www.hydrogenaudio.org/forums/...=&threadid=759

By the way, they don't use joint stereo either. Alt preset standard started from --NSsafejoint with --ns--msfix and modified the whole process in the code.

Thanks for that link. ...pity bad that forum doesn't permit unregistereds to post.

Some of the points made there are very weak. For instance, there's the matter of diminishing returns on any bandwidth gains from JS as bitrates rise. Since turning off the JS (in modes that permit it) results in slightly larger VBR files, it's obvious that some frames were done at higher bitrates, so this alleged "lack of bandwidth" from not using JS must be a hallucination, founded in brainwashing that is based upon old-fashioned CBR thinking.

Further, on some material the JS is so infrequently used (on such a tiny percentage of frames) that no significant improvement in sound quality could possibly arise from its exceedingly rare use, but CPU cycles were apparently wasted during the compression of each frame deciding that JS would virtually never be used. This experience/reasonaing alone should be enough to 'require' all future LAME presets to optionally be invoked without JS, rather than forcing it down CPUs' and users' throats.

But the post was nevertheless enough to incite me to give JS another listen.

I tried the -q0 -V0 --athlower 1 --lowpass 20
(and --lowpass 19.5 for more complete comparisons) as shown above in the attached screen shot and also substituted "--alt-preset standard" and "--alt-preset extreme" in Additional command line options.

I chose 2 different WAV files. The first is Jefferson Airplane White Rabbit from the Surrealistic Pillow CD (not some newer remastered release), which is plenty hissy. As recently as 3.89 I'd tried --r3mix with and without -ms on this WAV and found the hiss got real 'chunky' in Joint Stereo mode while the Stereo mode was decent in this regard. (some brainwashing...) And for something with less hiss recorded with more tracks (before mix-down), I chose Genesis' Jesus He Knows Me from We Can't Dance.

I grabbed copies of the compressor screens (text) for each compression prior to doing blind listening tests against the known original WAV source.

What I found was the LAME 3.91's JS is indeed significantly better than was 3.89 when it comes to not chunkying up hiss. But it's also clear how it accomplishes this: fewer than 1% of the frames are encoded in JS! IOW, the fewer JS frames, the better the JS works on hissy material. This is brainwashing lesson #2: JS can be like governemt; less can be preferable to more.

On the newer Genesis release, LAME 3.91 used JS much more liberally, with only the very slightest most subtle deterioration to the smoothness of the sound field.

So is it superior?

In theory, I'm eager to adopt these 'active' switches that can make on-the-fly decisions, as opposed to static switch settings. They should be demonstrably better. But, according to my ears/tests, they're kind of a wash.

First of all, the 'standard' preset was not very difficult to discern. It was just a little too brash, actually offering 'more' than the original in some cases. While it wasn't bad, it does not sound as close to the original as the q0V0 static switches in the screenshot (above).

'extreme', OTOH, was a match for the switches in the screenshot. On loud bold passages it sounded slightly better. Closer to the full 'punch' of the original. Yet, on soft, subtle passages, 'extreme' sounded slightly worse, lacking the last bit of detail. It appears to suffer from the same slight ATH mistuning as does q0V0 (w/o the ATH lowered).

Further, as you'll see below, 'extreme' always cost more bits and/or time (even without -q0) compared to the -q0 -V0... settings. So I find the -q0-V0 a nice accurate compromise between the time/size/sonic results of the two presets. And if a 'dumb' collection of switch settings can compete/compare (very well) with a 'smart' preset, then I think the 'smart' preset must still need more work...

It's clear there are very different strategies being employed, especially in the last two, where in Genesis 'extreme' there was much use of 224 and 256 but in Genesis q0V0 there was much more use of 192 and 320.

<font face=courier new>
<pre>
JA std:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
5750/5864 (99%)| 1:39/ 1:41| 1:39/ 1:41| 1.5218x| 0:02
128 [ 10] %
160 [ 616] %%%%%%%%%%***
192 [3244] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*********
224 [1516] %%%%%%%%%%%%%%%%%%%%%%%%%******
256 [ 210] %%%%*
320 [ 154] %%%*
bitrate=202


JA -q0 -V0 --lowpass 19.5 --athlower 1 -b160 -p

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=0) stereo MPEG-1 Layer III (ca. 5.7x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
5700/5864 (98%)| 1:56/ 1:59| 1:56/ 1:59| 1.2848x| 0:03
160 [ 427] %%%%%%%%%%%
192 [2710] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
224 [2144] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
256 [ 398] %%%%%%%%%%
320 [ 21] %
bitrate=206


JA -q0 -V0 --lowpass 20 --athlower 1 -b160 -p

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=0) stereo MPEG-1 Layer III (ca. 5.7x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
5700/5864 (98%)| 1:59/ 2:03| 1:59/ 2:02| 1.2486x| 0:03
160 [ 382] %%%%%%%%%%
192 [2666] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
224 [2204] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
256 [ 426] %%%%%%%%%%%
320 [ 22] %
bitrate=207


JA extreme:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
5350/5864 (92%)| 1:56/ 2:08| 1:56/ 2:07| 1.1997x| 0:11
128 [ 15] %
160 [ 165] %%%%**
192 [ 581] %%%%%%%%%%%%%%%%%%***
224 [1052] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
256 [1672] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
320 [1865] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
bitrate=257


genesis std:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9650/9820 (99%)| 3:38/ 3:42| 3:38/ 3:42| 1.1576x| 0:04
128 [ 492] %**********
160 [3176] %%****************************************************************
192 [2351] %%%%%%%******************************************
224 [1703] %%%%%%%%****************************
256 [1216] %%%%%%********************
320 [ 712] %%%%***********
bitrate=199


genesis -q0 -V0 --lowpass 19.5 --athlower 1 -b160 -p:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=0) stereo MPEG-1 Layer III (ca. 5.7x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9650/9820 (99%)| 2:34/ 2:36| 2:34/ 2:37| 1.6403x| 0:03
160 [1797] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
192 [2576] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
224 [ 939] %%%%%%%%%%%%%%%%%%%
256 [1060] %%%%%%%%%%%%%%%%%%%%%%
320 [3278] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
bitrate=237


genesis -q0 -V0 --lowpass 20 --athlower 1 -b160 -p:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=0) stereo MPEG-1 Layer III (ca. 5.7x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9150/9820 (94%)| 2:21/ 2:31| 2:20/ 2:30| 1.7012x| 0:10
160 [1698] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
192 [2395] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
224 [ 818] %%%%%%%%%%%%%%%%
256 [ 831] %%%%%%%%%%%%%%%%%
320 [3408] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
bitrate=240


genesis extreme:

LAME version 3.91 MMX (http://www.mp3dev.org)
(Win32 binaries from: http://www.hot.ee/smpman/mp3)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding C:\IMAGES\CDDAS\EAC\tmp!)-(.wav to C:\IMAGES\CDDAS\EAC\tmp!)-(.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9500/9820 (97%)| 3:06/ 3:12| 3:06/ 3:12| 1.3344x| 0:06
128 [ 199] %****
160 [ 871] %%********************
192 [1231] %%%%%%*************************
224 [2356] %%%%%%%%%%%%%*********************************************
256 [2693] %%%%%%%%%%%%%%%%%%%%%%%%%*****************************************
320 [2150] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
bitrate=241
</pre>
</font>

Originally posted by Unregistered
Thanks for that link. ...pity bad that forum doesn't permit unregistereds to post.

Registering is easy and free : there is just to choose a name and a password, that's all. In this forum (EAC) we have no problems, so unregistered posts are not annoying. But in most forums, where flaming may occur from time to time, registration is needed to handle problems.
Besides, it provides a lot of advantages : instant messages, profile setup (picture, signature, time zone), and of course, we can recognize you when you post

Originally posted by Unregistered
Since turning off the JS (in modes that permit it) results in slightly larger VBR files, it's obvious that some frames were done at higher bitrates, so this alleged "lack of bandwidth" from not using JS must be a hallucination

The possible "lack of bandwidth" comes from the 320 kbps maximum bitrate. In stereo, the maximum is 160 kbps per channel. In M/S, in some cases (mono), the bitrate is allowed to rise to 320 kbps for one channel (center).

Originally posted by Unregistered
But the post was nevertheless enough to incite me to give JS another listen.

That's what I find most interesting in your post. The custom command lines were mostly developed using some short samples very difficult to encode, and tune to avoid everytime any "crash" of the encoder, even during the worst parts to encode. But on regular music, no one really hears the difference between original and MP3.

Your results would be interesting for the http://r3mix.net/forum forum too.
And a big lot of work, that I didn't follow, has been already done tuning Lame presets. I'd be curious to hear about what MP3 people, that know each Lame switch inside out would say about your command line.
There will be some that will say "don't waste your time... the alt presets are the best in the world... etc". But as you're backuping what you're saying, I'd nonetheless be interested in a blind listening test, as we sometimes do at r3mix forum.

Would you mind go and post this message there ? Or let me post a link to here ?

"-q0 -V0 --athlower 1 --lowpass 20 -b160 -p"
what do you think you get by using -q0 and -v0? Quality? - not likely.
slower encodingprocess and unneccesarily high bitrates, not put where they really are needed either, and also CRC checksums will make your files larger.

Why not simply use --alt-preset stadard or --r3mix or some tested commandline?

Originally posted by MTRH
Why not simply use --alt-preset stadard or --r3mix or some tested commandline?

He said they sound worse.

<blockquote>
In stereo, the maximum is 160 kbps per channel. In M/S, in some cases (mono), the bitrate is allowed to rise to 320 kbps for one channel (center).
</blockquote>

That's basically true (completely true if 2nd word was 2channel instead of stereo and if a frame fully contains monaural information). In reality, stereo allows the channels to share bandwidth (if one channel has more info than the other it gets more bits). And also in reality, I don't listen to rap 'music' and thus the bulk of the material is not being duplicated in the two channels, making that 320 Kbps theoretical ideal for JS less than fully applicable to my concerns. You've illustrated your point well with that, but A)it's a theoretical ideal that rarely, if ever, fully realized, and B)utilizing 320Kbps for a single channel strikes me as overkill (2 160 Kbps [give and/or take] channels sounds pretty good, no?). And until I'm thoroughly convinced that the JS can never alter the soundstage whatsoever, I'm reluctant to give up any soundstage precision for an instant of 320 Kbps mono. The (precision of the) shape of the sound field is as important to me as how the sound field sounds, if you know what I mean.

And let's not forget the time spent by the CPU determining what information is sufficiently equal (monaural) to determine whether to use JS or not on each frame. I'm not saying that's necessarily bad, but as you saw in the JA (hissy) example, the extreme preset used M/S so infrequently that it may as well have not bothered testing each frame for the possibility. The standard preset used M/S much more frequently, though. hmmmm.... (doesn't that continue to suggest that, to attain maximum quality [at least on some material], JS is to be avoided? hm?)

(as far as I'm concerned, linking between forums is kosher unless the forum owner[s] say otherwise -- or paste a copy wherever you like, this is a public discussion not [well, more than] a private publication... If these thoughts of mine get flamed or shot down somewhere else without me knowing about it [first-hand], I can live with that...)

<hr>

<blockquote>
what do you think you get by using -q0 and -v0? Quality? - not likely.
</blockquote>

I'm no LAME expert (compared to some, anyway), but I've been around computers long enough to make semi-educated guesses much of the time. Based upon reading LAME docs/forums, plenty of trial and error, a decent set of ears/equipment, and past experiences, my belief is that -q0 causes LAME to perform maximum recursions (carrying out division to more decimal places) for greatest precision. More than necessary? Perhaps. But better too much than too little, I say. (I like to maintain maximum [even excessive] resolution/information at each step along signal processing chains...) As for -V0, that should be fairly clear to anyone who's read LAME docs. It tells LAME to make highest quality VBR, with higher bitrate frames (as needed) and more sensitive ATH model (though not quite sensitive enough in 3.9x, IMHO -- it sounds to me like a Dolby NR that's mistracking [rec vs playback calibrations off] slightly).

I've definitely heard improvements (in 3.88; I haven't re-run every informal test I'd ever done since 3.9x came out...) in bass detail (tympani) with -q1 over -q2. And there was not a significant speed decrease using -q0 wrt -q1, but there may have been the last iota of sonic improvement. So why not? If you want to (try to) hear this for yourself, I recommend Joe Walsh - Ordinary Average Guy

If I need faster compressions, I'll buy faster hardware, but I'll not turn down the quality for compression speed gain (within reason). Compression time is fleeting; quality compressions endure...

<blockquote>
slower encodingprocess and unneccesarily high bitrates
</blockquote>

That sounds logical in theory, but the text-screenshots (reality/experience) indicate otherwise. (Nothing beats a trial like a failure..)

<blockquote>
also CRC checksums will make your files larger.
</blockquote>

Right. There is no impact whatsoever on sound quality (contrary to what's implied in CBR-oriented LAME docs). The two extra bytes (16 bits) are added to the musical content of each frame, making each very slightly larger. Same as with the parity bit in RS232 serial data, or the extra 100M per CD that data discs use as opposed to audio CDs. I like checksums. I like for computers to check/verify what they're doing as they're doing it. (That's why I like/use EAC...) It's an extra level of protection against data corruption.

I think the checksum bits may cause problems for some of the MP3 tweaker pgms that can change volume w/o recompressing. OTOH, I've never really considered MP3 much of an editable format; I use it for finished products, so I'm not sure how much I care about that...

ID3 tags make my files larger, too, by adding good but non-sonic information.

OMG..
Well.. I can't say more that that you really need to do some more research, and don't come an claim that you've 'learned' what you write above from r3mix, HA or the LAME docs, because that's simply not true, it's not there...
I don't know where to begin, so I won't.
but DO go to HA & R3Mix and DO _READ_ the FAQs and ASK questions.
It might come to your disappointment that many of your hypothesises might be erroneus.
This is not critiscism or anythin, let me make that clear.
I'm not trying to be rude either!
but for your own sake, read throught this again...

/David

what i better: constant or variable bitrate?


would the sound quality of these be the same? if a varibit maxes out at 224, wouldn't a constant 224 be the same quality but bigger in size?

i've heard of some hardware mp3 players (like DVD machines or mp3 discmans) that aren't able to play varibit but i connect confirm this.

MTRH/David:

Did you try listening to those settings and compare them to the presets? Or just decide that since you've read and already know so much that there was nothing here for you to possibly learn from? You said those proffered settings would result in higher bitrates and slower encoding when the previous post's screen shots clearly indicate[d] otherwise.

I keep trying (and rejecting) the "some tested commandline"s. When I find one that's truly superior to "<b>-q0 -V0 --athlower 1 --lowpass 20 -b160 -p</b>" I'll use it. The current presets only offer trade-offs; better in some respects and worse in others.

The screen shots also clearly indicate that, at least on some material, for higher quality, JointStereo is to be avoided. Not only does LAME, by default at higher -V settings automatically disable JointStereo, but the -extreme preset uses far less (almost no JS on the JA track) than does the standard. If JS poses zero sound degradation issues and is all to the good, then how/why do you explain these LAME (default) behaviors?

Again, from the LAME usage file/manual, regarding <font color=red>Joint Stereo:

"[it] is basically a trick to increase bandwidth. At 128 kbps,
it is clearly worth while. At higher bitrates it is less useful."</font>

You received a good-faith reply (and withdrew).

<blockquote>
"many of your hypothesises might be erroneus"
</blockquote>

indeed? (Many of my toes might be missing. But they're not)

<blockquote>
you really need to do some more research, and don't come an claim that you've 'learned' what you
write above from r3mix, HA or the LAME docs, because that's simply not true, it's not there...
</blockquote>

That's simply a slightly polite way of calling me a liar. (Or, if not, support your contention!) Maybe it's been so long since you're read some of these things you've forgotten them. Or maybe you never read them completely, or interpreted what you read differently, or... ...doesn't mean what I say is in LAME docs is not there.

Further, no amount of research/reading is going to cause my ears to stop hearing the artifacts that too many self-proclaimed "experts" tell me I can't perceive (including the too-high ATH default value/setting in 3.9x). Just because something has been written and agreed upon by a large number of "experts" does not necessarily make it true. (When did the Sun stop revolving around the Earth?)

Last, if you're opposed to making files slightly larger by adding error-checking data (-p option), feel free to simply omit that option. The few extra bits will have no effect on sonic quality but will merely make the compressed file slightly larger. (If the file containing the additional checksum info was of the identical filesize, <u>then</u> I'd agree that a slight amount of bandwidth must've been occupied/stolen by the checksum data...)

If we can all agree that MP3 is a lossy compression scheme, we should also be able to agree that some losses will be more apparent to some ears than others. According to my trials, the new extreme preset still embodies compromises in sound quality, file size, and compression time WRT the proffered (non-JS) VBR switch settings. Therefore, since I believe a dynamic preset should offer significant advantages over static switch settings, I continue to conclude that the 3.91 presets need more work (which will preferably permit a user to optionally disable the JS portion of the strategies in future releases, if for no other reason than it is good to be able to make choices -- and direct comparisons).

Ok, I just tried two direct comparisons which reveal different types of artifacting:

--alt-preset standard, vs
-q0 -V0 --athlower 1 --lowpass 20 -b160 -p

using castanets.wav

aps (alt-preset standard) yielded 207 kbit/s
the other setting, which I will call "unr" for Unregistered, yielded 220 kbit/s

aps was clearly better in pre-echo. In a direct comparison of aps vs unr, I scored 16/16 in an ABX (blind) test.


In a second test, using 2nd_vent_clip.wav, the bitrates were:

aps: 171 kbit/s
unr: 195 kbit/s

Again, another winner for aps, on a different type of artifacting: dropouts. unr has an added gurgly sound in it, noticeable within the first second, and which is not present in the original.

I'd be interested in obtaining samples which clearly show aps to be inferior to unr. I have anonymous FTP upload capability, if required.

ff123