Cyker, you sound like you have a good ear, or at least pay attention to your sound, instead of just paying lip service to it. You are one of the people who noticed the problem with Plextools and LAME, even if you did not know why it was happening. WHY Plextools should give better sound quality on the Windows encoder at lower and medium bitrates than LAME is very frustrating and puzzling!
In my humble and respectful opinion, this was (primarily, anyway) because of the lack-of-joint stereo debacle.
Even the LAME developers themselves say that -q 1 or 0 'sound improvement may not be noticeable'--in fact, it's right in the command-line literature, as I'm sure you've seen, but am saying for the benefit of those who haven't. While there might be an improvement using those techniques, you use of "waay better" would not seem to match up. Contribute, perhaps. Cause? Not in my opinion.
Especially considering you noticed this phenomenon at 128kbps (and presumably below, as 128kbps is generally seen as the beginning of "low" bitrates, if you had to divide them into "low" and "high"), I note that the audible absense of Joint Stereo is most-audible at medium and low bitrates such as those.
I always presumed that Plextools had lame_enc.dll encoding at -q 2, but upon reading your post, I realize that I have and never had any reason to presume this, aside from the fact that -q 2 is the "standard" or default--but since when has Plextools followed LAME defaults? (I mean, er, until recently:
Considering that Plextools encodes on the fly with no option to do otherwise (suggested by me as an option in the above thread), they may very well have it at some unwholesome setting you & I & everyone else who cares wouldn't approve of, in order to keep the ripping speed up?
That is one of the many negative things about LAME with Plextools: you don't know what you're getting.
(Turns on all the quality enhancing magic, but slows down encoding significantly).
Well, actually that (to my knowledge, anyway), doesn't turn on ALL the encoding magic, does it? Here's another thing to consider: you & I can't use LAME's reportedly highly effective tweaks, such as --alt-preset or the less-popular --preset (I don't think using -q 1 or 0 enables either of these). We just don't have access to them with Plextools. I know the LAME developers have spent significant resources developing & doing sophisticated multi-user blind listening tests on these for our benefit, which we don't get to use with Plextools. Which is why I say Plextools LAME encoding is neutered.
I really think that, until recently, Plextor didn't realize how bad of an encoding program they really had. This is changing with this group.
You think it'd be worth e-mailing Plex with a request for a 'manual settings' field, like in EAC, where I could disable their ones and supply the options I want manually?
We have been campaigning for a switch field Ã la EAC, but perhaps Plextor will have to enable a full lame.exe to do that (which would really be good). They should just shamelessly copy EAC, at least there. If you read the above thread fully (I know, it is long), I said that I learned (from drpino's correspondance with Plextor Europe, btw) that Plextor has said that command-line switchability has been "on the to-do list for awhile". "Awhile" in this case would mean years. Considering Plextools dev seems to finally have turned their attention to getting this silly little insignificant "DAE thing" (which happened to largely create their fortune and even moreso fame), I am hoping that we will finally see this... SOON. I don't think there's anyone on this board who says that Plextools is a serious tool for LAME. When that happens, it will be, finally.
I wouldn't have even made the post above which started so much of this, had the command-line option been available to override the [now-former] glitch in Plextools. And you can bet that if I had access to command line switches in Plextools, I would redundantly switch as much as possible to make sure I would know what I was getting. That is why I say that when (if) command line switching is finally released, they must override any radio button/drop-down menu settings. But even EAC, switches won't completely override everything (i.e. bitrate); the drop-down still sometimes takes precedence :Z .
I very reluctantly completely abandoned using Plextools when I discovered the whole lack of Joint Stereo thing (which is now fixed, again see link above). Thing is, I haven't started using Plextools again, because I, like you, just don't feel that I can trust it, because I don't have enough control to know that the job is being done right, and I don't have the time to pain over listening tests to see if there's any difference with this setting or that setting from EAC, as differences may not be noticeable in the singular, but observable in the cumulative. Besides, I've been spending all my free time doing free QC for Plextools. I have also grown accustomed to being able to put command-line switches like --alt-preset and -c (copyright bit) in my MP3's via EAC, and change them up when desired as easily a writing in notepad. Hell, turning off and on bold, underline and italics on this CDFreaks thing is harder!
I stay on Plextor's hide as a labor of love, and the hope that someday I can return to it as a personal equal or better to EAC. I want Plextor and Plextools to be as good as it can be, because I believe in the potential of the software and hardware. I do feel let down, though, discovering the long-outdated Vorbis library after I had done my entire CD collection in Ogg, and discovering that all my MP3's done in Plextools at not-so-high bitrates were done in S, not JS. Fooled once, shame on them. Fooled twice, shame on me.
What needs to be done is a campaign to bring this switch thing to the forefront. Plextor does listen to us. I guarantee... The more noise that's made, the sooner it'll be.