[RipVanW]

I'm getting ready to rip over 400 CDs to build a digital archive of my music.  I've ripped a few of them over the years to listen to on my Sansa during airplane flights, but never the entire collection.  It's going to take a lot of time, so I want to make sure there's nothing new out there that I'm not aware of, and that my process is efficient.  So... a few questions:

.flac vs .wav?
Given that:

• TB drives are cheap
• Gbps Ethernet is commonplace
• .flac is computationally more expensive than .wav for decoding
• some (granted, fewer than in the past) players may have problems with .flac files

Is there still a compelling reason to rip to .flac?  A back-of-the-envelope calculation on 400 CDs at 650MB/CD (which should be high) results in 260 GB, which is just over a quarter of a $50 1TB drive.  Even if I include a hundred vinyl albums and growth of another 200 CDs, that still tops out at 455 GB, or effectively $50 worth of storage if I mirror the drives.  Is there another reason I'm not seeing that I should consider .flac?


EAC vs <something else>
Back when I first downloaded Ver 1.0 Beta 2 in 2011, it was arguably the best (as I recall, certainly the most popular) program where you could rip a CD, complete with .cue files, and be able to burn an exact copy of the CD later.  I have it and am familiar with it, but is the latest iteration of EAC still the best out there for that purpose, and with those capabilities?


I realize that like anything else audio-related, there will probably be varying opinions and I'm ok with that, but what are your thoughts?  Anything I'm missing?

Rip (a username which, ironically, isn't meant to have any relationship to the topic at hand  )

[WGH]

Anything I'm missing?

• Servers and computers are fast enough that the computationally difference between playing a wav or flac is basically nil.
• .flac is just a wrapper like a zip file. Back in the early digital days music servers had to try to unpack a .flac and play it back on the fly which sometimes sounded different. These days all players have "memory playblack", each song is unpacked into a wav and played from memory so you are always listening to a wav file. The next song is unpacked while the first song is playing with no hit to sound quality.
• I haven't used EAC in years, dBpoweramp is much easier, more powerful, and a fast way to convert wav to flac and other compression formats.

And the most important

• .wav files do not natively support metadata like album name, cover artwork, song title, artist, etc. I read there are work arounds but why bother when flac works so well?
• Load an album ripped to wav into JRiver Media Center and all it shows is a generic icon, not very helpful when trying to find an album by looking for the cover.

JRiver Media Center MC29 has a new feature called Spotlight that uses metadata to collect more information about the artist and album similar to Roon.

Spotlight -- Rich Metadata
MC29 has a new page that brings you rich information about whatever audio you're playing.  Click on the icon and you'll see a list of their albums, artists who are related, and their bio.  Click on an album and get the list of tracks and a way to play them.

Spotlight retrieves data from Google for the artist images, albums, and related artists.  It uses Wikipedia for the About section.  A link to the donation page at Wikipedia is included.

[speltz]

I’ve been ripping to .aiff lately. I doubt there’s any improvement over .flac, for the reasons WGH sets out, but I don’t see why I would unnecessarily introduce another step (decoding) during playback.

And .aiff supports metadata, so I prefer it to .wav.

[Mag]

   I ripped my favorites to wav, using Thumb Drives. But I can see the advantage of Flac for the reasons mentioned. I have a whole pile of Thumb Drives various sizes my main Stick is 230 GB. Which I can then add to my Amazon HD music playlists by usb port.
  The rest of my collection, couple hundred cd's but not my favorites are stored in binders. When I did ripping cd-r brand was important in getting a good quality rip and fewer duds. With brands still available I haven't encountered some of the problems I had using cheap cd-r.
   I did not like using DBpoweramp as it introduced random glitches into a rip so I switched to Nero with no problems. Nero though is not easy to use like it use to be. I got the latest update but don't like how they changed the user interface.
  And one more thing is I ripped using Jitter reduction which is a slower rip, takes considerably longer. If you listen carefully you will notice the difference in sound as opposed to a fast rip. Jitter Reduction butts the sector ends whereas as a fast rip overlaps sector ends.

[Yog Sothoth]

I'm getting ready to rip over 400 CDs to build a digital archive of my music.  I've ripped a few of them over the years to listen to on my Sansa during airplane flights, but never the entire collection.  It's going to take a lot of time, so I want to make sure there's nothing new out there that I'm not aware of, and that my process is efficient.  So... a few questions:

.flac vs .wav?
Given that:

• TB drives are cheap
• Gbps Ethernet is commonplace
• .flac is computationally more expensive than .wav for decoding
• some (granted, fewer than in the past) players may have problems with .flac files

Is there still a compelling reason to rip to .flac?  A back-of-the-envelope calculation on 400 CDs at 650MB/CD (which should be high) results in 260 GB, which is just over a quarter of a $50 1TB drive.  Even if I include a hundred vinyl albums and growth of another 200 CDs, that still tops out at 455 GB, or effectively $50 worth of storage if I mirror the drives.  Is there another reason I'm not seeing that I should consider .flac?

That is going to take a LOT of time, so provisioning for backups with mirrors is a wise plan!

I recently did the same thing as you're proposing with about 500 CDs and decided to keep not only a backup live at home (on a small RAID), but also on a NUC I placed at a friend's house.  I backup to it across the Internet nightly using rsync to ensure it's always up to date. I also run a weekly scrub on the RAID and the NUC to look for bad data.  I sleep much more soundly at night.

[WGH]

All my ripped CD's are in a box waiting for whoever cleans out my house when I'm gone to put at the curb along with all my expensive cables.

FLAC backups are on spare IDE HDDs, after 20 years I have a lifetime supply of old but serviceable IDE drives that I use in a external USB case. When one is filled up with music I pop in another. Since the USB dock is always unplugged and disconnected there is no risk of lightning, power surges, etc. scrambling the data. My current Asus motherboard doesn't even have any IDE connections.

[RipVanW]

• Servers and computers are fast enough that the computationally difference between playing a wav or flac is basically nil.
• .flac is just a wrapper like a zip file. Back in the early digital days music servers had to try to unpack a .flac and play it back on the fly which sometimes sounded different. These days all players have "memory playblack", each song is unpacked into a wav and played from memory so you are always listening to a wav file. The next song is unpacked while the first song is playing with no hit to sound quality.

No arguments on the (lack of) computational hit given today's processors.  What I said was true, but as you pointed out, in practice in 2022 it doesn't matter.

I wasn't aware that players these days unpacked the compressed files to memory before needing them.  That's interesting.

And the most important

• .wav files do not natively support metadata like album name, cover artwork, song title, artist, etc. I read there are work arounds but why bother when flac works so well?
• Load an album ripped to wav into JRiver Media Center and all it shows is a generic icon, not very helpful when trying to find an album by looking for the cover.

At first I was like, "Yeah, that makes a lot of sense.  Flac it is!"  But then I got to thinking... "That doesn't match my experience...".

Not long ago I packaged up some locally-recorded music for distribution to the players and for my own archives, and used Mp3tag to insert metadata (composer, title, etc).  I distributed it as .mp3 for the average folks who don't care about such things, but kept the .wavs for myself.  I had no problem saving metadata in the .wav file.  I tried it again tonight with a commercial CD  True, while EAC was able to pull the titles and such from gnudb, it didn't write the metadata to the .wav files.  However, when I imported those .wav files into Mp3tag, I was able to pull metadata from gnudb and write it into the .wav files.  I scanned the cover art, and it went in fine as well.  See below when playing back that folder in foobar2k:



Granted it was a two-step process using both EAC and Mp3tag, but I had no problem inserting the metadata and cover art into the .wav file.  Perhaps JRiver doesn't understand metadata in .wav files.  I haven't used that program yet so I can't say.  However, my experience with .wavs and metadata does seem to contradict yours...?

[RipVanW]

I’ve been ripping to .aiff lately. I doubt there’s any improvement over .flac, for the reasons WGH sets out, but I don’t see why I would unnecessarily introduce another step (decoding) during playback.

And .aiff supports metadata, so I prefer it to .wav.

I haven't used .aiff before, probably because it originated with the Apple Mac and I haven't been an Apple person since the ][e days.  I did some research and it looks more or less like a PCM wrapper with the ability to include various forms of non-audio data (such as metadata, including IDv3).  It looks interesting.  Even though the .wav files did allow me to put metadata in them, I may look into this instead, if the .wav's are problematic with some software.

I haven't used EAC in years, dBpoweramp is much easier, more powerful, and a fast way to convert wav to flac and other compression formats.

I did not like using DBpoweramp as it introduced random glitches into a rip so I switched to Nero with no problems. Nero though is not easy to use like it use to be. I got the latest update but don't like how they changed the user interface.

Ah, consensus...     Updating to a new program doesn't bother me, but when I hear about glitches in rips, I start to get nervous.  I checked the program out and it has a good pedigree and says that it uses (and invented, it says) AccurateRip, so...  what sort of glitches were you seeing?  How could they not have gotten caught with the AccurateRip cross-check?

And one more thing is I ripped using Jitter reduction which is a slower rip, takes considerably longer. If you listen carefully you will notice the difference in sound as opposed to a fast rip. Jitter Reduction butts the sector ends whereas as a fast rip overlaps sector ends.

I don't mind a slower rip if it's more accurate and stable.  Yeah, it's going to take longer, but I'd rather do it once than twice, or find out there were problems later.  I'm a happy tortoise... 

That is going to take a LOT of time, so provisioning for backups with mirrors is a wise plan!

I recently did the same thing as you're proposing with about 500 CDs and decided to keep not only a backup live at home (on a small RAID), but also on a NUC I placed at a friend's house.  I backup to it across the Internet nightly using rsync to ensure it's always up to date. I also run a weekly scrub on the RAID and the NUC to look for bad data.  I sleep much more soundly at night.

I completely agree.  I'll probably start on a PC with a single HDD just to get the process rolling, but before the year's out I'm hoping to work up to a dedicated NAS with mirrored raid, and periodically back that up to a USB or SATA HDD that gets kept in the safety deposit box.  No, it won't be a daily backup like what you're talking about, but the bulk of my collection is static so it shouldn't matter.

[rbbert]

dBPoweramp in Secure mode ripping will use AccurateRip, so it is hard to see how there can be ripping errors.  It tags WAV files pretty well if that is how you decide to go.

There may be differences in playback software; most careful listeners find the latest build of Roon to sound better than JRiver, as well as preferring its integration of all your music (Jriver does offer integration of video and other media, if that is important to you).  HQPlayer and Euphony Stylus are 2 other options with adherents; either can be used with Roon for its cataloging and streaming integration..

The FLAC vs. WAV vs. AIFF debate will continue into the indefinite future.  Ripping to FLAC now you can always easily convert to either of the other formats later (using dBPoweramp batch file convertor), or vice-versa.  As noted, though, most of the music players (all those mentioned) now allow you to load multiple files as uncompressed PCM (or DSD) into memory prior to play.

[Yog Sothoth]

I completely agree.  I'll probably start on a PC with a single HDD just to get the process rolling, but before the year's out I'm hoping to work up to a dedicated NAS with mirrored raid, and periodically back that up to a USB or SATA HDD that gets kept in the safety deposit box.  No, it won't be a daily backup like what you're talking about, but the bulk of my collection is static so it shouldn't matter.

Sorry, I should perhaps have been more detailed.  The nightly backup only syncs changes in the main library, so if there are no changes, then nothing happens.  But if there are changes, the backups all happen automatically (both to the local RAID system as well as to the remote NUC).  The RAID system is actually another NUC (or something like it) running a 4-way mirror.  It serves as a backup server for more than just the music library, so the extra redundancy gives me peace of mind.  Until the earthquake comes.

In fact, I just notice yesterday that one of its drives has failed.  I've been slowly replacing them with SSDs, so time to buy another!  If I had sufficient I/O ports I'd dedicate a hot spare.

For ripping I generally use either Grip or KDE.  I set cdparanoia to its maximum so it will keep reading until it can get a copy without errors; with a damaged CD it can take many hours.  Thankfully there were only a couple of CDs that were difficult to read!

[Mike B.]

Everything I convert is done using WAV and dbpoweramp. Memory is cheap. I do have some FLAC files I have downloaded off the net.
When I ripped my CD collection I set up a stand alone system. Laptop, separate dvd drive. dbpoweramp will open the drive tray when the rip is finished. It does add cover art, individual track titles and run time (Meta data). The tray being open at the end allowed me to quickly know when the rip was done.
I do several tweaks during the process. 

[Saturn94]

I’ve been using dBPoweramp for many years and haven’t experienced any glitches (I’ve ripped about 800 CDs).  I rip to FLAC as most anything will play it, it’s lossless and easily converted to another format if desired using dBPoweramp (I convert to mp3 for my phone), it sounds just as good as the original CD, and it handles metadata very well.  Also, being an open sourced format, I don’t believe it’s going anywhere in the foreseeable future.

Many years ago when I first ripped my CDs to add to my portable player, I ripped to WMA, thinking a format from a company as big as Microsoft would be the most widely accepted.  Long story short, I was wrong and re-ripped my entire CD collection to FLAC and haven’t had any issues since.

At the time I ripped my CD collection to FLAC, most things I read mentioned WAV not handling metadata natively, hence why I chose not to rip to WAV.

[Digi-G]

I'll just reiterate what a few others have already stated.

FLAC works best for me.  I used WAV for many years but decided I wanted to add artwork, and then metadata.  I just couldn't get WAV to work, not consistently.  FLAC made that much easier.  The files compress a bit more too, so they have a smaller footprint.

MP3TAG is a fantastic program for adding images and metadata.  There is a small learning curve, but once you get it you'll wonder how you ever lived without it.

A few side notes:

I'm not a big fan of EAC.  I used it for a long time but its cumbersome to use; the graphic interface looks like it was written for DOS; it 's obvious it was developed by programmers (really obvious) and (for me) it would always lose it's settings.  Eventually it stopped working for me with some error I couldn't figure out.  So I use my Goldwave software for ripping CDs now.  Honestly, it works better.

For my images to work I did a lot of trial and error.  I was trying to get them to work with an Oppo 95 player and as MP3s in my car.  Eventually I had to make all images 300x300 to get them to work.  Anything larger just wouldn't display.

[Saturn94]

….MP3TAG is a fantastic program for adding images and metadata.  There is a small learning curve, but once you get it you'll wonder how you ever lived without it.

Yes! 

[Rusty Jefferson]

dbPoweramp here. I rip to FLAC "uncompressed" in the drop down menu, which is the same size file as .WAV but has the metadata.

[newzooreview]

I rip to AIFF because it stores metadata and does not impose a burden on the playback system to unpack the compressed file. There's no compelling reason to choose FLAC for local music storage. Disk space has been fairly cheap for a long time now, and AIFF is universally recognized.

It makes sense for streaming services to send FLAC files because it saves them bandwidth, but Qobuz never sounds as good as locally streaming the same file stored as AIFF. There may be other factors involved, but routing every track through a decompression step draws power, generates heat, and consumes processor cycles. Taxing the playback system with unnecessary processes will effect playback. This is why Roon, for example, goes so far as to work with Intel in refining the Roon server software running on Intel NUC (e.g,. their Nucleus server and the build-your-own Roon ROCK server).

If you have a few favorite test tracks in FLAC, try converting to AIFF and comparing. You may hear the difference. Or you might not hear it now but will with system upgrades. It may never come into play for some, and that's ok too. But using an uncompressed format that stores metadata seems like the safest choice if setting out to rip a CD library.

[Rusty Jefferson]

I rip to AIFF because it stores metadata and does not impose a burden on the playback system to unpack the compressed file. There's no compelling reason to choose FLAC for local music storage....

An uncompressed FLAC file is the same size file as an AIFF or a Wav. They all sound the same and introduce the same burden on the Bridge/Renderer. It also has the metadata like AIFF but it's open source and not affiliated with Apple. FLAC and uncompressed FLAC are different.

[Mike-48]

Years ago, I ripped my entire CD library (3000 CDs) with dBpoweramp (paid version). At that time, EAC was not using AccurateRip but dBpa did. Also, I found the interface much better and liked the five sources of metadata to pick and choose from. I still use dBpa and think it's A-1.

IMO, the price of dBpa is so low that for anyone with audio aspirations, it's pocket change -- less than a pair of inexpensive interconnects.

People talk a lot about hearing differences between compressed and uncompressed (both lossless) formats. I suppose on some platforms that could be a problem, but I have never been able to hear anything. I wonder if there have been any well-conducted blind tests. This would be an area where sighted comparisons would be ripe for expectation bias.

So my suggestion would be to do as I do: use dBpa, use FLAC, compress it if you like, and if you hear a difference between compressed and uncompressed lossless formats, figure out what is broken in the playback system.

[RipVanW]

Thanks everyone for their thoughts.

I looked at dBpoweramp and have to agree that it's a much more highly-developed program than EAC is at this point.  I've only ripped a few CDs with it so far, but I'm near-certain that I'll switch over to it for my upcoming rip-fest.  There's a cost to the software, but it's small in the long run compared to the benefits.

The choice of file format is a little more uncertain.  I see pros and cons in all of the choices.  I think at this point I'm 90% certain that I have it narrowed down to two contenders though:  uncompressed AIFF and uncompressed FLAC. 

Yes, FLAC will do lossless compression, but unless I'm trying to fit a ton of files into a portable player, the file size is really of no importance to me.  If I had 3,000 CDs like Mike-48 does, yes, I might well run with compressed FLAC.  However, at 400 CDs allowing for growth to 600, I don't see a benefit, and while modern CPUs aren't at all taxed with the decompression, it still has to be done, which just irks my inner-psyche...  For the portable player problem, it's easy to do a batch-conversion when needed if I want something to listen to on a plane.  But, those times are few and far between (which is why I still have my Sansa), and you're not going to hear the nuances of a song with a jet engine that close to you, so I might as well load a bunch of high-bit-rate MP3s at that point.  Not to mention that I imagine these days portable players have gigs of memory in them anyway, and plane rides are only so long.

That brings me down to FLAC vs AIFF.  AIFF was originated by Apple and FLAC is open source.  I prefer open-source where possible, though I'll pay for software if the feature set and performance warrants it (like with dBpa).  Apple made me mad back when they discontinued the completely open Apple ][+/e/c and introduced the completely closed Mac.  I said goodbye to them then, switched to the open IBM PC-XT and haven't ever looked back.  But... this is just a file format, and (I assume) almost everyone supports it, given the age of it, so I'm not going to hold its heritage against it. 

So... uncompressed FLAC, or uncompressed AIFF...   Hmmmmm  Of the two, does anyone know of any particular pros and cons from a compatibility or feature standpoint?  Given that they're both uncompressed, I can't imagine they're any different sonically...?

[Vincent Kars]

However, when I imported those .wav files into Mp3tag, I was able to pull metadata from gnudb and write it into the .wav files.  I scanned the cover art, and it went in fine as well.  See below when playing back that folder in foobar2k

That is a matter of "luck"
Tagging WAV is a problem.  In fact some people believe you cannot tag is at all.
This is incorrect as the WAV standard supports tagging. Unfortunately this standard is very limited. There are no tags for Album or Cover Art.
However, WAV is a container. You can put anything in it.
A couple of developers decided to circumnavigate the tagging problem by writing ID3 tags in a info chunk.
Indeed, MP3tag does this and Foobar as well.
But it is not a standard so  use other software and all your tags are invisible.
This is the WAV paradox, the support for the audi part is almost universal, the tagging support a mess.
https://www.thewelltemperedcomputer.com/KB/WAV_KB.htm

The reasons I use FLAC
- Excellent tagging support including custom tags.
- Lossless compression. Indeed I agree pricewise this is no longer a very important argument even when using SSD.
However, having my library, my backup, my external backup, it still saves some time and money having a reduced file size.
- FLAC is highly asymmetrical. Finding the best linear prediction is time consuming (well at older hardware is was), unpacking is very efficient, just add the residue to the prediction.
A nice experiment is indeed a media player supporting memory playback. You see a short spike when decoding and that's it.
For those who believe this CPU aspect is important, they might explain why almost doubling the I/O ( that happens when using WAV) doesn't have any impact
- Checksum. FLAC has a internal MD5. You can always check if the data is corrupted.
- Support. Today almost universal except of course Apple.