CDex 1.51 released Options

[slothdog]

CDex 1.51 has been released.

Changes:
* Fixed normalization problem
* Fixed play digital CD function
* Fixed filename generation when % character was in trackname
* Better support of USB drives when using Native NT SCSI library option
* Various small bug fixes

Downloads

[Frampesomi]

thnx! i like cdex, even if people always recommend EAC.

[irchs]

I'm a CDex user also Thanks

[Jojo]

I think he just wants to lead the sourceforge charts again . Anyway, thanks I like Cdex a lot

[kwanbis]

would it be posible to have an option like in EAC (%o) which represent the full final filename that the track would be?

[AngelGR]

I think he just wants to lead the sourceforge charts again 

No, there were a few problems and they're solved now.

[ss1]

I'm an avid user of CDex - Great program! Easy to use and allows me to rip to .flac files with ease.


ss1.

This post has been edited by ss1: Sep 11 2003, 19:09

[Miles]

Just like that? No alphas or betas at all?
Anyway, It's a great news, thanks!

[calx]

I decided to try cdex but I'm having a small problem. I'm trying to use LAME 3.90.3 as external encoder but I keep getting an error message saying data can't be sent to the external encoder. I think I made my mistake in the parameter string. This is what I used:

--alt-preset standard --pad-id3v2 --tt "%t" --ta "%a" --tl "%g" --ty %y --tn %n --tg "%m" %1 %2

That's what I was using in EAC. I already put in the %1 & %2 at the end of the string. I think that part is right. What else do I have to change for it to work in CDex?

[zegilles]

try to add quotes around the paths:

CODE

--alt-preset standard --pad-id3v2 --tt "%t" --ta "%a" --tl "%g" --ty %y --tn %n --tg "%m" "%1" "%2"

[R.A.F.]

A new CDex-boom? Why that? - But the grabbing-routines still aren´t as good as in EAC.
BTW: I use EAC since ever and for-ever.

[master]

But the grabbing-routines still aren´t as good as in EAC.

Can you please define on what u said?

[R.A.F.]

I meant, that the routines for reading scratched CD´s at CDex´ paranoia-mode, complete are not as good as those from EAC in secure-mode.
Also I couldn´t read about any improvements there in the changelog from 1.50 to 1.51.

P.S.: I´m not interested in a war between the EAC- and CDex-fans, even if that may have looked like this before.

This post has been edited by R.A.F.: Sep 13 2003, 17:08

[calx]

try to add quotes around the paths:

CODE

--alt-preset standard --pad-id3v2 --tt "%t" --ta "%a" --tl "%g" --ty %y --tn %n --tg "%m" "%1" "%2"

bah! it didn't work. back to EAC!!

[Jan S.]

Read Pio2001's test of CDex vs. EAC in the wiki:

http://doc.hydrogenaudio.org/wikis/hydroge...AudioExtraction

Shows how EAC is a lot better (but keep in mind that this is also drive dependent).

[Frampesomi]

I know EAC is supposed to do a better job, but i also did a number extractions using EAC & CDex.
And all of them were 100% the same. So for me, CDex is easier to use, and i'm able to encode *on the fly* to MPC, OGG, WMA and others. And CDex is faster.

But then, i don't have any scratched CDs.
However, i don't know how often we have a bad media.

For me, CDex is sufficient.

[R.A.F.]

.... So for me, CDex is easier to use, and i'm able to encode *on the fly* to MPC, OGG, WMA and others. And CDex is faster.

With EAC you can also encode on-the-fly. You only have to configure it right.
Just go to EAC -> EAC-Options -> Tools -> and set there On extraction, start external compressors queued in the background and Use [1] simultaneous compressor-thread(s).
EAC will now read-out the CD, and start to compress simultaneously (means: reading and compressing at the same time), when the first song of the CD once was cached as WAV on hard-disk. So, it´s just a myth that CDex is faster. And if, then only because the grabbing-routines don´t have such a high security-level as the ones built-in in EAC !

Last hint (Edit):
You can speed-up EAC´s grabbing-speed by giving EAC in all a higher priority-level. Just go to to
EAC -> EAC Options -> Extraction -> Extraction and compression priority and set it from idle or normal to high ! Unfortunately the extraction- and compression priority can´t be set separately from each other, and that destroys in parts the advantage of the higher processing priority, as the compression-process slows down slightly then the extraction-process, which always should have a higher prio than the compression. That´s one of the last points of criticism on EAC, which is still waiting for an improvement. Someone should tell that to André Wiethoff one day....

This post has been edited by R.A.F.: Sep 14 2003, 13:02

[Jojo]

Would it be possible to process a spectral analysis do determine which frequency should be used? I did some testing on my CD's and found out that some songs use a frequency of 32 kHz only. However, I'm not sure what the 'automatic' option does, but my guess would be that it checks the frequency of the input file and uses whatever frequency has been used on that file. Anyway, if I rip a song from a CD I'm sure that Cdex always uses 44,1khz no matter if the actually frequency used in the file is only 32 kHz (based on a spectral analysis).
Therefore, I think it would be nice if there were a checkbox or something beneath the frequency setting (in case you choose the automatic frequency mode) so that a spectral analysis is done before encoding.

Any feelings about that?

Thanks

[zokik]

EAC has some advantages over CDex, but it isn't better in every way. We're talking about secure mode and cdparanoia full, right? CDex usually IS faster than EAC, it doesn't stress the drive as much as EAC, it is also much more responsive during ripping. Those things do matter a lot, it's not just error detection that matters. And if you have a non caching drive, I doubt EAC is much more secure that cdex, maybe not at all.
Besides, cdex is very quick, easy and robust to configure. With EAC you can easily ruin advantages of secure ripping if you make a mistake when configuring your drive, e.g. if you enable C2 because the drive reports it has this feature although it doesn't have it.
On other hand, if you know exactly how eac should be set up and you take your time to do it, you get more secure error detection, at least with caching drives. Plus eac has a lot of features cdex doesn't. For those who need them, that's great, for those who don't that's just more useless settings and things to get lost in.

[krazy]

Read Pio2001's test of CDex vs. EAC in the wiki:

http://doc.hydrogenaudio.org/wikis/hydroge...AudioExtraction

Shows how EAC is a lot better (but keep in mind that this is also drive dependent).

On the test where CDex slipped up, "A CDR that was becoming barely readable was used."

Surely this means that EAC is only shown to be a lot better when extracting audio from burned CD's?

As such CD's are often burned with Nero or some such burning program which doesn't do error detection during CD copying, many burned audio CD's would have read errors burned into them anyway and shouldn't we assume that they're not perfect copies of the original?

Can't we then conclude that CDex is as good as EAC for extracting from original audio CD's?

This post has been edited by krazy: Sep 14 2003, 11:47

[R.A.F.]

As such CD's are often burned with Nero or some such burning program which doesn't do error detection during CD copying, many burned audio CD's would have read errors burned into them anyway and shouldn't we assume that they're not perfect copies of the original?

Exactly for this reason I use EAC in secure-mode for reading out the whole original CD as an image with cue-sheet (at EAC: Action -> Copy image & Create cue sheet) to store it on hard-disk first. After this is done, I use as a second step Nero to just click on the cue-sheet and burn the new CD from HD.
In this manner it is secured, that you get a real 1:1-copy form the original CD, even if the original one was scratched in some way.

Can't we then conclude that CDex is as good as EAC for extracting from original audio CD's?

So, sorry, no.

Edit:
In some way you are right for sure. So your (as mine always is) slogan should be: Never trust an already copied CD !. That´s the main-reason for me, why I avoid them like the plague. Instead of it I always try to catch originals.

This post has been edited by R.A.F.: Sep 14 2003, 12:59

[Andavari]

On other hand, if you know exactly how eac should be set up and you take your time to do it, you get more secure error detection, at least with caching drives.

I made the mistake of needing a new CD drive when mine died in the middle of trying to re-install Windows and ended up frantically, and unknowingly buying a CD-RW drive that caches audio. Well actually I didn't have much choice since I needed a drive that day and had to go with the cheapo Memorex.

My findings with EAC on my Memorex drive (indeed it must be drive dependant) are not something to jump and be happy about. I've seen a few different posts about people stating CDex is useless with caching drives, however my experience has not shown it to be useless. I've had problems with EAC stating errors were corrected when in fact they weren't, and some of which sound worse than what CDex is capable of correcting. I wouldn't be saying this if my old DVD drive that did not cache audio had never died, it worked very good with EAC.

[krazy]

As such CD's are often burned with Nero or some such burning program which doesn't do error detection during CD copying, many burned audio CD's would have read errors burned into them anyway and shouldn't we assume that they're not perfect copies of the original?

Exactly for this reason I use EAC in secure-mode for reading out the whole original CD as an image with cue-sheet (at EAC: Action -> Copy image & Create cue sheet) to store it on hard-disk first. After this is done, I use as a second step Nero to just click on the cue-sheet and burn the new CD from HD.
In this manner it is secured, that you get a real 1:1-copy form the original CD, even if the original one was scratched in some way.

Can't we then conclude that CDex is as good as EAC for extracting from original audio CD's?

So, sorry, no.

Sorry, I didn't make myself clear...

The article states: "A CDR that was becoming barely readable was used."
If you have an audio CD which is not burned (a purchased, pressed disc), then wouldn't CDex would be as good as EAC at extracting audio from it?

This assumes that pressed CD's do not become "barely readable" unless due to scratches or holes in the disc, from which CDex extracted audio (and reported errors) with at least an equal level to EAC and, which seems to be the case, as they are manufactured differently and do not have the same degredation problems CDR's do.

If this is not the case, then how else do pressed CD's become "barely readable"?

[ancl]

If you have an audio CD which is not burned (a purchased, pressed disc), then wouldn't CDex would be as good as EAC at extracting audio from it?

If you have a cd without scratches or dust or any other "fault", all ripping programs will give the same result. The reason for using secure ripping is to find and/or correct the cases when this is not the case.

EAC is the best program to detect and give a warning when there is an error in the reading. CDex comes close but have problems when the drive cache data - a problem that EAC handles when checking "drive caches audio data".

They are not necesarily the best when it comes to extracting really scratched discs. Plextools is really good in extracting listenable data from those discs (for Plextor drives only), while EAC will give you a warning that there where errors. That is what EAC is best at - to tell you when something is wrong.

[Jojo]

Would it be possible to process a spectral analysis do determine which frequency should be used? I did some testing on my CD's and found out that some songs use a frequency of 32 kHz only. However, I'm not sure what the 'automatic' option does, but my guess would be that it checks the frequency of the input file and uses whatever frequency has been used on that file. Anyway, if I rip a song from a CD I'm sure that Cdex always uses 44,1khz no matter if the actually frequency used in the file is only 32 kHz (based on a spectral analysis).
Therefore, I think it would be nice if there were a checkbox or something beneath the frequency setting (in case you choose the automatic frequency mode) so that a spectral analysis is done before encoding.

Any feelings about that?

Thanks

I'm not sure whether that was just a stupid suggestion or if it just got lost because of the little war that started right after I posted that