The CDXTRACT Page

December 20th, 2006 by Colin

So roughly four years ago, I decided to start work on CDXTRACT 4. About eighteen months had passed since I did the last build of CDXTRACT 3 and I thought it was about time to start anew. I had recently aquired my copy of Visual Studio .NET and was relatively eager to start a reasonably sized project in an environment other and Visual C++ 6. My goal at the time was to have a unicode capable, cross platform GUI version of CDXTRACT 4 with dynamically loadable pluggable everything. I worked on that for a couple of weeks, making just a few core functions work when I realized it was going to be too painful and ugly to support my architecture on multiple platforms being able to compile for ANSI or unicode. At that point I realized that other programs out there were good enough for my ripping needs, and my intellectual curiosity had been satisfied at least for a while.

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