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: CDex updated to v1.70b4 (Read 17095 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CDex updated to v1.70b4

At least, that's what their website says. November 2009 has brought 2 major updates, the latest being version 1.70b4. It'll be intersting to see the competition between them and EAC ramp up again.

CDex updated to v1.70b4

Reply #1 –
It's still horribly broken for the uninitiated as it defaults to a minimum bitrate for VBR encoding of 128Kbps as opposed to the standard default of 32Kbps. It also uses LAME 3.98 by default as opposed to the widely recommended 3.98.2. How is this "back in the game" exactly? 

CDex updated to v1.70b4

Reply #2 –
There was never a competition between CDex and EAC. EAC is secure. CDex is not. End of discussion.

CDex updated to v1.70b4

Reply #3 –
Can EAC record 400+ CD's in barely 4 days, at breakneck speed, while giving you the accuracy that you want to get quality recordings? I don't think so. And when, on occasion, a track you've recorded has an error (which was rare), all one had to do was re-record the track in full paranoia mode, and everything was fine. In fact, when using the standard recording mode in CDex, the amount of errors I had recording all those CD's would fit on one hand. And I'd still have room to spare. With these capabilities, it's no wonder that Hydrogenaudio recommend CDex, along with EAC, to extract audio from CD's.

BTW: The last time I checked, one can easily upgrade to the latest version of LAME in CDex. I've done it.

CDex updated to v1.70b4

Reply #4 –
Quote from: DP3_001 on
Can EAC record 400+ CD's in barely 4 days, at breakneck speed, while giving you the accuracy that you want to get quality recordings?
Depends on the drive.  If the drive provides reliable C2 pointers and does not cache, EAC can do this at burst speeds.  For drives that cache you can use burst mode with T&C.  There is no faster way without AccurateRip, which EAC can use (can CDex?).  So guess which ripper wins here?  Not CDex.

Quote from: DP3_001 on
And when, on occasion, a track you've recorded has an error (which was rare)
"You've," eh?  You're telling others how often they get errors when ripping?  I didn't know you were omniscient. 

Quote from: DP3_001 on
all one had to do was re-record the track in full paranoia mode, and everything was fine.
Nonsense.  Because red book error correction is not very robust, uncorrectable errors aren't all that hard to come by.  DAE software can't perform miracles, not even CDex.

PS: Competing with EAC may have put CDex back in the game a few years ago.  These days it barely passes for admission.

CDex updated to v1.70b4

Reply #5 –
What's good in entering a flame war of fanatics defending one or the other software? The point is, we have multiple choices here and everyone can select what best fits him. Tastes are, certainly, different. Although I have never used CDex, I am happy that an other piece of free software is alive and capable to give developers the necessary motivation for further work.

CDex updated to v1.70b4

Reply #6 –
Quote from: Matyas on
I am happy that an other piece of free software is alive and capable to give developers the necessary motivation for further work.

As am I.

I'm not particularly happy about being being given a line of bullshit telling me that I have nothing to worry about so long as I use CDex in full paranoia mode, however.

With the exception of C2 pointers or AccurateRip (neither of which CDex currently supports), do you dispute that there is no faster way to detect errors than 2X burst reading?

CDex updated to v1.70b4

Reply #7 –
I did a quick test to prove how unsecure CDex is even on a non-caching drive. I ripped a track from a badly scrtached cd 4 times--twice with standard mode and twice with full paranoia. 4 rips with 4 different MD5 checksums. Not once did CDex report an error. All rips were tagged as ok.

Here are the screenshots. Notice the CRC column differs each time.

full paranoia trial1


full paranoia trial2


standard trial 1


standard trial 2

CDex updated to v1.70b4

Reply #8 –
Quote from: greynol on
Quote from: Matyas on
I am happy that an other piece of free software is alive and capable to give developers the necessary motivation for further work.

As am I.

I'm not particularly happy about being being given a line of bullshit telling me that I have nothing to worry about so long as I use CDex in full paranoia mode, however.

With the exception of C2 pointers or AccurateRip (neither of which CDex currently supports), do you dispute that there is no faster way to detect errors than 2X burst reading?


I was curious enough to try the latest CDex.  It does support C2 as can be seen when you choose not to use the default generic settings and instead choose to detect read settings.  You are then presented with a list of supported read configs and can choose one.

I didn't use CDex to rip a CD yet (just been investigating the settings) so I can't comment on its ability to report errors, and I'm also unable to know if the person who tried it and got lots of errors which went unremarked had actually set the application up in a reasonable way (as we know is necessary for pretty much any DAE tool).  It may be that CDex does not present the full capabilities of cdparanoia.  If so that's a shame because cdparanoia certainly does report errors and one would expect that a graphical interface should do the same. 

I noticed that in the encoder settings one can use an external decoder, so criticism of the default version of lame seems invalid.  You can use whichever version of whichever encoder you like.

I don't use CDex or have any preference for CDex over anything else but I do believe that any test/comparison or comment should be done in a reasonable way and in a way that can be shown to be reasonable. In particular the assessment of the current version should be on that version's merits (or otherwise) and not coloured by issues in older versions.  Assumptions don't make a good basis for discovery.  cdparanoia went through huge improvements and perhaps CDex has as well (though I don't know, maybe it sucks).

CDex updated to v1.70b4

Reply #9 –
One more thing CDex could use--log generation. So one wouldn't have to resort to screenshots for testing.

CDex updated to v1.70b4

Reply #10 –
Quote from: Takla on
I noticed that in the encoder settings one can use an external  decoder, so criticism of the default version of lame seems invalid. You  can use whichever version of whichever encoder you like.
Quote from: Slipstreem on
it defaults to a minimum bitrate for VBR encoding of 128Kbps as opposed to the standard default of 32Kbps. It also uses LAME 3.98 by default as opposed to the widely recommended 3.98.2
If you don't understand the implications of what Slipstreem says, I suggest you stop posting here until you do. We are concerned about audio quality here, and Slipstreem's comments document a case where CDex is ignoring best-practices for creating top-quality MP3.

Quote from: DP3_001 on
Can EAC record 400+ CD's in barely 4 days, at breakneck speed, while giving you the accuracy that you want to get quality recordings? I don't think so.
In burst mode with AccurateRip, EAC should be no slower than any other ripper. And as we've documented above, CDex produces MP3s by default that are not in compliance with best-practices, making its results not what I'd consider "quality recordings".

Quote from: DP3_001 on
In fact, when using the standard recording mode in CDex, the amount of errors I had recording all those CD's would fit on one hand. And I'd still have room to spare.
How are you diagnosing these errors? Are you absolutely certain none have slipped by? No inaudible errors, no interpolated errors, nothing? Show us this proof.

Quote from: DP3_001 on
With these capabilities, it's no wonder that Hydrogenaudio recommend CDex, along with EAC, to extract audio from CD's.
Your grammar here is kind of broken. Are you implying that we currently recommend CDex along with EAC? Because we do not. Are you implying that we should begin to recommend CDex alongside EAC? There are some quality issues that would have to be resolved before anyone here would be comfortable doing that.

Quote from: DP3_001 on
BTW: The last time I checked, one can easily upgrade to the latest version of LAME in CDex. I've done it.
You're missing the point.

Quote from: Matyas on
What's good in entering a flame war of fanatics defending one or the other software? The point is, we have multiple choices here and everyone can select what best fits him. Tastes are, certainly, different.
The issue at hand are the uninformed dropping onto Hydrogenaudio and telling us that the two pieces of software are equivalent for producing secure rips. This is not true, and we aggressively defend the truth around these parts. If quality is not a concern, go ahead and use CDex. If quality is even the slightest concern, go use a different ripper like EAC, dBpoweramp or foobar2000 now that it has AccurateRip support.

CDex updated to v1.70b4

Reply #11 –
Quote from: Canar on
Quote from: Takla on
I noticed that in the encoder settings one can use an external  decoder, so criticism of the default version of lame seems invalid. You  can use whichever version of whichever encoder you like.
Quote from: Slipstreem on
it defaults to a minimum bitrate for VBR encoding of 128Kbps as opposed to the standard default of 32Kbps. It also uses LAME 3.98 by default as opposed to the widely recommended 3.98.2
If you don't understand the implications of what Slipstreem says, I suggest you stop posting here until you do. We are concerned about audio quality here, and Slipstreem's comments document a case where CDex is ignoring best-practices for creating top-quality MP3.


Yes I do understand his point.  However the encoder and its unsatisfactory default are both entirely optional and configurable. Neither is fixed.  The user can change both.  I agree that better defaults, in both cases, would be preferable.  But that doesn't make it a poor application (though it may be for various reasons), but one with poor defaults.  For example, and for comparison,  EAC fails to correctly detect the caching feature of one of my optical drives, so either by default or after using the set up wizard the settings are plain wrong.  That doesn't mean I consider the application to be no good, it just means the default settings and the settings derived from  the hardware detection wizard are not entirely satisfactory out of the box.  So guess what...I change the settings and it's OK 

I would not expect anyone who says that these configuration issues are insignificant (being easily overcome) be offered the same unwarranted response of "I suggest you stop posting here until you do". 

Your suggestion that I stop posting seems inappropriate and unwarranted.  I didn't break any of the posting rules and I've offered only rational points which can be easily substantiated.

CDex updated to v1.70b4

Reply #12 –
Quote from: Takla on
EAC fails to correctly detect the caching feature of one of my optical drives

I don't believe you.  Please provide some evidence.

CDex updated to v1.70b4

Reply #13 –
Quote
What's good in entering a flame war of fanatics defending one or the other software? The point is, we have multiple choices here and everyone can select what best fits him. Tastes are, certainly, different. Although I have never used CDex, I am happy that an other piece of free software is alive and capable to give developers the necessary motivation for further work.


This is the Philosophy I believe in as well. The only problem is CDex needs a lot of work in terms of what needs to be implemented and their are a lot of people that have neither the knowledge or know-how to accomplish these tasks (at least with this project) and there are naysayers  who don't help either, because the apparently have the time to sit around all day and pick at it apart having no vested interest in it. Take for example I would like to see it ported to other Operating Systems and upgraded to cdparanoia 10 that's a first step!  Somebody else mentioned a detailed log generation files which would help as well!
budding I.T professional

CDex updated to v1.70b4

Reply #14 –
Quote from: greynol on
Quote from: Takla on
EAC fails to correctly detect the caching feature of one of my optical drives
I don't believe you.  Please provide some evidence.

Thanks for the kind words    I feel like I just asked for a rare steak at a vegan restaurant.

Here is a screenie of EAC having completed the set up wizard.  As you can see it shows that the drive does not cache audio.  However the drive does cache audio.  I confirmed this by running 'cdparanoia -A' which is the analyse mode of cdparanoia.  During this analysis the drive cache and timing behaviour are analysed.  One can watch as the cache is detected, filled and as cdparanoia checks it can be flushed and defeated.  I'll post that as well.



And here is the output of 'cdparanoia -A'

Code: [Select]
$ cdparanoia -A
cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/cdrom for cdrom...
	Testing /dev/cdrom for SCSI/MMC interface
		SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVDRAM GH15F EG00 
 

Checking for SCSI emulation...
	Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...
	Drive is MMC style
	DMA scatter/gather table entries: 1
	table entry size: 131072 bytes
	maximum theoretical transfer: 55 sectors
	Setting default read size to 27 sectors (63504 bytes).

Verifying CDDA command set...
	Expected command set reads OK.

Attempting to set cdrom to full speed... 
	drive returned OK.

=================== Checking drive cache/timing behavior ===================

Seek/read timing:
	[53:17.07]:   54ms seek, 0.33ms/sec read [40.6x]                 
	[50:00.00]:   46ms seek, 0.35ms/sec read [38.2x]                 
	[40:00.00]:   60ms seek, 0.38ms/sec read [35.0x]                 
	[30:00.00]:   51ms seek, 0.42ms/sec read [31.9x]                 
	[20:00.00]:   57ms seek, 0.48ms/sec read [27.8x]                 
	[10:00.00]:   57ms seek, 0.57ms/sec read [23.2x]                 
	[00:00.00]:   58ms seek, 0.74ms/sec read [18.0x]                 

Analyzing cache behavior...
	Approximate random access cache size: 16 sector(s)               
	Drive cache tests as contiguous                           
	Drive readahead past read cursor: 234 sector(s)                
	Cache tail cursor tied to read cursor                      
	Cache tail granularity: 1 sector(s)                      
	        Cache read speed: 0.15ms/sector [86x]
	        Access speed after backseek: 0.71ms/sector [18x]
	Backseek flushes the cache as expected

Drive tests OK with Paranoia.
Very few applications are perfect.  Perhaps only the very simplest applications are entirely free of bugs.  Manufacturers of optical drives are not always forthcoming about their products' cache behaviour and it's unreasonable to expect every application to be able to correctly detect every strategy.  Personally I don't expect EAC or any other complex application to be 100% perfect and I'm not disappointed if it isn't.  This is expressed more succinctly by the developers of cdparanoia http://lists.xiph.org/pipermail/paranoia/2...une/001575.html 
Quote
> The reason for using EAC instead of cdparanoia has been that EAC has
> been able to handle drives with caches, while cdparanoia hasn't.

Well, it's more that EAC expects drives can have bigger/different
caches than older Paranoia did.  A few more drives today also offer
command set ways to force media access, as opposed to attempting to
trick the drive into flushing cache via access patterns. But only a
few (and you can't rely on that).

Both EAC and Paranoia will still have the problem where a drive with a
completely different cache strategy can defeat them without either
knowing (thus bundling the new -A tests with cdparanoia that tries to
find these drives).

CDex updated to v1.70b4

Reply #15 –
Sorry, but your assessment of EAC's test is simply wrong.

For EAC's purposes the drive must cache more than 64kB in order to require cache flushing.

You might not have liked it, but I was correct in calling you on your misinformation.

CDex updated to v1.70b4

Reply #16 –
I had a look at CDex page at sourceforge http://sourceforge.net/projects/cdexos/develop where I saw:

Quote
#
Comment: Updated Lame dll 3.97a11

Latest Latest LAME release: v3.98.2 (September 2008) is included with CDex 1.70 Beta 4.

2009-11-20 14:13:29 UTC by codingmaster


However after looking at the changelogs it seems that CDex still does indeed use an older version of cdparanoia i.e. earlier than 10.2.  This alone means that it is unsuitable for secure DAE in many circumstances so it's rather pointless to consider its default settings or other features.  It may be that the changelog is not comprehensive as the project generally is not very well documented. I'm downloading the source code and hope it indicates which version of cdparanoia is used.

CDex updated to v1.70b4

Reply #17 –
Quote from: greynol on
Sorry, but your assessment of EAC's test is plainly and categorically wrong.

For EAC's purposes the drive must cache more than 64kB in order to require cache flushing.

You might not have liked it, but I was correct in calling you on your misinformation.



I couldn't find this in EAC's documents so I appreciate the correction.  Can you point me towards some more comprehensive/authoritative documentation?

CDex updated to v1.70b4

Reply #18 –
My apologies.  My use of the word "categorically" was ill-advised.  The point is that EAC's test was solely designed for its own purposes.

Here you go:
http://www.digital-inn.de/106824-post3.html

You'll see that I worded my post inconsistently.  Apparently drives that cache 64kB do not need flushing within EAC either.

CDex updated to v1.70b4

Reply #19 –
Quote from: greynol on
My apologies.  My use of the word "categorically" was ill-advised.  The point is that EAC's test was solely designed for its own purposes.

Here you go:
http://www.digital-inn.de/106824-post3.html

You'll see that I worded my post inconsistently.  Apparently drives that cache 64kB do not need flushing as well.


Thanks. Here are Andre Wiethoff's actual words

Quote
The smallest block size which is read is 64 kB, so usually every cache smaller than this block size does not count (as usually blocks larger than this value are read in one go)
But of course, to be really sure, it can be enabled though...

cu, And


So it seems he is slightly cautious about being definitive on this (see the use of the word usually).

Anyway my original point was that an application with less than ideal (but user configurable) defaults is not necessarily a bad application, only one with unsatisfactory defaults.  In the case of CDex there are much better reasons to not use it 

CDex updated to v1.70b4

Reply #20 –
Of course.  He's typically cautious about everything he says since there are always those who like to nitpick.

Anyhow, here's another post where he doesn't exercise the same amount of caution (though he still uses words like "normal" and "should"):
http://www.digital-inn.de/113449-post2.html

Honestly, if he knew about a loophole in his test, don't you think he would have fixed it rather than allowing it to stay to be potentially exploited?

CDex updated to v1.70b4

Reply #21 –
Quote from: greynol on
Of course.  He's typically cautious about everything he says since there are always those who like to nitpick.

Anyhow, here's another post where he doesn't exercise the same amount of caution (though he still uses words like "normal" and "should"):
http://www.digital-inn.de/113449-post2.html

Honestly, if he knew about a loophole in his test, don't you think he would have fixed it rather than allowing it stay to be potentially exploited?


Yes I'd think he would fix it.  But I'm not sure it has to be a 'loophole'.  However expert he is it's unlikely he can anticipate a test for every cache strategy, particularly when some manufacturers decline to make their methods or specifications available.  It's a little too much to ask of any developer that he makes a product so perfect that it is future proof, or even that it works ideally with every piece of hardware currently.  I'd be amazed if Mr Wiethoff has not updated and revised EAC's hardware detection and cache defeating capabilities numerous times already.  I'd be even more amazed to see him claim these features worked ideally in all circumstances right now.


CDex updated to v1.70b4

Reply #22 –
In the meantime, I believe (another weasel word) that you are 100% safe in telling EAC that your HL-DT-ST DVDRAM GH15F does not cache audio data.

CDex updated to v1.70b4

Reply #23 –
For information:

I finally completed downloading CDex source code from their SVN repository and can confirm for sure that it uses an old version of cdparanoia:

From cdex/CDRip/paranoia/README

Quote
This is Monty's <monty@xiph.org> paranoia library that allows high quality
digital audio extraction even with scratched CDs. It is taken from the
cdparanoia-III-alpha9.5 package.


So whatever improvements have been made in the GUI and whatever features or facilities have been added it is all undermined by use of this old version.  For CDex users or potential users who are not clear what the problem is here is an explanation of why versions of cdparanoia prior to 10.2 should be avoided:

http://www.xiph.org/paranoia/news.html

Quote
10.2 includes a raft of minor bugfixes in device scan, device autosense and the transport layer.

More importantly, 10.2 addresses serious CDROM drive cache modelling deficiencies that exist in earlier versions. In a nutshell, a sizable fraction of modern drives exhibit new and exciting readahead cache abuses/bugs of which older versions of cdparanoia were not fully aware. This means that skips and cracks could slip through the cache management strategy of older versions completely undetected. 10.2 fully addresses and models these new cache behaviors.


Quote from: greynol on
In the meantime, I believe (another weasel word) that you are 100% safe in telling EAC that your HL-DT-ST DVDRAM GH15F does not cache audio data.


I stand corrected, and better informed.  That's what a discussions is for isn't it?