Note: I tried emailing this to Al, the developer of CDex, at the email listed on the website www.cdex.n3.net. It didn't go through, so I'm posting my (hopefully) constructive criticism here. It'll probably draw some more comments out from people, which will be useful. If anyone knows Al's personal address (al.faber@yahoo.com didn't go through; got returned to me), I'd appreciate if you'd alert him of this. Here is:
* * * * * * *
First off, let me say that I like CDex. It's a well-designed program, and it offers some options that EAC does not, such as internal vorbis support and tagging, and on-the-fly encoding. Here are some issues with the current release candidate; I hope that this is helpful. None of it has to do with my cd drive, so the fact that I have a generic E-IDE 50X L with the normal Adaptec interface shouldn't be important here. What may be important is that I am running Windows 98, 256 mb RAM, AMD-K6 3D processor... but that probably doesn't matter on these issues either. Here they are:
Nice to see ogg vorbis rc3 in the new CDex. This inclusion would be much better if at least one decimal place were available in setting quality level using the slider. This will be a big issue for a lot of users; lots of us like to use 3.5 or 4.99 or 5.25 or settings like that to encode ogg files. And since the quality settings are the way that vorbis rc3 is supposed to be used and certainly gives the best results unless careful control over file size, and being able to choose from the full range of quality options is important.
A possible addition to the ripping function: It would be nice if, when "abort" is selected during ripping, the portion of the track that was ripped so far would be saved and available for usage. This is nice when ripping in secure mode "full paranoia" and a certain track is taking forever, it’s nice to be able to stop the ripping but still have the results of what has been ripped so far. This is how EAC works.
Finally, a problem that I’ve noticed in past versions is still present in this one. When converting mpeg to wav, Cdex messes up with wma files. It will initially estimate a time, and then increase the estimate and finally exceed it, even though the blue horizontal bar indicator is all filled up, implying that conversion is finished. At that point, after waiting for some time with nothing happening, I hit abort, and force cdex to shut down if necessary (ctrl-alt-del). When I attempt to play the file in Winamp, it is listed as being 405:47 long no matter what the actual length is. At least winamp can play the wav; Windows Media Player lists the same time (as 6:45:47) but claims that the file type is invalid when I attempt to play it. CDex decodes ogg and mp3 just fine, but this wma thing is an issue. Not that I’m a wma fan or think that it’s worth using, but still... Whenever I do need to decode a wma file, I've been using dBpowerAMP, it would still be good if CDex could do this correctly.
Finally, a wish list of stuff which isn't all that important, but is worth considering for future updates:
- replaygain compatibility for decoding; mpeg to wav takes the track's replaygain value (if one exists) into account when decoding to wav. Basically a scaling function.
- a ripping dialog box that gives a lot more information than the current one. Percent of track, avg speed so far, current speed, etc. And it would be nice to know what is slowing the ripper down at certain points. In EAC, when ripping a really scratched cd, I can see that the program is reading a sector numerout times. With CDex, all I know is that the ripper got stuck on a certain % value of the track.
Thanks for your work in putting CDex out there. It's much appreciated by me and others. Peace,
Tim