Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: open letter to Al Faber: CDex 1.40 rc1 (Read 4951 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

open letter to Al Faber: CDex 1.40 rc1

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
God kills a kitten every time you encode with CBR 320

open letter to Al Faber: CDex 1.40 rc1

Reply #1 –
Well, I'm an administrator of CDex project (don't really know how I get there  ), So I believe I'm entitled to answersome of the questions:

Quote
Originally posted by timcupery

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.


John33 and I have already taken care of that issue.

Quote
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.


I'll se if we can do something.

Quote
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.


Have you already taken a look at WMA's sdk?

Anyway, I think (not my area in CDex) WMA reading is done by PP's "Alternative" WMA plugin. So, there's not much we can do.

Quote
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.


Again, it depends on Winamp plugins (Peter will kill us someday because of that).

Quote
- 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.


I can take a look, but that's not my area either.

Thanks a lot for your constructive criticism.

Regards;

Roberto.

open letter to Al Faber: CDex 1.40 rc1

Reply #2 –
I have only 1 enhancement request: make Full Paranoia truly secure.

If I rip a track in full paranoia, get back a ripping status of OK with no errors...only to find that the file has clicks and pops then it's enough to drive me mad (especially if I already burned it to CD).

Until Full Paranoia is truly secure it will still play second fiddle to EAC.

All the little things (vorbis tagging, etc.) are nice icing on the cake...but until the ripping (after all the main task of CDEx) is the best that can be most people would never use it...

open letter to Al Faber: CDex 1.40 rc1

Reply #3 –
these are all the wishes i still have for cdex:

"encode while ripping" option (saves alot of time)

rename "external mp+ encoder" to "external mpc encoder" ;D

and the biggest one: ripping from multiple drives. only mediajukebox got this so far (correct me if i'm wrong!)

open letter to Al Faber: CDex 1.40 rc1

Reply #4 –
Quote
Originally posted by ilikedirtthe2nd
these are all the wishes i still have for cdex:

"encode while ripping" option (saves alot of time)


You mean on-the-fly encoding? You can do it with any dll encoder (Lame, FAAC, Gogo, MP2...), and some command line encoders that support stdin encoding.

Quote
rename "external mp+ encoder" to "external mpc encoder" ;D


It's been renamed by me to Musepack Encoder. 

Quote
and the biggest one: ripping from multiple drives. only mediajukebox got this so far (correct me if i'm wrong!)


Far away from my coding skills. Sorry.

Regards;

Roberto.

open letter to Al Faber: CDex 1.40 rc1

Reply #5 –
Quote
You mean on-the-fly encoding? You can do it with any dll encoder (Lame, FAAC, Gogo, MP2...), and some command line encoders that support stdin encoding.


no i don't mean on-the-fly encoding. what i mean is, that the encoder is processing the tracks, which are allready ripped while the next tracks are ripped. (for the command line encoders that don't support stdin).

Quote
It's been renamed by me to Musepack Encoder.


thanks! i think this was really important!

Quote
Far away from my coding skills. Sorry.


yes, you would have to restructure big parts of the interface, but maybe there is someone who can do this one day...

regards; frederic

open letter to Al Faber: CDex 1.40 rc1

Reply #6 –
Just to confirm a couple of things that Roberto mentioned above.

1. I have already amended the oggvorbis interface so that the full range of quality settings is available.

2. I have heavily reworked the lame dll and the interface so that the full range of Dibrom's presets is available. r3mix is still available. The normal CBR settings are also available on 'q' settings 0, 1, 2, 3, 5, 7 and 9. The standard VBR and ABR settings are also still available. There is a current maximum of 15 preset options available, and they are now all used!!

Hopefully, all of this will make its way into 1.40 before final release. Roberto is dealing with this currently.

john33

PS. A quote from the pages of Xiph.org regarding CDParanoia III alpha 9.8 "Also, alpha 9 does not yet include scratch detection and repair or info file support.". Probably answers the above questions?

open letter to Al Faber: CDex 1.40 rc1

Reply #7 –
Quote
Originally posted by john33
I have heavily reworked the lame dll and the interface so that the full range of Dibrom's presets is available.
There wouldn't by any chance be a compiled binary of this fantastic dll on Roberto's site, would there? Does it still use hacked workarounds for Dibrom's presets? It would be SO nice to have the methods straight-forward.

open letter to Al Faber: CDex 1.40 rc1

Reply #8 –
Quote
Originally posted by layer3maniac
There wouldn't by any chance be a compiled binary of this fantastic dll on Roberto's site, would there? Does it still use hacked workarounds for Dibrom's presets? It would be SO nice to have the methods straight-forward.


It'll be included in next CDex, as soon as I manage to discover how to upload the sources back to sourceforge through WinCVS  (If someone knows how to do this, PLEASE send a tutorial, or any piece of information you can spare, to my mail address: rjamorim at yahoo dot com. I'm really in a hurry. Final 1.40 version will be out soon. )

Here's a screenshot of the VBR settings with alt presets:




Regards;

Roberto.

open letter to Al Faber: CDex 1.40 rc1

Reply #9 –
...that should be trivial, since it already works with
other formats.

when MPEG->MPEG (shouldn't be called transcoding
since it support more than MPEG?) put ID3 tags into
Vorbis Tags.

It would be great to encode a collection in a lossless
format with ID3 and later transcode to any new Vorbis
rather than rip it every time.

It not only saves time but avoids the risk of finding out
that when Vorbis 4.0 RC1 comes out all my CD's are
already way too much scratched

Cheers, AGS.

open letter to Al Faber: CDex 1.40 rc1

Reply #10 –
just my 2 llamas: mr. Faber - have you ever heard about asking for permission before including someone else's software ? you don't seem to read licenses at all. i really don't care about my work being included, but AOL might be unhappy with that. also, using in_vorbis instead of making your own libvorbis decodning interface looks like overkill for me.
Microsoft Windows: We can't script here, this is bat country.