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) mpesch3.de’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.
TECHNICAL BACKGROUND on JOINT STEREO vs BINARY STEREO
“Channel Modes” are different ways/strategies wherewith stereo information is encoded.
BINARY STEREO or simply “STEREO”–INFERIOR
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.
JOINT STEREO–SUPERIOR & DEFAULT
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]
. Would be a nice gesture, and would probably only end up helping them in the long run anyway.
