MAJOR Bug Found In Plextools DAE (Pro & XL)

I found a major bug in Plextools–in both Pro & XL versions–which deals with an erroneous way Plextools interfaces with the lame_enc.dll while encoding MP3’s. Plextools (until now) was thought to be the highest-quality way to encode MP3’s of any encoder, using Plextools as a front-end. But due to this bug it cannot seriously be considered an interface for LAME until it is fixed.

Plextools (either version: XL or Pro) somehow modifies the default channel mode for LAME, which is Joint Stereo, into forcing all MP3’s–no matter how low the bitrate–to be old-style or dedicated-channel “Stereo” channel mode, a much less efficient–and at lower bitrates, a simply ridiculous–way of encoding. Check it out yourself with an in-depth ID3 tag viewer such as found in DbPowerAmp’s Music Converter or (less intrusively)’s 1by1 Directory Player (sweet player). Look for “Channel Mode”. You will notice that any MP3 you made using LAME & Plextools, regardless of VBR, CBR, or ABR, Channel Mode will be “Stereo” (bad) and not “Joint Stereo” (good/supposed to be default). This goes heavily against the default settings of LAME itself. I don’t know how Plextools does it, but I’m sure there’s no good reason for “why”–this bug has got to be accidental, not intentional, because it’s irrational and counterproductive. If it were intentional, it was because somebody writing Plextor software didn’t know the difference between Joint Stereo and old binary or dedicated-channel “Stereo”. (See the bottom of this post for an explanation of the difference between Joint Stereo and Binary or Forced “Stereo”). You can even rip an MP3 at 32Kbps in Plextools using LAME and it will still come out in (binary) Stereo channel mode, not Joint Stereo! That’s truly crazy–a mistake, in other words.

LAME’s developers have the channel mode set to Joint Stereo (also known as J-Stereo, or JS) for a reason–good reasons, at that! It’s safe to say the LAME dev team knows what they’re doing with MP3 encoding. That’s why everybody wants to use their encoder, and why theirs is currently the only MP3 encoder still being developed. LAME is the best MP3 encoder in the world, but only when your front-end doesn’t muss up important defaults or settings it depends on for good quality.

L.A.M.E. always defaults (or is supposed to always default) to Joint Stereo at any and all bitrates. This is because no matter what bitrate you’re encoding at, [B]Joint Stereo is wildly more efficient than old-style stereo[/B], or what I call “binary” or “forced” stereo. The only way you can even force old-style stereo upon LAME is to manually use switches through a command line interface, which you can’t even do with Plextools, because it doesn’t even give you the option to use your own command line switches (unlike EAC and others). Plextools should offer command line switching, but it doesn’t; the Plextor community has grumbled about this for years, but that’s not the point of this post.

Plextor users, who were basically content to rip/encode using LAME’s very good defaults, now discover that for years, their LAME MP3 files through Plextools were not being encoded properly, being encoded at a much lower efficiency, all being forced into binary Stereo channel mode with no reason, no notice, and no explanation. Indeed, it’s safe to say that Plextor itself was/is unaware of this.

What’s worse, this happens with Plextools XL too, which is pay software (although I think of Plextools Pro as pay software too, because you have to pay [buy and install a Plextor drive] to get it, and Plextor users pay a lot extra for their drives, in large part for Plextools Pro, which is in no small part due to its DAE capabilities). Certainly neither are “free” softwares, so they ought to work properly, even if they are limited in options.

It will probably take only minimal effort on the part of Plextor to fix this problem, but I do not want that possibility to in any way at all minimize the the problem. Plextor’s Plextools DAE (Digital Audio Extraction) reputation basically hangs in the balance, as far as its usefulness with LAME goes. I know it sounds pretty technical, but this is pretty darn major and fundamental. Plextor has long been considered king of the hill when it comes to DAE, but this confusing goof makes it impossible for Plextools LAME encoding to be taken seriously… Plextools’ most popular encoding option. At this point, users would conceivably get better results using the dreaded Windows MP3 Encoder (which also always defaults to Joint Stereo, even when used through Plextools) at the same bitrate, especially lower ones at least. I don’t know too much about the Windows MP3 encoder so I can’t comment authoritatively, but I do know that using the Windows MP3 Encoder through Plextools will correctly default to Joint Stereo (unlike LAME through Plextools).

This is egg on the face of Plextor which comes on the heels of another major problem I lately discovered with Plextools DAE (both Pro & XL), which was that Plextor had “updated” its Vorbis Library (which encodes the Ogg, Monkey’s, and FLAC options you see in Plextools) with an already year-old encoder, 2 months after a new library had been released. To Plextool’s great credit, Plextor responded to my posting by releasing an update to Plextools within 2 weeks of my post. I would have liked to have received a reply email from them–not even a thank you note, but just a message that I was right and they would work on it, or to check the updates, but they did not. However, they did fix it, and that was the most important thing, and I again thank them for that.

Considering the prompt responsiveness with which Plextor fixed the “outdated Vorbis Library” mistake, I expect that Plextor will quickly release a new update to Plextools which has the lame_enc.dll properly encoding in its default Joint Stereo Channel Mode position. Again, it seems like this will be a very easy fix, but I am not a software writer. Regardless the case, it will be an extremely important fix. Until then, I would not say that Plextor’s LAME option is useful or legitimate until the Channel Mode situation is corrected. Regardless of my opinion, Plextools is certainly forcing LAME off of a very important default setting for all MP3’s it creates. This is made especially critical considering that we Plextools users cannot otherwise control the settings or re-initiate Joint Stereo ourselves. Had I found a work-around, i.e. been able to plug in my own command line, I would’ve plugged along my merry way. I still would’ve told the group, but not with this much formality, as now we need Plextor to fix it just to be able to make proper use of it.

I have run tests for the past several days before making this post to verify that I had everything in order to make this post. This bug happens in the latest version of Plextools, v2.23, as well as in older versions, such as v2.17 and earlier, and, as I said, Plextools XL. For Plextools XL or Plextools Pro to be considered to be a serious DAE rip-to-MP3 program, this problem must be quickly solved.

How serious is it?
Joint Stereo being erroneously forced off by Plextools on every LAME-created MP3 is a serious enough deal that if you are considering encoding a significant number of CD’s, or important CD’s, I would have no reservations recommending that the person hold off encoding until the problem is fixed, if the music is of significance. If you’re serious enough to be using Plextools and LAME, you would probably rather wait for the fix than use the Windows encoder through Plextools. But at least the Windows Encoder will default correctly to Joint Stereo in Plextools. You could “just use EAC” (Exact Audio Copy), a recommendation which gets tossed around when anything goes wrong with any other encoding software, but unfortunately, in my experience, EAC in Secure Mode (i.e. with error correction on) takes twice or more total time to rip & encode than Plextools, and that’s if EAC doesn’t run into any errors at all. If EAC finds errors–uh, you’re gonna be there for awhile. Maybe go out and do all your shopping, and that’s after turning off the drive cache in EAC to speed things up! I respect the hell out of EAC and it is my second choice of encoding program. But it doesn’t have the speed or efficiency of Plextools, despite Plextor’s help in guaranteeing EAC’s compatibility with Plextor products (see bottom of EAC’s download page). Plus EAC has a fairly steep learning curve for newbies, which is the other thing it is famous for.

EAC and Plextools are the only rip/encode programs I’ve ever tried with error correction which actually “did anything” (i.e. worked) for me. Easy CD-DA Audio Extractor claims to have error correction, but in my repeated experiments, using such “correction and repair” yielded absolutely no audible improvement to damaged audio files, as if the feature weren’t there (yes, I turned the feature on). Ditto on CDex. Plextools, however, yields amazing DAE error correction and data retrieval. By the way, I have experimented with all levels of Plextools “DAE Error Recovery”, and have found option #2, “Reduce the Speed Upon Error”, to work the best for the least amount of time, yielding the same audible results (in my tests) in roughly a quarter of the time as the other options, which is significant, because otherwise a heavily damaged file can take about 5 minutes or more to retrieve well. Plextools is simply the most amazing ripper/encoder I have tried from a standpoint of error checking & digital audio data recovery. A free quality ripper called Audiograbber (which offers a lot more encoding control), which can use lame_enc.dll OR LAME.exe, will rip much faster than Plextools (2-3 times), but there is no error checking or data recovery whatsoever. So you will inevitably at some point end up with pops, clicks, or other distortions on various tracks of your cherished music–not good for the serious encoder. I have found that while many pressed CD’s don’t contain errors, there is no way to know it’s error-free from physically looking at the CD, so that’s why Plextools as a ripper/encoder is so important to have working properly with LAME.

I would like to say, considering the above and other unmentioned things, that despite the lack of options & command line usability, Plextools is, after a lot of experience, the fastest and most-efficient exact DAE ripping/encoding solution I’ve ever seen, but unfortunately Plextools is not yet a serious program as far as LAME is concerned, especially at medium and lower bitrates, due to this “Joint Stereo being forced off” problem. Plextor, while I have your attention, may I ask that you please add command line switchability similar to EAC, but please fix this Joint Stereo problem first.

I can almost guarantee, judging by Plextor’s responsiveness over the outdated Ogg/Vorbis Libraries issue, that this current problem will be fixed–the question is moreso [U]“how soon?”[/U]. Hopefully, this solution will be heavily expidited, because this problem is probably 10x or more important than the “Obsolete Vorbis Libraries” one. LAME MP3 encoding is still probably the most popular encoding option–MP3 or otherwise. And Ogg is still relatively uncommon (though growing in popularity with a very dedicated following). In either case, it is not acceptable to release an inferior product, especially when dealing with free encoders.

The question is also is, “Who is doing Plextor’s software testing, and how are these things getting past them?”. The 2 major problems I have found should have never gotten past Plextor Quality Control. Verifying that Plextools is interfacing properly with these 3rd-party encoders is important, since Plextools relies entirely on 3rd-party encoders/codecs for its encoding capabilities–which is a good thing, but this still requires Quality Control & Testing. I hope that this will be the last major problem I find. But I hope that Plextor speaks with whoever is in charge of QC over there, and finds out how these errors are passing through.

Lastly, if I can repeat anything for emphasis, it is that I ask that Plextor fix this problem soon as possible. For any user who cares enough to want to use LAME, in my opinion for anyone serious enough to actually use LAME, it’s worth waiting for the interface fix to encode your CD collection or any special CD of yours. You could use EAC, which keeps its mitts off LAME, but again, my trials show that EAC runs at least twice as slow as Plextools on my Plextor drive in Secure Mode before it even runs into any errors.


“Channel Modes” are different ways/strategies wherewith stereo information is encoded.

The oldest or original is just called “Stereo”, I presume because it was first and the oldest and got the name first. I call it “binary stereo”, “forced stereo”, or “old-style stereo” because it is more descriptive. MP3-dev still just calls it “stereo”, which has unfortunately misled a lot of people (who use programs where you can actually control this type of thing, unlike Plextools) into changing the output from the default “Joint Stereo” to “Stereo”, because they of course want “stereo” output, not realizing the huge superiority of Joint Stereo, or thinking that unless they choose simple “Stereo” as their Channel Mode, that their files will somehow not be in stereo, which is false. Even I first started out years ago changing Channel Mode to “Stereo” because I didn’t understand. This could even have been what happened or went through the mind of the person who wrote the relevant the code for Plextools, but I don’t know. I can’t tell if Plextools intentionally or accidentally forces LAME into inferior binary stereo, but I do know that it is wrong.

In MP3 encoding, “Stereo” or “Binary Stereo” as I prefer to call it because it is more descriptive of two dedicated channels, is an older, less-efficient strategy of encoding stereo files. It is kept in LAME because it does have some uses (usually for interviews or mic’d stereo tracks with great amounts of separation). Forced Stereo, binary stereo, old-school stereo–whatever you want to call it, mimicks the “2 dedicated tracks” concept of old cassette tapes and CD tracks. On CD’s and cassettes, there are 2 dedicated tracks: a Left and a Right. In binary stereo, the MP3 file is split into two independent data streams (left and right), each running at half the total bitrate. Identical information between tracks is needlessly duplicated on the left and right channels. So with old style Stereo, the MP3 encoder has to make 2 identical copies of that identical information (1 for each track), creating needless and extremely inefficient redundancy. The only solution, if you are forced to use old-style Stereo as your channel mode (i.e. if you happen to be a user of Plextools v2.23 or earlier and insist on using LAME and not the Windows MP3 encoder), is to record at high bitrates, to try to ensure that each track gets the bandwidth it deserves. But a binary Stereo track is only roughly half as efficient as a Joint Stereo track for most modern music (i.e. for 99% of the people 99% of the time). That means you theoretically need to almost double the bitrate to get the same quality, if you are not using Joint Stereo.

Almost all popular is recorded mostly in mono, with some stereo effects and sounds, making the left and right channels almost identical from a data and sound standpoint. What MP3 does by default (not just LAME, but AFAIK all MP3 encoders, including the Windows MP3 encoder) is to use almost the full bandwidth of the MP3 data to encode this identical information, instead of creating 2 identical streams at half the bandwidth each (or half the quality per needlessly-duplicated track data). So you get the stereo information being encoded at the same rate, only the mono data (most of the information) is actually encoded at almost double the resolution, with the same resultant file size, with no detriment to the stereo information. This is extremely important.

For the “stereo difference” within the file, the MP3 encoder creates an as-needed stream, and codifies all that stereo data, which, at playback, is recompiled and re-separated into stereo data, yielding a perfect stereo file, at almost double the resolution of a “binary” stereo file. The joint stereo file is still full stereo. It doesn’t affect the sound, except to make it more accurate. It’s just a much better way of doing things, and that is why it is default in LAME at all bitrates, no matter how high or low. If you have a pop tune which you’re encoding at the highest available bitrate of 320Kbps in (binary) “Stereo”, it will still be technically inferior to the same bitrate in Joint Stereo. At the highest speeds, you would probably not hear the difference. However, when you get down to slower speeds, especially speeds around the very common 128Kbps, or lower-bitrate files commonly used for streaming, the likelihood that you will actually hear the difference is somewhere between “pretty good” to “inevitable”. Unlike many things in MP3 and music encoding, this “Joint Stereo” vs “Stereo” thing is not just academic. It enters into “real world” concern, especially with complex passages, low bitrates, and CBR (continuous bitrate) encoding.

To make it more graphic, a 128kbps file encoded with old-style Stereo will have 2 dedicated channels: a Left and a Right, each channel (Left & Right) being encoded at 64kbps. Since most of the data on those 2 tracks is identical, this is a big waste of a data stream. Joint Stereo, however, makes a note to the decoder that “this is mono data–duplicate it as Left as well as Right upon playback”, and then uses most bandwidth to encode that stream of identical data, and the rest of the bandwidth to encode the stereo-only data, or “stereo difference”. The higher the need for stereo priority, the more data is allocated for it. Things more than balance out. What you end up is a file with the mono sound being encoded at a much higher resolution, with no harm or reduced resolution to the stereo information. In either case of forced stereo or joint stereo, you end up with stereo output, only the Joint Stereo file will sound better, or at least as good, and will be technically superior.

And with slow bitrates, commonly used for streaming, binary Stereo is just incredibly stupid (with some obscure exceptions). Even the few remaining anti-joint-stereo people would admit to this. Unfortunately, this is what Plextools is forcing lame_enc.dll to do in each & every file. This is a big deal for Plextor users, many of whom are production professionals. This bug also prevents the ability to create excellent-quality streaming MP3 files using LAME, in which case of files intended for streaming you usually have to stick with CBR and therefore have even less of a fallback. A streaming music file in “binary” Stereo is a disgusting idea, and not using Joint Stereo [U]will[/U] impact upon the sound in such a situation. Plextools inexplicably forces LAME to use binary Stereo even at its lowest bitrates.. At such low bitrates, it would be better just to encode in mono rather than old-style Stereo, but guess what: Plextools won’t even let you do that. Amazingly, Plextools does not include any mono encoding options whatsoever–for any format–be it the Windows MP3 Encoder, LAME, or OGG–all of which have native mono encoding capability. That is not a big deal, as most people do not need mono encoding capability. But stealing away our right and expectation to Joint Stereo altogether is in fact a big–no, huge deal.

There are still a few people out there on the internet you will find who say that Joint Stereo is actually inferior to old-school Stereo. These people generally don’t know what they’re saying, or are misguided in their thought process. Most of that noise and obfuscation was written a number of years ago, when things were less-well-understood. It is definitely with good reason that LAME defaults to Joint Stereo on all bitrates, no matter how high or how low. This is supported by A/B/X listening tests done in the MP3 development community. For 99% of users 99% of the time, Joint Stereo will be superior to old-style Stereo.

The only time binary Stereo would be a better alternative than Joint Stereo is when you have 2 tracks with completely or at least mostly different content (such as an interview with the guest on the Left channel, and the host is on the Right channel)–very rare circumstances indeed. If you are doing candid/ambient sound recording with wide stereo separation, that would be another instance, but these are rare instances, and those who need it will usually know they need it. [U]For Plextools to force LAME to use an inferior and non-standard, non-default Channel Mode (for 99% of the people 99% of the time) without telling customers, or even giving them a workaround to be able to use Joint Stereo–the standard and default, it will be a critically bad move for Plextor’s reputation regarding Plextools’ DAE if this LAME channel mode error is not corrected.[/U]

That honour belongs to EAC … not Plextools

Just use the modified *.dll at … it is configured via a *.ini file that allows to encode with the --alt-presets … that way, you’ll get perfectly-sounding joint-stereo MP3 files.

I agree on the point that full stereo is indeed useless with lossy (and lossless) encoding since the process of M/S en- and decoding has proven to be lossless various times.

Ah, JeanLuc, tu es si intelligent. I always love your posts. You know what you’re talking about. And you’re right. I was going to mention it in the post, but there is a problem. I did find the rarewares modified lame_enc.dll. But it only works for VBR output. And you are restricted to presets. But you are right… it is currently the ONLY way to get obviously-needed Joint Stereo in any LAME encoding scheme using Plextools. I thought I had enough info in one post, but planned to bring it up later, and you beat me to it.

I did not want to mention this yet (I wanted to wait until I asked), but I am going to try to get the author of that modified DLL file to write the Plextor community (and everyone else) a new modified DLL, the INI file for which will serve as a “command line interface”, instead of a list of preset VBR schemes, so people can use CBR and perhaps even ABR, and have hopefully pretty full control over LAME–that would be a real breakthrough. I would love to be part of bringing that around, after the years of grumbling and groveling with still very little control over MP3 output. If we managed to get full control over LAME output, Plextools really would kick EAC’s butt, as far as LAME goes.

I haven’t had time to work on this yet, and I must figure out a nice way to ask. I don’t even know if it will be possible. The dll seems to behave differently from the exe. Perhaps someone else here may mention if it’s possible. I’ll probably have to go to another forum… HydrogenAudio.

I really do need CBR for some of my purposes. The VBR presets just aren’t enough for me. But you made a great suggestion.

Regrettably, it still doesn’t fix the problem that Plextor’s claim of us having use of LAME through Plextools is ~basically~ not true, since the output files are -m s (old Stereo), not -m j (Joint Stereo) as they obviously need to be. I’m convinced that Plextor is clueless about the existence of this problem, and that they will correct it when it is brought to the right person’s attention (which I’m in the process of now).

Maybe they’ll let me test Plextools XL with a full, non-demo license, eh? :stuck_out_tongue: . Would be a nice gesture, and would probably only end up helping them in the long run anyway.

I simply don’t know why anyone would use CBR encoding these days …

And before Plextools really kick EAC’s butt, there have to be some serious improvements in e.g. file naming schemes, tagging and CLI encoder abilities.

Wow, long text. While I certainly support the call for an updated Plextools that gives better control over the external and internal codecs I nevertheless have some criticism on the statements made.

What you are complaining here is not a “bug”. A bug is an error in program code that results in the programm running in a way that is not intended to do. What you have found is a setting that cannot be altered while it might be desireable for people to do so. Whether the current choice of this setting makes sense or not is certainly open to discussion.

Sorry, but that is just plain wrong! Please type “lame --help” and read for yourself!

Regular stereo mode is a valid encoding mode in LAME and it does both make sense and has its use. As you’ve correctly stated yourself (not quoted: the 32kbits example) there are combinations in encoding settings where regular stereo does not make sense. But then you also base your criticism on the fact that people use Plextools to encode their CD collection. Now I’d like to ask who in his right mind is going to encode his or her collection in 32kbits? It’s widely known and accepted that MP3 needs a minimum of 192kbits to sound ‘good’. A data rate where regular stereo mode is far less decisive than at lower rates.

That’s not a ‘fault’ of EAC neither. It’s the fundamental design of EAC that makes up for this. A design that is radically different from Plextools.

And if Plextools does, you’re not? Tell me again what happens when you have selected “Reduce the Speed Upon Error”.

[QUOTE=brjones]I would like to say, considering the above and other unmentioned things, that despite the lack of options & command line usability, Plextools is, after a lot of experience, the fastest and most-efficient exact DAE ripping/encoding solution I’ve ever seen, but unfortunately [U]Plextools is not yet a serious program as far as LAME is concerned, …[/ QUOTE]

This is something that i can agree too. Plextools shines when it comes to DAE extraction into a WAV file. DAE plus encoding however is currently only supported in a very rudimentary way. This is not only true for LAME but for all the other codecs included as well.

On the other hand proper encoding can be quite a challenge. There are many settings to know and also conceptual differences in the codecs to be respected. Plextools currently strikes a balance between simplicity and power. It will allow the beginner to encode his music easily while the knowledgable ‘pro’ is left wanting more.

In this regard the recommendation to use Plextools for ripping only and use something else for encoding still stands. (Unless you’re satisfied with what Plextools offers encoding-wise.)

That is correct …

No modern HQ codec that I am aware of (like Vorbis, Musepack and all lossless codecs) uses full stereo by default … it is simply a waste of bitrate, thus inefficient. There are codecs that have flawed joint stereo modes (without lossless reconstruction of the original signal’s stereo stage) implemented (like Xing and some FhG builds) but since LAME is today’s de-facto standard for MP3 encoding, other MP3 codecs can safely be disregarded in that context.

I have MP3 files that are indistinguishable from the original at 128 kbps (it all depends upon the source, after all) … that’s why I originally stated that CBR modes are useless these days (and that’s why the LAME --alt-presets were developed).

If you are encoding two different language version of something in the two channels you may want to have true stereo instead of joint stereo. But I think this is quite rarely the case.

M/S encoding will still work (keep the channel separation) in that case since the transition from M/S to pure stereo is floating according to the present channel correlation … if correlation is high, there will be much data in the midband (thus saving a lot of bitrate) and vice versa.

I prefer VBR (especially the presets) but i always have trouble cutting VBR+CUE files. They are either cut wrongly or the header gets messed up and then the players report wrong length. Any advice?


It IS a mistake. I shall let you wrestle with the definition of “bug” by yourself, while other people get to work on getting this mistake fixed.

What you have found is a setting that cannot be altered while it might be desireable for people to do so.

What I found was NOT intentional. And it would only be desireable for 1% of the people 1% of the time. No one at Plextor “intentionally” made all MP3’s be channel moded into old Stereo–that is, if they knew what the hell Joint Stereo was. It was either a mistake, or the person doing the coding had a juvenile understanding of channel modes.

[QUOTE]L.A.M.E. always defaults (or is supposed to always default) to Joint Stereo at any and all bitrates.

Sorry, but that is just plain wrong! Please type “lame --help” and read for yourself![/QUOTE]
Sorry, but you are wrong. Although I will concede that the LAME help file does say “default is (j) or (s) depending on bitrate”, this is no longer true. J-Stereo is in fact the default, regardless of bitrate. I just used command line LAME 3.96.1 to encode several test wav files. Try it yourself if you don’t believe me; I did what you suggested, do what I suggest! Encode an MP3 at the highest bitrate possible in LAME–320kbps–do it using CBR so it never dips lower than the max 320kbps. It is the highest bandwidth option available in LAME. The file will come out in Joint Stereo. You can get this same setting by typing lame a.wav 1.mp3 --alt-preset insane". Either way, it will default to j-stereo.

The developers of LAME have realized that old Stereo creates no sound improvement, at any bitrate, for typical files. Encode some VBR files, some ABR files. Go high, go low. Do it. Find a bitrate which defaults to -s. Get back to us when you do.

If you don’t want to use a command line, just use EAC as a LAME front-end, and use some of the drop-down bitrates (list has both CBR and VBR options), with no other settings or command line switches, to ensure that you’re getting the “default” setting, since this is what it is about. Let me know what you come up with.

And I also dare you to find ONE preset in LAME which uses old Stereo. Just one! --alt-preset standard, insane, extreme, or medium. Do it, try! Because I’ve tried them all. They all default to j-stereo.

Like I said in my original post, old-stereo LAME supporters are leftovers from a time when Joint Stereo was less-well-understood. Joint Stereo has of course also improved since that time, and now it is default at every bitrate and in every preset, for good reason. There is still a vocal minority out there who end up confusing a lot of people (I enter hwp’s post as my first exhibit). It’s confusing enough already without extra obfuscation. Posts similar to hwp’s held up my understanding of Stereo vs Joint Stereo years ago, but no more. The people who exaggerate old Stereo’s usefulness are smarty pants people who are generally wrong about a lot of things… music encoding included. Which leads me to my next point…

It’s widely known and accepted that MP3 needs a minimum of 192kbits to sound ‘good’. A data rate where regular stereo mode is far less decisive than at lower rates.

And you reveal yourself. “Widely known and accepted”, huh. To sound “good”. Okay. Maybe you need to encode your MP3’s at 192 to sound good. I can make 128 files sound “good”. You may have to A/B/X them to tell the difference, and listen for specific cues, but they will definitely sound very good–no obvious artifacting or difference, at least without a listening test. For that matter, depending on the source material, I can make 96 files sound “good”. They may not be perfect, but can certainly be at least “good”. But that’s what you get when you go use Joint Stereo. If you use old Stereo, your files are basically being recorded at almost half the bitrate per channel. So a 96 Joint Stereo MP3 will be qualitatively near to a 192 old Stereo MP3, (at least from a technical perspective–I’ve not tested this). But it would explain why you have to encode your files at 192 to get your MP3’s to sound “good”. At your old Stereo encoding of your 192 kbps, each channel is being encoded at 96Kbps. Most of the info in music tracks is mono, so my Joint Stereo files recorded at 96 kbps sound almost as good as your 192 kbps old Stereo files. Okay, I don’t really believe that even you are encoding all your music in old Stereo. I am saying this to make a point, but you do have an unreasonable affinity to, and perception of, old binary Stereo. You know enough to mislead someone else, but not enough to be right. Another case in point:

Now I’d like to ask who in his right mind is going to encode his or her collection in 32kbits?

Who in their right mind would ask such an inane question? Vocal old-style Stereo supporters have a pattern in their posts of displaying a certain unreasonable quality, which I suppose attracts them to old Stereo. Makes them feel smart. They jack up the bitrate and then turn on binary stereo, thinking they’re getting “full stereo separation” or something else, when in reality they just end up neutering that high-bandwidth file they just made. Not that they’d ever hear the difference anyway. It’s a psychological need which is fed. So in that sense old Stereo served its purpose. I really believe that that is true reason MP3-dev really keeps old Stereo in LAME… It serves a greater psychological use than it does a utilitarian one.

Regular stereo mode is a valid encoding mode in LAME and it does both make sense and has its use. As you’ve correctly stated yourself (not quoted: the 32kbits example) there are combinations in encoding settings where regular stereo does not make sense.

It’s not that there “are combinations where regular [old] stereo does not make sense”. It’s that it’s not a valid encoding mode for typical files, especially low-bitrate ones. And at high bitrates, it still reduces the technical quality of the file. At best, it doesn’t hurt anything. It’s only a valid mode for very unusual files, and in those cases, it will be used only as-needed and then any wise person would go back to using Joint Stereo. Unless Left and Right have wildly different information on them, it doesn’t make sense. And as JeanLuc pointed out, even then, Joint Stereo in LAME is very sophisticated and can probably handle it.

And for Plextools to spit out every file in old Stereo, that is just insane, which is why I say it was a mistake, not intentional, and will (fairly presumably) be fixed/changed now that this has been brought to the attention of Plextor engineers.

[QUOTE]…but unfortunately, in my experience, EAC in Secure Mode (i.e. with error correction on) takes twice or more total time to rip & encode than Plextools, and that’s if EAC doesn’t run into any errors at all.

That’s not a ‘fault’ of EAC neither. It’s the fundamental design of EAC that makes up for this. A design that is radically different from Plextools.[/QUOTE]
The fact that that it can take EAC 6-30 times longer than Plextools to recover a significantly damaged file with no superiority to Plextools isn’t relevant? EAC does not provide superior error checking and correction to Plextools in my experience. If it does, it’s theoretical and nothing I can hear. My heavily damaged test files both come out sounding fine with either EAC or Plextools (and no other software I can find), it’s just that EAC will take 20-30 minutes or more for such a file (and only this “fast” with the buffer disabled), and Plextools will take 1.5 to 5 minutes, depending on which strategy. If Plextools is fundamentally different, that’s fine by me–it does the same job to my ears. Perhaps you have a psychological need to feed, where spending longer on your error correction makes you feel smarter and lets you feel like you have a better file.

[QUOTE]I would like to say, considering the above and other unmentioned things, that despite the lack of options & command line usability, Plextools is, after a lot of experience, the fastest and most-efficient exact DAE ripping/encoding solution I’ve ever seen, but unfortunately Plextools is not yet a serious program as far as LAME is concerned, …

This is something that i can agree too. Plextools shines when it comes to DAE extraction into a WAV file. DAE plus encoding however is currently only supported in a very rudimentary way. This is not only true for LAME but for all the other codecs included as well.[/QUOTE]

We’ll have to partially disagree even here. Plextools’ DAE interface is very streamlined, and allows for easy and quick modification of File Names, ID3 tags, or your general Naming Convention. This is precious because time and energy are precious. We buy Plextor with Plextools to make our lives simpler and more powerful, not more complex or harder. The fact that it rips and encodes simultaneously saves time too. Although there are faster rippers out there for free, the access to modifying these aspects is superior in Plextools in my experience. Add to this error checking & correction which is just as powerful as EAC but many times the speed, and you get SPEED and efficiency and therefore Plextools seems indispensible for the serious encoder–right?. But it has an achilles heel. No encoder control. It has so much potential. Plextor could solve this all just by putting a command line field into the software, which would override any other GUI/radio button settings. Those who wanted that control would know or learn what to do, and newbies who don’t care would not be intimidated, simply ignoring that field, like they can with the Filename Construction field if they so choose. I seriously hope Plextor does that. They don’t need to make extra radio button options. Just give us a command line field. They do it for File Naming, and people figure it out. Why not for encoder control? And of course all LAME MP3’s need to otherwise default to Joint Stereo.

Plextools currently strikes a balance between simplicity and power. It will allow the beginner to encode his music easily while the knowledgable ‘pro’ is left wanting more.

After reading this thread about forced Stereo on every LAME MP3, even the beginner will be left wanting with Plextools. And I see your point about striking a balance between simplicity and power. But again I don’t agree. That simplicity IS power. I think by “power” you mean “control”, because Plextools DAE is very powerful from a Naming, and Error Correction, and Efficiency perspective. Very important when encoding your collection of CD’s. The only “power” Plextools is lacking is in control over the 3rd-party encoders, and almost exclusively LAME. And all that could be solved by simply putting in a command line field and letting us grow up and fend for ourselves and learn how to drive ‘stick shift’ as it were. Give us the keys, Plextor! Then we’d have nothing to complain about. People would find something (“it’s too hard to use the command line field”), but we’d show them what to type, and we’d say, [In Dana Carvey Grumpy Old Man voice:]

[I]"When I was your age, we didn't HAVE encoder control in Plextools! All OUR files were encoded in Ancient Stereo, and we couldn't even use presets. Copyright bits. Who needs that?! Plextor said we didn't 'need' bandpass, or 'choice' between silly things like... 'High Quality' and 'Low Quality'. 'High quality' and 'Low quality'. What kind of spoiled brats are ya? In our day, Plextools was neuteured, with backwards defaults, and it drove us nuts.  And we LIKED it!"[/I]

I cower in shame before your magnificence. :bow:

We all bow really low with that sheer sageness touching our eyes :bow: :bow:

new versions of Plextools Pro will include command line interface capabilities…straight from Plextor Europe tech contact…

So nice to see they are not limiting such important enhancements to the XL version only. :slight_smile:

Okay, it’s July 9, 2005 now.

Plextor has released Plextools Pro v2.24 and XL v3.03, which now have a section in the LAME settings for selecting Channel Mode… either Joint Stereo or Stereo.

Discussion has also ranged in this thread

and this thread regarding the new release:

First, I want to THANK Plextor and the manager in Europe for being responsive and addressing this problem in the soonest update of Plextools Pro as he said he would!

Unfortunately, it’s not all better yet.

  1. With the new Channel Mode choice setting, it still defaults to old-school Stereo, not Joint Stereo as it should. At least that is the default setting. This whole thing was about Plextools incorrectly defaulting to Stereo (with no other choice). So if you’re going to add the choice, why not have it default to the correct setting? Why should every single user have to manually correct this? This is still clearly a mistake. What I can’t figure out is how this got past QC after the whole point for this was originally that Plextools wasn’t defaulting to Joint Stereo. People shouldn’t need to have a broad range of knowledge about Channel Modes in order to set Plextools correctly. Joint Stereo is, and should be in Plextools, the default for LAME. Period.

  2. ABR in LAME is now totally screwed up. I tried it in 2 plextor drives with 2 CD’s and multiple tracks therein on a fresh new install of Windows, with 2 different lame_enc.dll’s in the home directory (both 3.96.1). Will someone please verify this for me. Output sounds like crap, even though the bitrate you choose comes out to the file size it seems it should be for that type of bitrate. Sounds like it is being encoded at an extremely low bitrate, even when it’s not (super-obvious, not a little). Does this in any ABR setting in my experience. But the settings I had, for an example, was ABR/CBR dropdown set to 128, minimum bitrate 96 [not applicable for ABR but strangely Plextor doesn’t gray out that choice–seems to me that the Plextor coder doesn’t understand MP3 terminology or definitions very well–so that is where I had it, but I monkeyed with it, too], and maximum bitrate, oh, say 256 or 320. Changing channel modes doesn’t seem to matter, nor any other bitrate setting you choose, low or high; those were just some of the settings I was using. CBR and VBR seem to be good in my tests.

I won’t even give this next one a number on the list, because I don’t want to compare it to the above problems, but “Mode” setting name should be changed to “Channel Mode”. There are millions of “modes” in the world; just one thing TTBOMK called Channel Mode.

Honestly I can’t see how the person at Plextools who does the QC keeps his job… perhaps they don’t have anyone doing QC, or the people who write the code check [or don’t] their own work. It took me 5 minutes cumulative of testing this new Channel Mode setting to find the problems above. 5 minutes!

#1 and [un-numbered] should be really easy to fix, but I have no idea what is going on with problem #2.

Hopefully this will be fixed in the “Next” update for Plextools. Baby steps? Perhaps it’s too much to ask for a command-line switch field to take advantage of what LAME really is, instead of messing around with drop-downs? We can’t even set a copyright bit or use one of the highly effective presets. Tough love: keep it moving, Plextor… MP3 won’t last forever–it’s already at the end of its lifespan; you’ve had how many years to get this straight? Many Plextor customers are drawn in due to the DAE capabilities, and justify the extra (sometimes double) expense specifically because of Plextools Pro. The software should work right, but Plextools is still not considered a serious tool for LAME encoding.

Thanks for the report brjones, I’m sure someone at Plextor will pick this up and fix it :wink:

I’m pleased to announce that Plextools development team has set a new record time for a fix release! THANK YOU! Introducing Plextools Pro v2.24a:


Version History

PlexTools Professional V2.24a released on 12 July 2005
* Changed:
*General: support PX-740UF and PX-716UFL
* DAE: The ‘Mode’ option in the LAME preferences has now ‘Joint Stereo’ as default value

[B]* Bug Fix: [/B]
* DAE: When choosing ABR in LAME, the encoded files have an extremely low bitrate.
* Q-Check Beta/Jitter Test: The jitter values for DVD media are not always correct.

Thanks to delios101 for the snappy notification of this update.

I verified that Joint Stereo is in fact now default. Good!

I also verified that ABR is now working properly. I did some test rips. Sounds good! :slight_smile:

What’s interesting is that Plextor also took my cue to gray out the Min and Max bitrates when ABR is selected (as those settings are irrelevant to Average Bitrate).

However, there is still a small bug.

Despite being grayed-out, if the “Minimum Bitrate” has been set below the ABR bitrate you choose, you cannot save/“OK” that setting. You will get an error, “[L.A.M.E. options] Warning: the minimum bitrate should be set lower than the average bitrate!”. This is a spurious error, and it is more than a “warning”; Plextools won’t let you exit out of the “L.A.M.E. Extra Options” screen without either Cancelling, OR: selecting Variable Bitrate, changing the Minimum Bitrate to something equal to or lower than your ABR choice. It will then let you save your setting. Once you do this, ABR will work.

This bug won’t affect many, but newbies will be confused, as Plextools is (spuriously) requiring change to a grayed-out/inaccessible field, and users may not know how to activate the Minimum Bitrate field in order to change it. Plextools dev still made the right decision in graying-out those irrelevant fields. They’ll just have to make that error go away.

I caught this bug in record time, under 30 seconds (first thing that happened to me with the new 2.24a). If Plextools development fixes this bugaboo as quickly as it did the last one, Plextools development will again have my admiration.

I am also glad to see Plextools Dev updating Plextools Pro first, as was proper in this case.

Keep Going, Plextools Dev!!! :clap:

brjones your obstination has made 2.24b appears
Plextor :bow:
I wish you support GNU/Linux with the same dedication

Plextools sets another record with a release! 24 hours!

PlexTools Professional V2.24b released on 13 July 2005
* Bug Fix: DAE: if ABR is selected in LAME preferences and the ‘Average Bitrate’ is set to a lower value than the ‘Minimum Bitrate’, a warning is given when the window is closed.

Yet, it is still not fixed.

The warning is now gone, but there are still problems with ABR.

· If the VBR Minimum Bitrate (despite being grayed-out) is higher than the ABR Bitrate, Plextools will encode at the higher VBR Minimum Bitrate with the sound quality of the [lower] ABR bitrate (worst of both worlds).

· If the VBR Minimum Bitrate is lower than the ABR Bitrate, Plextools will encode at the [higher] ABR bitrate, with the sound quality of the [lower] Minimum Bitrate (again, the worst of both worlds, just reversed).

· There is also a new error: “Cannot Initialize L.A.M.E.”.
Here is one way to reproduce it:

Go to LAME VBR settings:

  • max 224kbps
  • min 320kbps

switch to ABR settings (VBR Settings will gray-out)…
Constant/Average Bitrate setting:

  • 56kbps [32kbps up to 64kbps]

Try to rip [gives error].

80kbps and above here gives no error.

I have gotten produced this error with a “Minimum Bitrate” as low as 192kbps and an ABR/CBR Bitrate as high as 64kbps. I do not know how many other configurations it can be had in.

I also unfortunately had some instability… Plextools has crashed on me twice in just this hour or two of testing, and taking the session’s settings with it.

So when do I start earning a salary? ;)Honestly, though, if Plextools Dev keeps on releasing fixes this quickly, I can’t really complain. There seems to be a sea change in the attitude Plextools dev has. When I first reported this problem after v2.23, the Plextools manager literally told me that they’d fix it ‘in the next release of Plextools’, but that they ‘wouldn’t release a special version’ just for that (URGENT and major) fix. As it was, we all waited nearly two months for the next release, which, after all that waiting, (obviously) wasn’t even properly fixed anyway. Now they are very, very wisely releasing new versions specifically to work on a particular fix, when they have the fix, and tending to it immediately! Good going! That is the way it should be, and should’ve always been.

Although still embarrassing to their QC, this is still a remarkable improvement in both attitude and effort on the part of the Plextools Development Team (or its management?). Imagine having to wait a month (the average time between Plextools updates) for a totally new update to incrementally chase down these bugs! I originally was shocked that Plextools management would put the original problem in this thread on the same priority order as “minor bug fixes”… Imagine: for the manager to find out that Plextools has been erroneously encoding in old-style Stereo since the beginning of the Plextools LAME feature, only to put it on a “to do” list! It is wonderful to see that changed…

Some have speculated that the attitude change was a directive from upper management relative to the PR disaster relating to the PXLinux rigamarole. I don’t know. But what I do know, is that I now have reasonable hope that we will get command line switch capability relatively soon? Plextor, perhaps consider a lame.exe option for those who want to drive ‘stick shift’ if you’re having difficulty working in full/switch control with lame_enc.d-l-hell :wink: ;). …Perhaps also with an option to encue LAME encoding (which EAC has) in addition to the current rip-encode on-the-fly (which EAC doesn’t have, and has nevertheless always been a cool & neat feature of Plextools DAE).

I have this vision of what Plextools can be; I’ve always seen huge potential in it. I have tons of suggestions, so many in fact that I’ve cataloged them. But until recently, the attitude of Plextor towards Plextools seemed to be one of neglect… some really bad decisions [Plextools XL, PXLinux witch hunt], and immediately apparent embarrassments such as Plextools Pro still operating at a juvenile resolution of 640x480 without the ability to be maximized, all which served to embarrass Plextor and turn consumers away, so much so that once vociferously pro-Plextor seniors in this group publicly vowed to never purchase Plextor products again [PXLinux; don’t want to mix that in too much here]. I personally am one of the many who was a regular lurker on the Plextor forum before I purchased my first Plextor drive. At that time, this board, and what I learned from it, were actually primary motivating factors for me to purchase a Plextor drive.

But that knife can cut both ways (thank God for free speech), and perhaps Plextor, or at least Plextools dev, has finally realized this. I’ve said that a compliment is of no significance in an environment where a fault cannot as easily be articulated. Perhaps they got a super new person in there who’s doing things right just because that’s the type of individual they are. No way to know, as Plextor seems to have sent a memo to all of its branches, interdicting them from participation in this board. I can just hear the upper manager’s voice in my head explaining why they can’t or shouldn’t actively participate here (“then we’d have to respond to everybody!” “it would become a forum for tech support from us!”). Actions speak louder than words anyway, so since we know that Plextor reads and responds now, and regularly admits mistakes at least with Plextools bugs (to which we respond with quick forgiveness and salutation), maybe they will take a cue from that and realize that we are a forgiving crowd when we have reason (no better friend, no worse enemy to Plextor) and reverse course or take corrective action on some other infamous decisions, which could ultimately end up patching up & bailing out their hull which has sprung a few leaks and is now taking on water?

Plextor is free to talk to me (or any one of the board’s articulate, reasonable participants) in private for kind suggestions of ways they can improve their situation. I’ve always thought that a good measure of top-level management’s job performance was how big of a bonk on the head the company needed to take corrective action on something. In some recent cases (not directly relating to this thread), that bonk was pretty big.

Again, I encourage Plextor to flourish and take proper steps, and acknowledge their in-process change. Onward…

LOL, I sense we will see 2.24c very soon. :wink: Thanks for reporting brjones.