Monthly Archives: April 2013

My own collection, which includes a healthy mix of CDs and downloaded high resolution audio files is now approaching the 30,000 files mark.  This occupies 1.2TB of disk space for the FLAC master library and 1.4TB for a replicated Apple Lossless library.  I am totally paranoid over the consequence of losing all of this to a HD failure.  I have endured several HD failures in my lifetime, so I know that they happen more often than you would like, and generally without warning.  I don’t want to imaging how much time it would take me to re-rip my CD collection, and re-download all my downloaded music.  I don’t know if that would even be possible!

There are various ways to address this issue.  First, is the obvious one, back it up!  I must confess I don’t like backup utilities much.  They seem to be overly complicated, designed as they are to deal with the myriad complexities of the gamut of computerized data.  I always suspect that when I need to use it, I won’t be able to work it!  Another option is to keep a nice simple copy of everything on another HD somewhere.  The problem is that you get lazy, and you don’t back up as often as you should.  But in general, backing up and copying strategies can be quite successful.

The solution I favour is to put everything on a Networked Attached Storage (NAS) unit.  A NAS is a very powerful device, but can also be very expensive.  There are cheap units at the $200 price point, and expensive units at the $1,000+ price point.  And that’s without any HDs!  The cheap units are more than likely going to be less reliable, and that completely misses the point of using a NAS for storing your audio data.  The most expensive units have a higher level of performance (read/write speeds, ability to connect simultaneously with multiple users with little performance loss, etc) and are aimed mainly at corporate applications.  As usual, the best deal is to be found somewhere in the middle.  I bought a Synology DS401j unit a couple of years ago and it has worked flawlessly for me.  Tim has a similar one.

After you buy your NAS, you have to kit it out with multiple Hard Drives.  Mine takes four 3.5” hard disks.  These disks are then formatted into what is known as a RAID array.  RAID is a scheme whereby the data is distributed across the multiple disks in such a way that if one disc should suddenly fail, then none of your data is lost.  You just replace the failed disk, rebuild the RAID, and you are back again at full operation.  Some NAS units will let you do that without even having to power it down (so-called “hot-swapping”).  There are different “Levels” of RAID, and they all have different characteristics.  Some will even allow more than one disk to fail with no loss of data.  When I started out, I built my NAS with four 500GB HDs, but soon learned my lesson and swapped them out for four 2TB HDs.  Configured in “Synology Hybrid RAID” this gives me 5.8TB of storage, and I can survive the failure of any one HD without losing any data.  As well as my music, I can store a whole load of other mission-critical data on there too.  My NAS is also plugged into a UPS so that if the power fails it can shut itself down gracefully.  The whole shebang sits in a room in the basement, next to the network router, well out of harm’s way.

My paranoia leads me to also be very picky about which model of HD I put in my NAS.  Ordinary consumer grade HDs fail – in my experience – at a rate higher than I feel comfortable exposing myself to.  Therefore I only buy “Enterprise Class” HDs.  These have a much lower failure rate, but, as you might expect, cost a good 50% more.  My own HD of choice has been the Western Digital RE4 family, and I own several of these without having incurred a single failure.  At one time they were in short supply and I had to buy a pair of Seagate Constellation ES 2TB units.  One of these subsequently failed – actually, the Synology warned me of its impending failure before it actually died, and Seagate were happy to replace it under warranty based on the warning alone – and the replacement unit has so far functioned without further incident.

I can attach an external USB drive to my NAS, so I have plugged in a spare 1.5TB external LG unit.  I place a further double-paranoid copy of my FLAC library on there for safe keeping, just in case

If you are keeping tally, that’s about $1,200-$1,500 spent on my file storage system.  6TB of cheap storage capacity will set you back about $600, so that’s an awful lot extra to budget for little more than data security. You may feel differently from me as to whether it is worth it.  But so long as you have taken the time to pause and think it through, then that’s good enough for me.

My own collection, which includes a healthy mix of CDs and downloaded high resolution audio files is now approaching the 30,000 files mark.  This occupies 1.2TB of disk space for the FLAC master library and 1.4TB for a replicated Apple Lossless library.  I am totally paranoid over the consequence of losing all of this to a HD failure.  I have endured several HD failures in my lifetime, so I know that they happen more often than you would like, and generally without warning.  I don’t want to imagine how much time it would take me to re-rip my CD collection, and re-download all my downloaded music.  I don’t know if that would even be possible!

There are various ways to address this issue.  First, is the obvious one, back it up!  I must confess I don’t like backup utilities much.  They seem to be overly complicated, designed as they are to deal with the myriad complexities of the gamut of computerized data.  I always suspect that when I need to use it, I won’t be able to work it!  Another option is to keep a nice simple copy of everything on another HD somewhere.  The problem is that you get lazy, and you don’t back up as often as you should.  But in general, backing up and copying strategies can be quite successful.

The solution I favour is to put everything on a Networked Attached Storage (NAS) unit.  A NAS is a very powerful device, but can also be very expensive.  There are cheap units at the $200 price point, and expensive units at the $1,000+ price point.  And that’s without any HDs!  The cheap units are more than likely going to be less reliable, and that completely misses the point of using a NAS for storing your audio data.  The most expensive units have a higher level of performance (read/write speeds, ability to connect simultaneously with multiple users with little performance loss, etc) and are aimed mainly at corporate applications.  As usual, the best deal is to be found somewhere in the middle.  I bought a Synology DS411j unit a couple of years ago and it has worked flawlessly for me.  Tim has a similar one.

After you buy your NAS, you have to kit it out with multiple Hard Drives.  Mine takes four 3.5” hard disks.  These disks are then formatted into what is known as a RAID array.  RAID is a scheme whereby the data is distributed across the multiple disks in such a way that if one disc should suddenly fail, then none of your data is lost.  You just replace the failed disk, rebuild the RAID, and you are back again at full operation.  Some NAS units will let you do that without even having to power it down (so-called “hot-swapping”).  There are different “Levels” of RAID, and they all have different characteristics.  Some will even allow more than one disk to fail with no loss of data.  When I started out, I built my NAS with four 500GB HDs, but soon learned my lesson and swapped them out for four 2TB HDs.  Configured in “Synology Hybrid RAID” this gives me 5.8TB of storage, and I can survive the failure of any one HD without losing any data.  As well as my music, I can store a whole load of other mission-critical data on there too.  My NAS is also plugged into a UPS so that if the power fails it can shut itself down gracefully.  The whole shebang sits in a room in the basement, next to the network router, well out of harm’s way.

My paranoia leads me to also be very picky about which model of HD I put in my NAS.  Ordinary consumer grade HDs fail – in my experience – at a rate higher than I feel comfortable exposing myself to.  Therefore I only buy “Enterprise Class” HDs.  These have a much lower failure rate, but, as you might expect, cost a good 50% more.  My own HD of choice has been the Western Digital RE4 family, and I own several of these without having incurred a single failure.  At one time they were in short supply and I had to buy a pair of Seagate Constellation ES 2TB units.  One of these subsequently failed – actually, the Synology warned me of its impending failure before it actually died, and Seagate were happy to replace it under warranty based on the warning alone – and the replacement unit has so far functioned without further incident.

I can attach an external USB drive to my NAS, so I have plugged in a spare 1.5TB external LG unit.  I place a further double-paranoid copy of my FLAC library on there for safe keeping, just in case

If you are keeping tally, that’s about $1,200-$1,500 spent on my file storage system.  6TB of cheap storage capacity will set you back about $600, so that’s an awful lot extra to budget for little more than data security. You may feel differently from me as to whether it is worth it.  But so long as you have taken the time to pause and think it through, then that’s good enough for me.

Back to Part IV.
Part VI can be found here.

By now I have laid the groundwork for the things you have had to be thinking about before you start ripping your CDs.  Now its time to look at the ripping process itself.  This is where we remove the audio data from the CD and replace it with a collection of files on your computer.  And the first thing you might be wondering is why that should be any sort of a problem.

The answer is that the music data on a CD is not stored as a nice neat collection of files.  Instead, the data is arranged more like a cassette tape, or an LP record.  It is designed to come off the CD in a continuous stream, and to be more or less played on the fly.  In the same way an LP has visible “gaps” between the tracks to guide you to drop the needle in the right place, so a CD has pointers in a “Table of Contents” to enable the CD player to find places in the stream where one track ends and the next one begins.

When the CD format was first established, the method of reading data off the disc – using a laser to detect the presence of microscopic pits embedded just below the disc’s surface – was truly revolutionary.  I was working in the laser industry at the time, and when the commitment was made to move forward with CD technology, laser technology had not yet produced a laser design that lived nearly long enough to last for the desired lifetime of the player!  That aside, there were two problems that the project’s design goals sought to overcome.  The first was that since the disc was to be read on-the-fly, there was no possibility to go back and read a section again if you got a bad reading first time.  The second was that the discs were going into an uncontrolled consumer environment, and were likely to be subjected to physical damage and deterioration.  Taken together, this meant that the discs had to have – to as great a degree as was practical – the ability to survive a significant loss of data, or significant faults in the accuracy of the data.  It is a tribute to the success of the technologies put in place to address these problems that CD technology today is of archival quality, something which the more advanced DVD technology does not quite match.

So when you rip a CD, one thing that is of prime importance is to be assured that you have ripped it accurately.  Since you are going to rip the CD once (we hope), and thereafter only ever play the ripped tracks, you want to be confident that you ripped it right the first time.  Most reputable CD ripping tools have special capabilities that seek to assure you of this, with ever greater degrees of confidence, but we are not going to lose sight of the fact that this is job #1.  I am going to mention three ripping tools which all have the compelling advantage of being free.  The ubiquitous iTunes for either Mac or Windows platforms; XLD for the Mac platform; and EAC for the Windows platform.  Of the three, I personally use EAC.  I have never made a serious attempt to compare XLD with EAC, and have occasionally used iTunes as well, but I have the most personal experience with EAC.  XLD and iTunes both have the advantage that they can rip and import into iTunes in one step.  I will describe each one, and outline the main options that impact the quality of the resultant rips.

Starting with iTunes, it has one option only “Use error correction when reading Audio CDs”.  Apple doesn’t actually tell us what this means, but it does seem to result in more accurate rips than with it turned off.  It probably invokes a number of re-reads if the data it’s getting looks at all dubious.  Checking this setting does slightly slow down the ripping process, so that makes sense.

XLD is the big daddy of ripping tools for the Mac, and it is 100% free.  It provides a plethora of settings to customize the ripping process to just what you want.  It has three ripping modes – in order of speed they are “Burst”, “XLD secure ripper” and “CD Paranoia”.  These trade ripping speed for progressively more thorough assurance of an accurate rip.  XLD can make use of the AccurateRip database, an on-line resource that cloud-sources data to permit XLD to verify the accuracy of the rip.  It also has the option to test the ripped track before committing it to file as a belt-and-braces check of the final rip.  Ripping a disc in CD Paranoia mode can often take well over half an hour.

EAC has an even more bewildering array of options and customizations, but at least it simplifies the ripping quality choices to “High”, “Medium”, and “Low”.  You should just use “High”.  EAC supports AccurateRip.  There is a good set of instructions from Carlton Bale here, although his graphics show a slightly older version of EAC than the most current one.  I don’t like his entry for Naming Convention – I prefer to use “%tracknr1%-%title%”, but you may prefer otherwise.  Once you have EAC set up, you won’t have to fiddle with the settings again.  EAC is the most thorough ripping tool I know, but its complexity may put you off.

You are going to spend many, many, many hours ripping a sizeable CD collection.  Do yourself a favour and don’t skimp on taking however much time is necessary to get your ripping process properly set up and streamlined before you start cranking the handle.

By now I have laid the groundwork for the things you have had to be thinking about before you start ripping your CDs.  Now its time to look at the ripping process itself.  This is where we remove the audio data from the CD and replace it with a collection of files on your computer.  And the first thing you might be wondering is why that should be any sort of a problem.

The answer is that the music data on a CD is not stored as a nice neat collection of files.  Instead, the data is arranged more like a cassette tape, or an LP record.  It is designed to come off the CD in a continuous stream, and to be more or less played on the fly.  In the same way an LP has visible “gaps” between the tracks to guide you to drop the needle in the right place, so a CD has pointers in a “Table of Contents” to enable the CD player to find places in the stream where one track ends and the next one begins.

When the CD format was first established, the method of reading data off the disc – using a laser to detect the presence of microscopic pits embedded just below the disc’s surface – was truly revolutionary.  I was working in the laser industry at the time, and when the commitment was made to move forward with CD technology, laser technology had not yet produced a laser design that lived nearly long enough to last for the desired lifetime of the player!  That aside, there were two problems that the project’s design goals sought to overcome.  The first was that since the disc was to be read on-the-fly, there was no possibility to go back and read a section again if you got a bad reading first time.  The second was that the discs were going into an uncontrolled consumer environment, and were likely to be subjected to physical damage and deterioration.  Taken together, this meant that the discs had to have – to as great a degree as was practical – the ability to survive a significant loss of data, or significant faults in the accuracy of the data.  It is a tribute to the success of the technologies put in place to address these problems that CD technology today is of archival quality, something which the more advanced DVD technology does not quite match.

So when you rip a CD, one thing that is of prime importance is to be assured that you have ripped it accurately.  Since you are going to rip the CD once (we hope), and thereafter only ever play the ripped tracks, you want to be confident that you ripped it right the first time.  Most reputable CD ripping tools have special capabilities that seek to assure you of this, with ever greater degrees of confidence, but we are not going to lose sight of the fact that this is job #1.  I am going to mention three ripping tools which all have the compelling advantage of being free.  The ubiquitous iTunes for either Mac or Windows platforms; XLD for the Mac platform; and EAC for the Windows platform.  Of the three, I personally use EAC.  I have never made a serious attempt to compare XLD with EAC, and have occasionally used iTunes as well, but I have the most personal experience with EAC.  XLD and iTunes both have the advantage that they can rip and import into iTunes in one step.  I will describe each one, and outline the main options that impact the quality of the resultant rips.

Starting with iTunes, it has one option only “Use error correction when reading Audio CDs”.  Apple doesn’t actually tell us what this means, but it does seem to result in more accurate rips than with it turned off.  It probably invokes a number of re-reads if the data it’s getting looks at all dubious.  Checking this setting does slightly slow down the ripping process, so that makes sense.

XLD is the big daddy of ripping tools for the Mac, and it is 100% free.  It provides a plethora of settings to customize the ripping process to just what you want.  It has three ripping modes – in order of speed they are “Burst”, “XLD secure ripper” and “CD Paranoia”.  These trade ripping speed for progressively more thorough assurance of an accurate rip.  XLD can make use of the AccurateRip database, an on-line resource that cloud-sources data to permit XLD to verify the accuracy of the rip.  It also has the option to test the ripped track before committing it to file as a belt-and-braces check of the final rip.  Ripping a disc in CD Paranoia mode can often take well over half an hour.

EAC has an even more bewildering array of options and customizations, but at least it simplifies the ripping quality choices to “High”, “Medium”, and “Low”.  You should just use “High”.  EAC supports AccurateRip.  There is a good set of instructions from Carlton Bale here, although his graphics show a slightly older version of EAC than the most current one.  I don’t like his entry for Naming Convention – I prefer to use “%tracknr1%-%title%”, but you may prefer otherwise.  Once you have EAC set up, you won’t have to fiddle with the settings again.  EAC is the most thorough ripping tool I know, but its complexity may put you off.

You are going to spend many, many, many hours ripping a sizeable CD collection.  Do yourself a favour and don’t skimp on taking however much time is necessary to get your ripping process properly set up and streamlined before you start cranking the handle.

Back to Part III.
Part V can be found here.

I hope I have managed to get across in my previous posts that the central benefit behind ripping your files and playing from a computer lies in the ability to use the metadata to enhance your playback experience.  What you will be able to do with your music collection will be limited – to a large extent – by the quality of your metadata.  So I want to spend some time on what is often called “metadata grooming” before getting round to the actual process of ripping the CDs and embedding the metadata into the resultant files.

For most users, this will not present too much of a challenge.  The metadata structures, and the way that current software uses it, was pretty much defined back in the nineties by techno-geeks who did the work in order to fill unserviced gaps their own needs.  So, if you listen mostly to rock, pop, and other modern musical genres, you too will probably find that the existing metadata structures meet most, if not all, of your needs.  But if you listen to classical music, you will find that the opposite is true.  For this reason, I will devote a separate post to data grooming for classical music listeners.  This current post considers only the existing mainstream musical needs.

Metadata is just Fields and Content, and how the two match up.  The Fields are the names given to the specific categories of metadata.  Typical Fields are Album, Artist, Title, and so forth.  The Content is what goes in the Field.  So an item of Content which might be “The Rise And Fall Of Ziggy Stardust And The Spiders From Mars” needs to go into a Field called “Album” and not one called “Artist”.  Data Grooming is basically the process of adjusting the Content to make sure it is properly descriptive of the Field, and in a form that will provide the most utility to you when it comes time to use it to browse your music collection.  But don’t worry too much, because most of the time that is going to happen automatically without your having to think about it.

One thing that is very important to grasp is that Apps such as iTunes provide only perfunctory support for the richness that good metadata provides.  Here is an obvious example.  Most Beatles songs were written by Lennon & McCartney.  So what do you enter into the “Composer” Field?  You have several approaches you can take.  First, you can enter “Lennon & McCartney”.  Second, you can enter “John Lennon & Paul McCartney”.  Or, if your name is Paul McCartney, you can write “Paul McCartney & John Lennon”.  So what happens if you want to browse your music collection to find cover versions of Beatles songs?  If you use Column Browser to list the “Composers”, you will find separate entries for all three of those variants, and they will not be adjacent to each other because they get listed in alphabetical order.  You might scroll down to “Lennon & McCartney” and not realize that the other entries exist further up and further down the Composers list.

Data Grooming is the process of finding and correcting these sorts of ambiguities.  And the first step in correcting them is to do your best to make sure they don’t happen in the first place, although if you buy downloaded music you don’t have any control over the metadata which has already been embedded into it.  When you rip your own CDs, you have the opportunity to perform a first pass over the metadata and make sure it conforms to one consistent standard.  Of course, you need to put some thought into what that standard should be.  Whatever you cannot correct at rip (or download) time, you will have to “groom” afterwards.

Think about how you want to use all that metadata.  When you browse through the list of Composers – and believe me that list can quickly grow to be pretty darned big – how do you want all the entries to appear?  Do you want to see “Bob Dylan” or “Dylan, Bob”.  If the former, “Bob Dylan” will be listed between “Bob Crew” and “Bob Feldman”.  If the latter, he will appear between “Dvo?ák, Antonín” and “Earle, Steve”.  It’s all about what makes the most sense to you, and you really need to spend time thinking about it before you start ripping.  But at the same time, you should bear in mind that the most popular nomenclature is “Bob Dylan” and that this will be what is employed in most everything you download, so if you want to standardize on “Dylan, Bob”, you need to be prepared to do a lot of Data Grooming to correct these entries.  Of course, some of you are going to believe it is only right and proper to use “Zimmerman, Robert

Another important aspect to be aware of is that most metadata standards actually support multiple-valued entries.  So we can enter TWO items of Content for the “Composer” in our Beatles collection.  John Lennon” and “Paul McCartney” can appear as two separate entries in the list of composers, and any search for songs written by “John Lennon” (or “Lennon, John”…) will come up with songs he co-wrote with others as well as songs he wrote by himself.  However – big however – you need to be aware that a simple software App such as iTunes does not support multiple value fields.  A Day In The Life” would show up in iTunes as being composed by “John Lennon/Paul McCartney” if the file was in Apple Lossless format, and “John Lennon;Paul McCartney” if the file was in AIFF format, since the two formats specify different delimiters to separate individual content items in a multi-valued field.  (Interestingly, the Apple Lossless specification means that the band AC/DC would be treated as two separate Artists, “AC” and “DC”.  Ha Ha!).

I have focused on Composers here, because it is convenient, but the same applies to Artists.  Take the album “Supernatural”.  This is a Santana album, and so the Album Artist would be “Santana”.  However, each track features a different guest vocalist.  Therefore a good strategy would be, for each track, to enter “Santana” as the Album Artist, and to have multiple values for the Artist field, “Santana” (or “Carlos Santana”, or “Santana, Carlos”, according to your personal preference) together with “Rob Thomas”, etc.  Note that there can be any number of multiple entries.

My view is that multiple value fields are a HUGE benefit.  The fact that iTunes doesn’t handle it properly today is NOT in my view sufficient reason not to take full advantage of it.  If you put it off until such time as Apps improve to support it, you may find the size of the task will have become daunting.

When you use a music player App (such as iTunes) to edit your metadata, one thing you need to be sure about is whether or not the App just updates the metadata within its own internal database, or if it then updates the metadata embedded within the individual files to reflect the changes you made.  It should be your objective to keep the metadata embedded within the files current, because you want the flexibility of being able to move from your existing music player App to any better one that comes along, without leaving your precious groomed metadata behind.  I don’t use iTunes to groom metadata, so I am not 100% sure, but I think it does update the embedded metadata whenever you make an edit to the “Get Info…” page.

My own practice is to use a totally separate App to perform Data Grooming.  That App is MusicBee and it is a free App that runs only on Windows.  I just like the convenience of their user interface.  Plus, I can use it to play music while I’m working!  My process for adding new music to my library is (1) rip or download it on my Windows machine using EAC; (2) groom the metadata on the Windows machine using MusicBee; (3) make an Apple Lossless copy on the Windows machine using dBpoweramp; (4) move everything to my NAS; and (5) import the Apple Lossless files into iTunes.  Again, not for everybody, but it’s what I do.

I hope I have managed to get across in my previous posts that the central benefit behind ripping your files and playing from a computer lies in the ability to use the metadata to enhance your playback experience.  What you will be able to do with your music collection will be limited – to a large extent – by the quality of your metadata.  So I want to spend some time on what is often called “metadata grooming” before getting round to the actual process of ripping the CDs and embedding the metadata into the resultant files.

For most users, this will not present too much of a challenge.  The metadata structures, and the way that current software uses it, was pretty much defined back in the nineties by techno-geeks who did the work in order to fill unserviced gaps their own needs.  So, if you listen mostly to rock, pop, and other modern musical genres, you too will probably find that the existing metadata structures meet most, if not all, of your needs.  But if you listen to classical music, you will find that the opposite is true.  For this reason, I will devote a separate post to data grooming for classical music listeners.  This current post considers only the existing mainstream musical needs.

Metadata is just Fields and Content, and how the two match up.  The Fields are the names given to the specific categories of metadata.  Typical Fields are Album, Artist, Title, and so forth.  The Content is what goes in the Field.  So an item of Content which might be “The Rise And Fall Of Ziggy Stardust And The Spiders From Mars” needs to go into a Field called “Album” and not one called “Artist”.  Data Grooming is basically the process of adjusting the Content to make sure it is properly descriptive of the Field, and in a form that will provide the most utility to you when it comes time to use it to browse your music collection.  But don’t worry too much, because most of the time that is going to happen automatically without your having to think about it.

One thing that is very important to grasp is that Apps such as iTunes provide only perfunctory support for the richness that good metadata provides.  Here is an obvious example.  Most Beatles songs were written by Lennon & McCartney.  So what do you enter into the “Composer” Field?  You have several approaches you can take.  First, you can enter “Lennon & McCartney”.  Second, you can enter “John Lennon & Paul McCartney”.  Or, if your name is Paul McCartney, you can write “Paul McCartney & John Lennon”.  So what happens if you want to browse your music collection to find cover versions of Beatles songs?  If you use Column Browser to list the “Composers”, you will find separate entries for all three of those variants, and they will not be adjacent to each other because they get listed in alphabetical order.  You might scroll down to “Lennon & McCartney” and not realize that the other entries exist further up and further down the Composers list.

Data Grooming is the process of finding and correcting these sorts of ambiguities.  And the first step in correcting them is to do your best to make sure they don’t happen in the first place, although if you buy downloaded music you don’t have any control over the metadata which has already been embedded into it.  When you rip your own CDs, you have the opportunity to perform a first pass over the metadata and make sure it conforms to one consistent standard.  Of course, you need to put some thought into what that standard should be.  Whatever you cannot correct at rip (or download) time, you will have to “groom” afterwards.

Think about how you want to use all that metadata.  When you browse through the list of Composers – and believe me that list can quickly grow to be pretty darned big – how do you want all the entries to appear?  Do you want to see “Bob Dylan” or “Dylan, Bob”.  If the former, “Bob Dylan” will be listed between “Bob Crew” and “Bob Feldman”.  If the latter, he will appear between “Dvo?ák, Antonín” and “Earle, Steve”.  It’s all about what makes the most sense to you, and you really need to spend time thinking about it before you start ripping.  But at the same time, you should bear in mind that the most popular nomenclature is “Bob Dylan” and that this will be what is employed in most everything you download, so if you want to standardize on “Dylan, Bob”, you need to be prepared to do a lot of Data Grooming to correct these entries.  Of course, some of you are going to believe it is only right and proper to use “Zimmerman, Robert

Another important aspect to be aware of is that most metadata standards actually support multiple-valued entries.  So we can enter TWO items of Content for the “Composer” in our Beatles collection.  John Lennon” and “Paul McCartney” can appear as two separate entries in the list of composers, and any search for songs written by “John Lennon” (or “Lennon, John”…) will come up with songs he co-wrote with others as well as songs he wrote by himself.  However – big however – you need to be aware that a simple software App such as iTunes does not support multiple value fields.  A Day In The Life” would show up in iTunes as being composed by “John Lennon/Paul McCartney” if the file was in Apple Lossless format, and “John Lennon;Paul McCartney” if the file was in AIFF format, since the two formats specify different delimiters to separate individual content items in a multi-valued field.  (Interestingly, the Apple Lossless specification means that the band AC/DC would be treated as two separate Artists, “AC” and “DC”.  Ha Ha!).

I have focused on Composers here, because it is convenient, but the same applies to Artists.  Take the album “Supernatural”.  This is a Santana album, and so the Album Artist would be “Santana”.  However, each track features a different guest vocalist.  Therefore a good strategy would be, for each track, to enter “Santana” as the Album Artist, and to have multiple values for the Artist field, “Santana” (or “Carlos Santana”, or “Santana, Carlos”, according to your personal preference) together with “Rob Thomas”, etc.  Note that there can be any number of multiple entries.

My view is that multiple value fields are a HUGE benefit.  The fact that iTunes doesn’t handle it properly today is NOT in my view sufficient reason not to take full advantage of it.  If you put it off until such time as Apps improve to support it, you may find the size of the task will have become daunting.

When you use a music player App (such as iTunes) to edit your metadata, one thing you need to be sure about is whether or not the App just updates the metadata within its own internal database, or if it then updates the metadata embedded within the individual files to reflect the changes you made.  It should be your objective to keep the metadata embedded within the files current, because you want the flexibility of being able to move from your existing music player App to any better one that comes along, without leaving your precious groomed metadata behind.  I don’t use iTunes to groom metadata, so I am not 100% sure, but I think it does update the embedded metadata whenever you make an edit to the “Get Info…” page.

My own practice is to use a totally separate App to perform Data Grooming.  That App is MusicBee and it is a free App that runs only on Windows.  I just like the convenience of their user interface.  Plus, I can use it to play music while I’m working!  My process for adding new music to my library is (1) rip or download it on my Windows machine using EAC; (2) groom the metadata on the Windows machine using MusicBee; (3) make an Apple Lossless copy on the Windows machine using dBpoweramp; (4) move everything to my NAS; and (5) import the Apple Lossless files into iTunes.  Again, not for everybody, but it’s what I do.

Back to Part II.
Part IV can be found here.

The process of extracting the music from a CD and placing it in a set of computer files is called “ripping”.  When you come to rip a CD, the first decision you have to make is which file format you are going to use.  There are several of them.  All of them have both advantages and disadvantages.  It is useful to understand what these are so you can make an informed choice.

The first, and most dramatic distinction is between lossless and lossy files.  This arises because, in order to minimize the amount of hard disk space taken up by your music files, or alternatively to maximize the number of music files you can fit on any given hard disk, you usually want to aim to store your music in the smallest convenient file size.  Much like “zipping” a regular computer file to get it down to a small enough size to attach it to an e-mail message, music files can be “compressed” down to a manageable smaller size.  This compression can be either lossy or lossless.  Lossy compression results in a much smaller file size, but at the cost of some loss in quality.  Generally the more the compression, the smaller the file size and the lower the quality.  The term “lossy” is used because some of the musical data is irretrievably lost in the process and can never be recovered.  I never recommend ripping a CD to a lossy format unless you are very clear in your mind that you really want/need smaller file sizes and are prepared to accept compromised sound quality to get it, and that if you ever change your mind about that you will have to rip all of your CDs over again.

Lossless file formats store the music data in such a way that all of the music data that was on the original CD can be precisely recreated during playback, bit for bit, each and every time.  This can be done either with or without compression.  The music data on a CD comprises 16 bits (2 Bytes) of data, per channel, 44,100 times per second.  So every second of music requires 176.4kB of disk space.  Lossless compression techniques can reduce this disk space requirement.  The amount of compression that can be achieved will vary depending on the musical content.  Some tracks will compress more than others.  But a rough guideline is that a lossless compressed file will use about one-half to two-thirds of the disk space compared to an uncompressed file.  This allows you to make a rough estimate of how much disk space you will need to store your entire collection.  Another (very) rough guideline is to allow for 200-300MB per CD (if compressed) for rock and jazz, and 300-400MB per CD (if compressed) for classical.  YMMV.

There are two major uncompressed formats in use today, WAV and AIFF.  Both are, to all intent and purpose, identical.  The differences are marginal.  The former was developed by Microsoft for use on Windows machines, and the latter by Apple for use on Macs.  In reality, there is nothing to stop a Mac from reading a WAV file and vice-versa.  It is just a question of whether or not the software you are running supports that file format.

There are also two major lossless compressed formats in use today, FLAC and Apple Lossless (also called ALAC, and sometimes ALE).  FLAC is an open-source format which has become widely adopted, and is now very close to being the de facto industry standard.  The latest version of the FLAC spec also includes an “uncompressed” option.  Apple Lossless, on the other hand, was developed by Apple for use with iTunes.  It was originally a private format, but has now been thoroughly hacked so third party software can support it.  But Apple has still not published a specification, and some minor incompatibility issues still surface from time to time.  It has no real use other than with iTunes, and lives on only because Apple still refuses to support the FLAC standard.  Apple Lossless files usually have the extension “.m4a”.

The two major lossy compression formats are MP3 (used everywhere – even in iTunes) and AAC (used only within iTunes).  I am not going to discuss lossy formats any further.  As they say at Ruth’s Chris Steak House, “customers wishing to order their steaks well done are invited to dine elsewhere”.

You will read in some places that music stored under various different lossless file formats actually sounds different.  This appears to stretch credibility somewhat.  Let me state for the record that if you are using BitPerfect there is absolutely no possibility of this happening.  At the start of playback, the file is opened, read and decoded, and loaded into memory.  This process normally takes less than five seconds, (but can be longer for some higher resolution music tracks).  Once this five seconds is over, then the precise same data will reside in the precise same memory location, regardless of what the file format is.  For the remainder of playback there is no possible mechanism by which the file format can influence the sound quality.  Arguably, if you use different software to play back the music, and the music is streamed from disk and not from memory, then the slight differences in specific disk and CPU activity needed to access the different file formats could conceivably be reflected in the resultant sound quality.  I have never personally heard any differences, though.

It is really important to understand that the different file formats store their metadata in different ways.  WAV files, for example, normally the first format that springs to people’s minds once they have dismissed MP3, only supports a very limited number of metadata fields – few enough to be a serious strike against it in my view.  Some people modify the WAV format to include metadata in the ID3 format, which is a comprehensive metadata standard.  Unfortunately, this results in non-standard WAV files which your choice of playback software may have trouble reading.  Apple’s AIFF format supports ID3 out of the box, but Apple Lossless supports the Quicktime metadata format, a symptom of its “Apple proprietary” origins.  FLAC supports a comprehensive metadata format called Vorbis Comments, which are flexible and easy to read and write, but the standards that define what the fields should be and what should go in them are very lax indeed.  This is both an advantage (since you can define whatever metadata implementation you want) and a disadvantage (since the software that reads the metadata may not interpret it in the same way as the software that wrote it).  Having said that, this is only a problem if you want to store “extended” metadata that goes beyond the commonly implemented “standard” fields, in which case there are no existing standards that you can adhere to anyway, regardless of whatever file/metadata format you may choose.

Since having good metadata is in my view the principle raison d’etre for moving to computer audio in the first place, this argues against using WAV files.  FLAC has become the de facto standard for lossless downloaded music, but the big strike against FLAC is that you cannot load FLAC files into iTunes.  So you cannot use FLAC with BitPerfect (for the moment).  AIFF and Apple Lossless appear to sound like good bets, but in reality there is little beyond perfunctory support for these formats outside of the Apple ecosystem.  If you choose one of those you may be locked into Apple.

Please read the previous paragraph again.  There are no simple answers to the conundrum posed by it.

My own approach is not for everybody.  I use FLAC for my reference library.  All my music is tagged and catalogued in FLAC, but I cannot load these files into iTunes for playback using BitPerfect.  Most of the music I download is only available in FLAC format.  FLAC is just too mainstream to ignore, and it is not going anywhere.  I couldn’t say that with any real conviction for any other format.  So right now I maintain a parallel music library in Apple Lossless (transcoded from FLAC using dBpoweramp, a Windows App) which I use to load the music into iTunes.  Sure, that’s wasteful on disk space, but right now it is the best approach for me.


The process of extracting the music from a CD and placing it in a set of computer files is called “ripping”.  When you come to rip a CD, the first decision you have to make is which file format you are going to use.  There are several of them.  All of them have both advantages and disadvantages.  It is useful to understand what these are so you can make an informed choice.

The first, and most dramatic distinction is between lossless and lossy files.  This arises because, in order to minimize the amount of hard disk space taken up by your music files, or alternatively to maximize the number of music files you can fit on any given hard disk, you usually want to aim to store your music in the smallest convenient file size.  Much like “zipping” a regular computer file to get it down to a small enough size to attach it to an e-mail message, music files can be “compressed” down to a manageable smaller size.  This compression can be either lossy or lossless.  Lossy compression results in a much smaller file size, but at the cost of some loss in quality.  Generally the more the compression, the smaller the file size and the lower the quality.  The term “lossy” is used because some of the musical data is irretrievably lost in the process and can never be recovered.  I never recommend ripping a CD to a lossy format unless you are very clear in your mind that you really want/need smaller file sizes and are prepared to accept compromised sound quality to get it, and that if you ever change your mind about that you will have to rip all of your CDs over again.

Lossless file formats store the music data in such a way that all of the music data that was on the original CD can be precisely recreated during playback, bit for bit, each and every time.  This can be done either with or without compression.  The music data on a CD comprises 16 bits (2 Bytes) of data, per channel, 44,100 times per second.  So every second of music requires 176.4kB of disk space.  Lossless compression techniques can reduce this disk space requirement.  The amount of compression that can be achieved will vary depending on the musical content.  Some tracks will compress more than others.  But a rough guideline is that a lossless compressed file will use about one-half to two-thirds of the disk space compared to an uncompressed file.  This allows you to make a rough estimate of how much disk space you will need to store your entire collection.  Another (very) rough guideline is to allow for 200-300MB per CD (if compressed) for rock and jazz, and 300-400MB per CD (if compressed) for classical.  YMMV.

There are two major uncompressed formats in use today, WAV and AIFF.  Both are, to all intent and purpose, identical.  The differences are marginal.  The former was developed by Microsoft for use on Windows machines, and the latter by Apple for use on Macs.  In reality, there is nothing to stop a Mac from reading a WAV file and vice-versa.  It is just a question of whether or not the software you are running supports that file format.

There are also two major lossless compressed formats in use today, FLAC and Apple Lossless (also called ALAC, and sometimes ALE).  FLAC is an open-source format which has become widely adopted, and is now very close to being the de facto industry standard.  The latest version of the FLAC spec also includes an “uncompressed” option.  Apple Lossless, on the other hand, was developed by Apple for use with iTunes.  It was originally a private format, but has now been thoroughly hacked so third party software can support it.  But Apple has still not published a specification, and some minor incompatibility issues still surface from time to time.  It has no real use other than with iTunes, and lives on only because Apple still refuses to support the FLAC standard.  Apple Lossless files usually have the extension “.m4a”.

The two major lossy compression formats are MP3 (used everywhere – even in iTunes) and AAC (used only within iTunes).  I am not going to discuss lossy formats any further.  As they say at Ruth’s Chris Steak House, “customers wishing to order their steaks well done are invited to dine elsewhere”.

You will read in some places that music stored under various different lossless file formats actually sounds different.  This appears to stretch credibility somewhat.  Let me state for the record that if you are using BitPerfect there is absolutely no possibility of this happening.  At the start of playback, the file is opened, read and decoded, and loaded into memory.  This process normally takes less than five seconds, (but can be longer for some higher resolution music tracks).  Once this five seconds is over, then the precise same data will reside in the precise same memory location, regardless of what the file format is.  For the remainder of playback there is no possible mechanism by which the file format can influence the sound quality.  Arguably, if you use different software to play back the music, and the music is streamed from disk and not from memory, then the slight differences in specific disk and CPU activity needed to access the different file formats could conceivably be reflected in the resultant sound quality.  I have never personally heard any differences, though.

It is really important to understand that the different file formats store their metadata in different ways.  WAV files, for example, normally the first format that springs to people’s minds once they have dismissed MP3, only supports a very limited number of metadata fields – few enough to be a serious strike against it in my view.  Some people modify the WAV format to include metadata in the ID3 format, which is a comprehensive metadata standard.  Unfortunately, this results in non-standard WAV files which your choice of playback software may have trouble reading.  Apple’s AIFF format supports ID3 out of the box, but Apple Lossless supports the Quicktime metadata format, a symptom of its “Apple proprietary” origins.  FLAC supports a comprehensive metadata format called Vorbis Comments, which are flexible and easy to read and write, but the standards that define what the fields should be and what should go in them are very lax indeed.  This is both an advantage (since you can define whatever metadata implementation you want) and a disadvantage (since the software that reads the metadata may not interpret it in the same way as the software that wrote it).  Having said that, this is only a problem if you want to store “extended” metadata that goes beyond the commonly implemented “standard” fields, in which case there are no existing standards that you can adhere to anyway, regardless of whatever file/metadata format you may choose.

Since having good metadata is in my view the principle raison d’etre for moving to computer audio in the first place, this argues against using WAV files.  FLAC has become the de facto standard for lossless downloaded music, but the big strike against FLAC is that you cannot load FLAC files into iTunes.  So you cannot use FLAC with BitPerfect (for the moment).  AIFF and Apple Lossless appear to sound like good bets, but in reality there is little beyond perfunctory support for these formats outside of the Apple ecosystem.  If you choose one of those you may be locked into Apple.

Please read the previous paragraph again.  There are no simple answers to the conundrum posed by it.

My own approach is not for everybody.  I use FLAC for my reference library.  All my music is tagged and catalogued in FLAC, but I cannot load these files into iTunes for playback using BitPerfect.  Most of the music I download is only available in FLAC format.  FLAC is just too mainstream to ignore, and it is not going anywhere.  I couldn’t say that with any real conviction for any other format.  So right now I maintain a parallel music library in Apple Lossless (transcoded from FLAC using dBpoweramp, a Windows App) which I use to load the music into iTunes.  Sure, that’s wasteful on disk space, but right now it is the best approach for me.

Back to Part I.
Part III can be found here.


It happens quite often.  People mention to me that they have started the process of ripping their CD collections to WAV files so they can start to play them through their computers.  And they haven’t paused to think it through before they start.  This is definitely an area where “look before you leap” or “an ounce of prevention is worth a pound of cure” can be held to apply.  Maybe I can help.

This is the first in a series of posts where I will talk about the real-world issues you will encounter when you take the plunge and commit to ripping your CD collection.  This mostly introductory post addresses the main predicament we face, and how we arrived to this juncture in the first place.

Part I    Metadata

I can’t think of anybody who has successfully made the transition from CDs to computer-based audio, and abandoned it to go back to CDs.  Once your music collection is safely tucked away on Hard Disk, the ability to navigate through it, to prepare playlists and collections, to browse intelligently – even to control it remotely using a mobile device such as an iPad or an iPhone – massively enriches the experience.  Even with a relatively mundane piece of software such as iTunes.  And serious high-end products such as Sooloos elevate the user experience much closer to the incredible possibilities that the brave new world of computer audio opens up for us.

My good friend ‘Richard H’ has something approaching 3,000 CDs in his collection.  They live in a selection of shelving units and cupboards that dot his listening room.  Richard knows pretty much where most of his CDs live, but occasionally some are hard to track down.  (Particularly if I’m the person who last put it away…)  Extracting full value from that collection involves not only knowing exactly where every disk sits, but also having a good memory for what tracks are on every one of those disks.  I’m sure many of you will identify with that.  But it is at least manageable.  Its what we’ve all gotten used to.

On the other hand, my sister Barbara works for a NPR radio station, WKSU, which is one of the biggest classical music stations in the world.  Their music collection comprises MANY THOUSANDS of disks, and their ability to function as a station relies to a great degree on the people who work there knowing how to find every last piece of music they own.  It is a nightmare of a task, and I have no idea how they manage that, but it seems they do it very effectively!  The thing is, with classical music, how do you organize a library of thousands of CDs with the sole assistance of a BIG shelving unit?  Do you do it by composer, by musical style, by period, by performer, by record label … or do you just stack ’em up one by one in the order you bought ’em?  There is no natural solution.  Particularly since, with classical music, a single CD can contain works by different composers, in different musical styles, of different periods, by different performers, and so forth.

But once you rip that library into computer files, there is an immediate, and very natural solution.  All that information is just data, and computers handle data very, very well.  The challenge, then, is to get all that valuable data off the discs and into the computer.  And that is where the problems start.  Because the data isn’t on the discs in the first place.

All of the information that is relevant to the music on an audio disc is termed “metadata”.  Most of it is printed on the jewel case artwork, or in the enclosed booklet, but none of it is encoded on the disc itself.  Back when the format of the CD was devised, more than 30 years ago, the concept did not exist of wanting to read that information from the disc, and so nobody thought to standardize any method for putting it on there.  Finally, in the mid-1990’s, when a standard did emerge for combining audio and data onto the same disc, there was no interest – let alone any sort of agreement – in establishing a standard format for doing so.  So it never happened.

What did happen was what always happens when a stubborn industry fails to meet the needs of their customers.  The geeks step in and engineer a solution of their own.  In this case it was called MP3.  Techies realized that they could play their music on their computers, if only they could get their music in there in the first place.  The trouble was, music files were so darned HUGE that you couldn’t fit many on the size of hard drives that were available at the time.  It is easy to forget that way back then the capacity of a CD exceeded the capacity of most computer hard drives!  You had to do something to get the size of the files down.  That something was the MP3 format.

So it soon became possible to collect a fair-sized number of music files on your computer and play them using some custom software.  Of course, if you wanted to be able to properly manage the new music collection on your computer – or even just identify which tracks were which – you wanted access to some of that “metadata” that I described.  So the next thing the geeks developed was the ID3 “metadata” tagging system, which was a way to embed metadata into the same files that contained the music.  MP3 became a file format that would store not only the music, but also all of the information that describes the music.  It was a revolutionary development, to which the music industry responded with various enlightened practices including refusing to accept it, pretending it didn’t exist, and trying to ban it.

With the record industry standing off to one side with its head in the sand, the next thing the geeks did was to come up with huge on-line databases which “cloud-sourced” (as we would describe the activity today) all of this metadata, together with some very clever information that individual users could use to interact with it.  Using these on-line resources, you could insert a CD into your computer, some clever software would analyze the CD, correctly identify it, locate all of its metadata, and – Bingo! – automatically insert it into the resultant audio files as part of the ripping process.

The “end of the beginning” (if I may channel Churchill) came when the hard disk industry started manufacturing drives big enough to hold the contents of a large numbers of CDs, and in response the geeks started developing alternative formats to MP3 which could store the music in a lossless form – the FLAC file format is by far the most popular – thereby preserving intact all of the musical information.  These new formats would also support the new high definition audio standards that were emerging at the same time.

Thus, with the support of an enthusiastic, geek-driven, audio hardware industry, the computer-based audio paradigm reached its first level of practical maturity.  The record industry at first refused staunchly to participate, and now that they are finally getting on board with downloading as a legitimate mainstream sales & marketing channel, they can no longer hope to control its de facto standards, which continue to evolve pretty much independently, for better or for worse.  Which is why we need a set of posts like this one – and the rest in this short series – to guide you through the perils of ripping a large collection.  Because it can be quite a frustrating business, and can take up an awful lot of your time.

It happens quite often.  People mention to me that they have started the process of ripping their CD collections to WAV files so they can start to play them through their computers.  And they haven’t paused to think it through before they start.  This is definitely an area where “look before you leap” or “an ounce of prevention is worth a pound of cure” can be held to apply.  Maybe I can help.

This is the first in a series of posts where I will talk about the real-world issues you will encounter when you take the plunge and commit to ripping your CD collection.  This mostly introductory post addresses the main predicament we face, and how we arrived to this juncture in the first place.

Part I    Metadata

I can’t think of anybody who has successfully made the transition from CDs to computer-based audio, and abandoned it to go back to CDs.  Once your music collection is safely tucked away on Hard Disk, the ability to navigate through it, to prepare playlists and collections, to browse intelligently – even to control it remotely using a mobile device such as an iPad or an iPhone – massively enriches the experience.  Even with a relatively mundane piece of software such as iTunes.  And serious high-end products such as Sooloos elevate the user experience much closer to the incredible possibilities that the brave new world of computer audio opens up for us.

My good friend ‘Richard H’ has something approaching 3,000 CDs in his collection.  They live in a selection of shelving units and cupboards that dot his listening room.  Richard knows pretty much where most of his CDs live, but occasionally some are hard to track down.  (Particularly if I’m the person who last put it away…)  Extracting full value from that collection involves not only knowing exactly where every disk sits, but also having a good memory for what tracks are on every one of those disks.  I’m sure many of you will identify with that.  But it is at least manageable.  Its what we’ve all gotten used to.

On the other hand, my sister Barbara works for a NPR radio station, WKSU, which is one of the biggest classical music stations in the world.  Their music collection comprises MANY THOUSANDS of disks, and their ability to function as a station relies to a great degree on the people who work there knowing how to find every last piece of music they own.  It is a nightmare of a task, and I have no idea how they manage that, but it seems they do it very effectively!  The thing is, with classical music, how do you organize a library of thousands of CDs with the sole assistance of a BIG shelving unit?  Do you do it by composer, by musical style, by period, by performer, by record label … or do you just stack ’em up one by one in the order you bought ’em?  There is no natural solution.  Particularly since, with classical music, a single CD can contain works by different composers, in different musical styles, of different periods, by different performers, and so forth.

But once you rip that library into computer files, there is an immediate, and very natural solution.  All that information is just data, and computers handle data very, very well.  The challenge, then, is to get all that valuable data off the discs and into the computer.  And that is where the problems start.  Because the data isn’t on the discs in the first place.

All of the information that is relevant to the music on an audio disc is termed “metadata”.  Most of it is printed on the jewel case artwork, or in the enclosed booklet, but none of it is encoded on the disc itself.  Back when the format of the CD was devised, more than 30 years ago, the concept did not exist of wanting to read that information from the disc, and so nobody thought to standardize any method for putting it on there.  Finally, in the mid-1990’s, when a standard did emerge for combining audio and data onto the same disc, there was no interest – let alone any sort of agreement – in establishing a standard format for doing so.  So it never happened.

What did happen was what always happens when a stubborn industry fails to meet the needs of their customers.  The geeks step in and engineer a solution of their own.  In this case it was called MP3.  Techies realized that they could play their music on their computers, if only they could get their music in there in the first place.  The trouble was, music files were so darned HUGE that you couldn’t fit many on the size of hard drives that were available at the time.  It is easy to forget that way back then the capacity of a CD exceeded the capacity of most computer hard drives!  You had to do something to get the size of the files down.  That something was the MP3 format.

So it soon became possible to collect a fair-sized number of music files on your computer and play them using some custom software.  Of course, if you wanted to be able to properly manage the new music collection on your computer – or even just identify which tracks were which – you wanted access to some of that “metadata” that I described.  So the next thing the geeks developed was the ID3 “metadata” tagging system, which was a way to embed metadata into the same files that contained the music.  MP3 became a file format that would store not only the music, but also all of the information that describes the music.  It was a revolutionary development, to which the music industry responded with various enlightened practices including refusing to accept it, pretending it didn’t exist, and trying to ban it.

With the record industry standing off to one side with its head in the sand, the next thing the geeks did was to come up with huge on-line databases which “cloud-sourced” (as we would describe the activity today) all of this metadata, together with some very clever information that individual users could use to interact with it.  Using these on-line resources, you could insert a CD into your computer, some clever software would analyze the CD, correctly identify it, locate all of its metadata, and – Bingo! – automatically insert it into the resultant audio files as part of the ripping process.

The “end of the beginning” (if I may channel Churchill) came when the hard disk industry started manufacturing drives big enough to hold the contents of a large numbers of CDs, and in response the geeks started developing alternative formats to MP3 which could store the music in a lossless form – the FLAC file format is by far the most popular – thereby preserving intact all of the musical information.  These new formats would also support the new high definition audio standards that were emerging at the same time.

Thus, with the support of an enthusiastic, geek-driven, audio hardware industry, the computer-based audio paradigm reached its first level of practical maturity.  The record industry at first refused staunchly to participate, and now that they are finally getting on board with downloading as a legitimate mainstream sales & marketing channel, they can no longer hope to control its de facto standards, which continue to evolve pretty much independently, for better or for worse.  Which is why we need a set of posts like this one – and the rest in this short series – to guide you through the perils of ripping a large collection.  Because it can be quite a frustrating business, and can take up an awful lot of your time.

Part II can be found here.