Present Perfect

So, before I shell out cold hard cash for new drives, I thought I should at least first figure out how I'm going to actually rip all my CD's.

If the goal of ripping my CD's is to have a perfect copy on disk, then certain logical conclusions present themselves.

• I should rip a CD completely as one file; this avoids problems with CD's with gapless transitions (for example, live cd's)  Besides gaps between tracks due to encoding (a lot of lossy compression methods have a windowing algorithm which causes them to actually decode some extra leading and trailing samples), there's also the fact that CD tracks are made up of sectors of 2352 audio bytes or  588 16-bit stereo samples (at 75 sectors per second), and so any audio file that's not a perfect multiple of the sector size will not be able to play back gaplessly on a CD because the sector gets zero-padded.  (Arguably they probably would be fine in separate files anyway given that I would expect a rip from CD to have exactly  a sector multiple of samples)
• Another reason to rip as one file is that I've come to believe that a good music management system should actually separate the concept of "song" from the concept of "medium".   A lot of "sound files" actually contain more than one song (think hidden track with lots of silence at the end of a regular CD track), and some sound files contain no songs at all (think spacers between songs and the hidden track).  If you don't know what I'm talking about then you haven't been sufficiently pissed off yet at how "All Apologies" comes with this incredibly long stretch of silence before a crap bonus track.
•  So if you're going to separate the concept of "audio file" and "song" anyway, why not go the whole nine yards and rip the whole CD as one track, allowing you to also re-burn a CD from that ?
• "songs" can then be defined as a start and end position in that file in the management system, defaulting to the actual cue points that the CD knows about

Of course, it's probably not going to be that easy yet to handle music like this.  I had a hard time finding any tools on Linux that would actually generate a .CUE file from a CD in my cd drive.  The closest I got was using cdrdao read-toc to generate a .toc file and then convert with cuetools.  Anyone know of other alternatives ?

Also, it didn't look like cdrdao deals with pre-gap tracks correctly.  For example, for "Any Minute Now" by Soulwax (I knew that Much Against Everyone's Advice had a pre-gap track, but that CD is locked upi in a box in Belgium.  But the internet told me that this album had one too, and lo and behold, there it was in all its crappiness), cdrdao extracts this:

CD_DA

// Track 1
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "BEP010400101"
SILENCE 05:29:03
FILE "data.wav" 0 04:35:07
START 05:29:03
So it marks the pre-gap as silence.  Annoying.  And also, tracks can have different pre-gap size, and it doesn't look like the .toc format takes this into account.  Does anyone know ?

(Also, I had completely forgotten about ISRC  codes, and I had *NO* idea they were actually recorded on CD tracks - not too old to learn - are FreeDB and MusicBrainz even tracking these codes ? Does anyone know of an on-line database of these things ?)

Once I know I have the tools and the format in place to make an exact copy of a CD, I can start looking at what I'll need to do to make a player support this if it doesn't yet, and maybe add GStreamer support if it's not there yet ?

To sum up - what do people use on Linux to rip a CD to one big audio file plus a .cue file that can be used to make a track-for-track identical copy of a CD, including pregaps ?

So, before I shell out cold hard cash for new drives, I thought I should at least first figure out how I'm going to actually rip all my CD's. If...

I was gearing up for buying two 750 GB drives, put them in software RAID, and then re-encode all my CD's to FLAC instead of Ogg like they are now.

I want to use FLAC so I have a perfect copy stored, and from that I can regenerate whatever I want for whatever other situation.   I used to have everything in Ogg, but with my Nokia 800 and Kristien's iPod that's just not the most useful format to have.

I figure I should be able to store around 1700 CD's on there, which is about 400 more than I currently have.

Except that now it seems there are 1TB drives available, for 50% more money than the 750GB ones.  So not exactly at the sweet spot, but not that unreasonable either... And by now I have so many old hard drives lying around collecting dust that I've come back a little on always buying at the lowest dollar/GB price.

Sigh, decisions! Please vote in the comments.

I was gearing up for buying two 750 GB drives, put them in software RAID, and then re-encode all my CD's to FLAC instead of Ogg like they are now....

I type duck all the time.  It makes me feel pythonic.

I type duck all the time.  It makes me feel pythonic.

If you find it, please bring it back. It would let us fix monstrosity warnings like this one:

WARNING: failed to install schema `/schemas/apps/gnome-sound-recorder/popup-warning-v' locale `C': Unable to store a value at key '/schemas/apps/gnome-sound-recorder/popup-warning-v', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf

If you find it, please bring it back. It would let us fix monstrosity warnings like this one: WARNING: failed to install schema `/schemas/apps/gnome-sound-recorder/popup-warning-v' locale `C': Unable to store a...

While doing various tasks around the house and ripping CD's I have from bands playing at next week's Pukkelpop festival I've been tackling some simple moap bugs so I can do a next release.  I've reworked a patch Tim sent in (a project starts getting fun when outside people start contributing and send in patches, making it heaps more easy for you to actually get stuff done if you just have to review and adapt patches), fixed another one of the bugs he filed, and fixed a bug for Philippe who seems to think French is a perfectly fine language to run a computer in.

In fact, for the first time I've picked a milestone date for 0.2.6 so I can coax other contributors like Marc-André Lureau into getting their patches ready for this Saturday.  He has been doing work on the git and git-svn VCS backends.

In related news, I talked to Martyn Russell (who works on maintainer.py) while at GUADEC to see if we could possibly merge our efforts.  I was specifically avoiding copying any functionality maintainer.py provides until I had some time to discuss this idea with Martyn himself.  I don't want to jump the gun but  we agreed on merging the projects and should now figure out the practical details.

On my side, it probably involves changing the logo and moving SVN and Trac to Freedesktop, a more neutral ground.  This means I have to double-check with people like Daniel who have an aversity to SVN, but hey, I should be able to be FDO's Subversion bitch right ?

After that, it's a matter of bringing all of maintainer.py's functionality under, for example, a "gnome" subcommand.

I've also had some interest expressed from people hacking on Gentoo, Debian, KDE, and Nokia to integrate some stuff into moap, but we'll see how that pans out when we get there.  It should in fact be easy to extend moap by dropping in additional command classes, so I guess I should make that possible in the future.

In related news, my Practical Project Maintenance talk at GUADEC went fine for a first version, and seemed to be well received.  I'll write more about that in my GUADEC wrapup, but for the people who asked me for the slides - I am going through Flickr withdrawal, I have all the links from where I got the photos and should now figure out if I can actually use them in the presentation or ask for permission if not.  I'll get going on that this week.

While doing various tasks around the house and ripping CD's I have from bands playing at next week's Pukkelpop festival I've been tackling some simple moap bugs so I can...