• Changer Support (Drives can be grouped together with the changers configuration menu)
• CDDB Submission Support
• MusicBrainz Metadata Retrieval
• Various Bugfixes And Architectural Changes

To use the infamous Nakamichi changers, each drive should be configured as a Sony/Plextor Drive with Secure Extractor. Note: Secure Extractor will need to be configured to not read C2 errors as the drive doesn’t support the feature. Currently, the Secure Extractor plugin is significantly slower than the old CDXTRACT 3 synchronized extractor, but the results are far more trustable. I would say this drive is probably good enough for normal lossy ripping applications, but I cannot recommend it for lossless archival ripping until I finish Secure Extractor 2, which will be far more intelligent than the current one.

Flash forward to sixteen months ago. I had just purchased a CD which couldn’t be ripped using any of my third-party tools at the time. As it turns out, it was a Sony CD with XCP copy protection, which mangles the table of contents on the CD as it appears through programs asking Windows, but not to programs reading the disc directly. So after firing up CDXTRACT 3, I found that I could rip this CD without difficulty. (assuming the malware wasn’t installed) At this point, I was reenergized and starting majorly refactoring the CDXTRACT 4 code base. I took out most of the pluggable everything code, which reduced the complexity considerably, and removed the compiler-time character types. (unicode/ANSI) I was still working under the assumption that I would be able to make it cross-platform and I had a plan in place to use wxWidgets to make a cross-platform GUI. After the first refactoring pass, I added functions to detect and disable parts of the XCP malware which prevented ripping. (a filter driver called $sys$crater) I wrote some more base code and had a reasonable console version that could rip WAV files. Soon, I realized that the academic exercise wasn’t that interesting because the architecture was almost exactly the same as CDXTRACT 3, and I would stop working on that version.

Flash forward to three months ago. Relatively recently, (in a geological timeframe) I had re-ripped my entire CD collection to WMA Lossless for use with a set-top media player. Since CDXTRACT 3 never supported WMA Lossless, I went in search of other programs which could rip from multiple drives at once to that format. I ended up finding one and ripping all of my CDs over a several week period. The problem was that it was clunky and not free. (as in beer) So a little while later, that itch to rearchitect CDXTRACT 4 came back and I started working again. I decided to work in an environment and architecture that was purely geared towards my personal productivity and original goals. CDXTRACT 4 was completely rewritten in Visual Studio 2005 in a combination of native C++, C++/CLI, and C#. The downside is that cross-platform is now gone. The upside is that it’s almost ready. I’m hoping to release the first public beta by the end of the year.

System Requirements

• Windows 2000/XP/Vista (Administrator rights are not required)
• .NET Framework 2.0
• One or more CDROMs supporting MMC-3 (every drive in the last 7 years) or D8 read commands

New Features

• Full unicode support, including tagging of all supported formats
• Separate artists per track, allowing compilation tagging to be significantly better
• Rip to multiple output formats at once
• iTunes automation with supported formats (import/convert)
• Updated format support, including the latest versions of LAME/OggVorbis/FLAC/WMA9
• Secure extraction requiring reduntant reads and data comparison

Missing Features (Compared With Version 3)

• CDDB submission
• Audio play controls
• Range extraction

Screen Shots

• Windows XP
• Windows Vista