Ripping CDs and converting audio with fre:ac [LWN.net]

By Joe Brockmeier
April 8, 2026

It has been a little while since LWN last surveyed tools for managing a digital music collection. In the intervening decades, many Linux users have moved on to music streaming services, found them wanting, and are looking to curate their own collection once again. There are plenty of choices when it comes to ripping, managing, and playing digital audio; so many, in fact, that it can be a bit daunting. After years of tinkering, I've found a few tools that work well for managing my digital library: the first I'd like to cover is the fre:ac free audio encoder for ripping music from CDs and converting between audio formats.

Building a music library starts with acquiring music rather than renting it; when I decided to ditch my Spotify subscription a few years ago, I already had a sizable CD collection that I'd started accumulating in the late 1980s. Unfortunately, I had been haphazard about converting to digital formats; some of it was ripped to MP3, some to FLAC, and I had not yet gotten around to digitizing hundreds of CDs. The metadata for what I had converted was a mess. It was time to standardize things and get serious about archiving everything in a digital format.

Step one was to pick the format or formats of choice; I settled on FLAC as the lossless format of choice for long-term archiving, and MP3 as a lossy-but-acceptable format to be stored on my laptop and copied over to my media player. I have a hardware player that reads from Micro SD cards rather than keeping my collection on my phone; it's quite impressive how compact storage has become over the years, and it's nice to have 128GB cards to work with rather than the paltry 6GB of storage my first MP3 player (a Creative Nomad 2) had.

No doubt some folks will wonder "why not Ogg?" That is a fair question. The primary reason is that I often share music files with family members who do not have Ogg-compatible devices. Standardizing on MP3 means that I could buy a dirt-cheap music player for my daughter and populate a few Micro SD cards with playlists without worrying about compatibility. MP3, despite its warts, is universally supported but Ogg support is not guaranteed.

fre:ac

Step two is, of course, ripping the CDs. There are countless Linux applications for extracting audio from CDs. After sampling many of these I've settled on fre:ac because it serves as a one-stop shop for ripping CDs and converting audio. None of its features are unique to fre:ac, of course, but it's rare to find them all collected in a single tool that offers (for me, anyway) the right mix of features, customization, and ease of use. For example, many rippers will convert audio from a CD to Flac, MP3, Ogg, or other formats; fewer have the ability, as fre:ac offers, to convert to multiple formats in a single run, and write the appropriate metadata for each.

Fre:ac is a multi-platform application; builds are available for Linux, FreeBSD, Haiku, macOS, and Windows. The project offers official Flatpak and Snap builds, in addition to AppImage builds for x86_64, 32-bit x86, as well as 32-bit and 64-bit Arm. It is licensed under the GPLv2, and uses a custom component framework to provide an interface to the encoders, decoders, taggers, and other applications fre:ac uses, such as LAME for MP3 encoding, libcdio to decode CDs, and many others. Fre:ac smoothes over the complexity of using the various libraries and command-line tools while stitching together the chain of utilities that extract audio, convert it to the desired format, and so forth.

The project began in the early 2000s under the name "BonkEnc", and was renamed in 2010. Fre:ac is mostly a one-person operation; its maintainer, Robert Kausch, is responsible for the vast majority of commits to its repository. There are 16 other contributors, all of whom have made fewer than 30 commits. He is actively developing fre:ac, but formal releases are few and far between: the most recent, 1.1.7, was announced in March 2023. However, the project also provides a set of continuous builds that track current development. In September 2025, Kausch said that a 1.1.8 release is in the works, but he couldn't say when it would be finished. At least for my purposes, this is fine—fre:ac is a mature program that does not really need much in the way of new features. It only needs to be maintained so that it continues to work as various libraries and helper programs are updated.

Settings

Using fre:ac is straightforward; the first order of business is to set the encoder to be used when converting a set of files or ripping from CD. The available encoders vary by platform; Linux versions of fre:ac include FFmpeg, LAME, Xiph's FLAC encoder, and quite a few others. The multi-encoder hub (meh!) component allows users to select two or more encoders to be used in the same processing run; so, for example, meh! can be used for converting a CD to FLAC and MP3 in one go. Fre:ac has sensible defaults for encoders, but it's also possible to set encoder options, such as the bit rate for MP3s, manually.

In addition to the encoder, users can choose from an assortment of filters for signal processing, such as the volume adjustment component to raise or lower the default volume of an encoded file. This might be useful, for example, when converting CDs that are victims of the loudness war. I've noticed a distinct difference in the loudness of CDs purchased in the 1980s and early 1990s versus more recent releases, but don't take my word for it; there is a Dynamic Range Database online with information about more than 190,000 releases. Each entry has a rating on its dynamic range; CDs with a higher score are more likely to sound better, at least as a representation of the recorded music. Reducing the volume won't improve the dynamic range of an album, but it can help to ensure that tracks from different albums play at the same relative volume; it can be annoying when creating a playlist and some tracks are markedly quieter or louder than the rest.

ReplayGain is a standard that is designed to normalize loudness for audio formats. Unfortunately, fre:ac does not have support for adding ReplayGain tags at this time. Kausch has said that he plans to add support at some point, but he couldn't commit to when it would be available.

Users will also want to pay a visit to fre:ac's settings (Options -> General Settings) to configure its other CD-ripping options, such as the output filename pattern, the CDDB source for album metadata (Gnudb by default), and the metadata tag formats. Assuming fre:ac finds CDDB data for a CD, it uses the metadata to populate the output filename; for example, I use the following structure when creating new files:

    The Cure/(2024) Songs of a Lost World/01-Alone.mp3

That is, the artist or band name, the year the album was released (in parentheses) and its title, the track number, title of the song, and the extension for the audio format (e.g. mp3). If fre:ac does not find metadata for a CD in Gnudb, which is extremely rare in my experience, it can be added manually before converting audio or added later with a tag editor such as Kid3 or MusicBrainz Picard.

Fre:ac also supports saving multiple configurations, so it's possible to have a configuration for ripping CDs, another for converting FLAC to MP3, and yet another for adjusting the loudness of audio from badly mastered CDs.

Ripping and converting

After configuring fre:ac, it's time to put it to the test. Users can add a CD and/or audio files with the File menu or toolbar icons; fre:ac even allows adding all files by filename pattern (e.g., "*flac") throughout a set of folders. This makes it quite convenient for converting an existing collection in one format to another. In addition to handling the format conversion, fre:ac will translate the metadata from one format to another so the collection does not need to be re-tagged.

After tracks are added to be processed, they will show up in the "Joblist" tab. The tags that will be added to the files are shown in the "Tags" tab; these can be edited before conversion if any of the metadata is wrong or missing. When ripping CDs, I find that a lot of the metadata pulled from Gnudb is mostly accurate, but I often disagree with the genre and the artist metadata often needs tweaking as well. This is not helped by bands that variously style the "and" in their name across releases as "and", "&" and "'N". Once all is well with the metadata, it's time to start the encoding process.

When converting CDs, fre:ac will attempt to verify the checksums of the ripped audio against the AccurateRip database, which houses checksum values for millions of CDs. If there is a mismatch, fre:ac will throw an error with a list of tracks that have a bad checksum. Note that it is possible that the conversion is fine and that the checksums do not match because it's a different version of the same album. Fre:ac also has a "Logs" tab where, as the name implies, it writes out the log of its operations, which displays the file checksums, if they were successfully verified, and how long each operation took.

Overall, I've found fre:ac to be a reliable workhorse for digitizing CDs and converting audio files. The only real downside I've encountered with fre:ac is its documentation. The basics of its operation are self-explanatory or easily uncovered with a bit of poking around. However, there are features that would benefit from documentation, such as what each filter does and suggestions for best results, but fre:ac's documentation is sparse and dated. The project does have a GitHub discussion forum, though a number of questions remain unanswered after quite some time. Trial and error is, currently, the best way to learn its ins and outs.

to post comments

How about the bad CDs?

Posted Apr 8, 2026 15:57 UTC (Wed) by Henning (subscriber, #37195) [Link] (7 responses)

Ripping CDs is the final task where I keep an old Windows system (Win 7) with Exact Audio Copy that is several years old but still rocking.
Would love to switch, but I am scared about the handling of problematic CDs (damaged, copy protected, just weird, etc) where I have come to trust EAC with my steady flow of second-hand and old CDs.

What is your experience with problematic CDs and different ripping methods (error correction, burst, etc) when it comes to fre:ac and/or other linux-tools?
One day my laptop might die and the need to find another trusty ripping station will become a urgent problem for me.

How about the bad CDs?

Posted Apr 8, 2026 17:12 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

Generally, CD ripping on Linux is a routine operation that has been a solved problem for decades. I don't personally have a lot of messed-up discs, but, I think all you do is just use cdparanoia instead of cdda2wav for them. Obviously you won't get everything off of a disc that's been too damaged to read, but cdparanoia is supposed to get whatever you can within the physical limitations of the hardware and the disc.

How about the bad CDs?

Posted Apr 9, 2026 1:54 UTC (Thu) by felixfix (subscriber, #242) [Link]

I just counted 2105 "1.flac" files from CDs I ripped with cdparanoia starting 2004-06-01, some of which were from the very early days of CDs 20 years earlier, when so few were available that it felt like I bought almost anything the stores had. I still have the originals packed away in boxes, and memory says there are around 5-10 that did not rip well enough to produce any files. Something less than a 1% error rate, depending on definition. I do remember trying several different CD players and finding that none was best overall; those few failures are ones that failed with every player in my collection.

How about the bad CDs?

Posted Apr 8, 2026 17:27 UTC (Wed) by jzb (editor, #7867) [Link]

I haven't really encountered many problematic CDs over the years; most of my CDs were bought new and handled with great care, and I can only recall one CD that had copy protection (Fiona Apple's Extraordinary Machine, IIRC). I think I resorted to non-ripping means to get a digital copy of that one.

If you look at this chart, fre:ac compares pretty favorably to EAC.

How about the bad CDs?

Posted Apr 9, 2026 7:42 UTC (Thu) by eru (subscriber, #2753) [Link]

In my experience, cdparanoia can handle iffy disks well, including one with attempted copy protection (I think that was 20 years ago, trying to copy-protect CD:s was fortunately a short-lived fad). Cdparanoia just deals with it as corruption it tries to recover from. Damage it cannot fix may be audible as snaps or crackle. Many other programs actually use cdparanoia underneath.

How about the bad CDs?

Posted Apr 9, 2026 14:53 UTC (Thu) by broonie (subscriber, #7078) [Link]

whipper does a really good job with dodgy CDs, it's got lots of good stuff around retrying reads and validating that what it's got is good and stable.

How about the bad CDs?

Posted Apr 9, 2026 22:23 UTC (Thu) by HenrikH (subscriber, #31152) [Link]

That is when you use cdparanoia and e.g RubyRipper (GUI ontop of cdparanoia that also does compression and tag handling)

How about the bad CDs?

Posted Apr 10, 2026 9:55 UTC (Fri) by tomsi (subscriber, #2306) [Link]

When I used EAC, I used burst mode on the problematic CD's.

Since I have lost rips to crashed hardware (real men don't take backups, but they cry a lot ;) ), I have now used Claude Code to build the ultimate ripping system that runs on linux (and macos). The ripping process is done by using cdparanoia in paranoia mode - if that fails, it retries with paranoia off; if that also fails, burst mode.

(The reason I build my own system is primarily to handle multiple drives sensibly, and support multiple ripping machines if wanted.)

Awesome album!

Posted Apr 8, 2026 16:14 UTC (Wed) by ahawtho (subscriber, #116503) [Link] (1 responses)

Good choice for the example album. Smith didn't seem to have lost his edge at all. Introduced Disintegration to my son this year and he loved it.

Awesome album!

Posted Apr 9, 2026 15:57 UTC (Thu) by jzb (editor, #7867) [Link]

In my opinion, it's their best work since Disintegration, though I was also partial to Wish and Wild Mood Swings. They don't seem to have lost anything as a live band, either; I saw them twice in the 90s, and then twice again in 2016. If anything, the live show was even better. Hoping they'll come through my neck of the woods sometime before they quit touring so I can take my wife and daughter to see them. I managed to drag them to a Robyn Hitchcock show right before the pandemic started...

Other choices

Posted Apr 8, 2026 17:33 UTC (Wed) by q3cpma (subscriber, #120859) [Link] (13 responses)

Since music and digital audio are domains I can claim a modicum of expertise in, I might as well give some pointers of my own concerning software.

Here are some features you might or should want: MusicBrainz as metadata source (really needed, freedb/CDDB are fully obsolete these days), correct handling of pregap and preemphasis, Accurip V1+V2 hash checking (some CDs are in only one of these DBs).

fre:ac seems okay, since it uses cdparanoia underneath, but no MusicBrainz is too large a failing in my eyes.
whipper (continuation fork of morituri), the standard Linux/*BSD cdparanoia frontend for serious business (i.e. private trackers focused on quality).
cyanrip, the rising star in this world and the one I use. Does everything with almost no dependencies (it's C) and actually handles all cases of preemphasis unlike modern EAC.
CUERipper, the one I usually recommend to Windows people these days. Easier to setup than EAC, cleaner GUI and a killer feature: a special, modern remote DB (CTDB) that contains enough parity information to correct errors up to ~75 sectors!

As always, don't forget the HydrogenAudio wiki when it comes to this stuff.

Other choices

Posted Apr 8, 2026 19:19 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

One thing to keep in mind when trying to automate everything: sometimes it's easier not to. Just put in names manually! If you have 20 discs that are not in the database, it'll take you about 20 minutes to put them in. That's less time than you'll spend setting up scripts.

Other choices

Posted Apr 8, 2026 19:33 UTC (Wed) by q3cpma (subscriber, #120859) [Link] (8 responses)

For sure, but it's often as easy to fill MusicBrainz yourself to benefit the rest of the community!

Other choices

Posted Apr 8, 2026 21:21 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (7 responses)

One problem I've had with user-contributed data is that the quality control tends to be lacking. Information for different discs from the same source- sometimes even different discs in a boxed set- was contributed by different users who couldn't agree on important details. For example, I had the boxed set of the Toscanini recordings of Beethoven's symphonies, and the different discs had subtle differences in how all the metadata was recorded. It was very annoying, because it meant they didn't show up the same when searching by that metadata, which you would really like to do with a music system. This was a long time ago, so maybe the databases have improved since then, but I could see consistent metadata as a substantial advantage to doing everything yourself.

Other choices

Posted Apr 8, 2026 22:30 UTC (Wed) by Wol (subscriber, #4433) [Link] (6 responses)

> For example, I had the boxed set of the Toscanini recordings of Beethoven's symphonies, and the different discs had subtle differences in how all the metadata was recorded.

I've come across this before, but I think the reason is that it isn't a boxed set :-)

The same identical recording is sold - in different packaging - as both an individual symphony, and as a boxed set. So it's quite likely several people could have bought the individual recordings and uploaded them, then you've got the same recordings in a boxed set and you're wondering why they're different.

Cheers,
Wol

Other choices

Posted Apr 8, 2026 23:10 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

> The same identical recording is sold - in different packaging - as both an individual symphony, and as a boxed set. So it's quite likely several people could have bought the individual recordings and uploaded them, then you've got the same recordings in a boxed set and you're wondering why they're different.

IIRC, MusicBrainz explicitly accounts for that. It has a pretty sophisticated multi-level M:N mapping between compositions, their recordings, and media on which those recordings appear, all precisely for this reason. If you do everything right, you won't clobber someone else's metadata of a boxed set with your metadata of an individual recording bought separately.

Other choices

Posted Apr 9, 2026 6:40 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

But how does it tell the difference between an individually packaged CD, and a box-set CD, when the two are (from the computer's PoV) identical?

So when I stick my CD from the boxed set in to rip, and someone else has already ripped and uploaded the standalone, MusicBrainz is going to return the standalone.

And if someone else has also uploaded the boxed set, MusicBrainz won't know which one to return ...

Cheers,
Wol

Other choices

Posted Apr 9, 2026 8:29 UTC (Thu) by kkretsch (subscriber, #177237) [Link]

Picard can’t tell from the CD TOC, but you can tell it to do a lookup by TOC (https://picard-docs.musicbrainz.org/en/latest/usage/retri...) and it will give you a list of the releases which contain the corresponding tracklist.

Other choices

Posted Apr 9, 2026 13:31 UTC (Thu) by jzb (editor, #7867) [Link]

And if someone else has also uploaded the boxed set, MusicBrainz won't know which one to return ...

A lot of the time (but not always) MusicBrainz will have multiple entries for an album and even metadata for complete box sets. If you're using Picard, it will try to return the most likely match, but you can pick manually. Just to pick an album randomly, if you look at Rage Against the Machine's self-titled album, there are 39 versions available. Odds are you'd be able to find the correct metadata for your specific copy, or one that is almost an exact match.

Other choices

Posted Apr 8, 2026 23:30 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

The symphonies are only an example. You'll see something similar with different albums by a rock band. Things like the music genre or how the credits are assigned are different from album to album. People might seriously disagree on whether a band gets categorized as, say, Rock or Pop.

I think it's worse for classical music than popular music, though. For one thing, I suspect a lot of the metadata categories were devised with popular music in mind, so there's a mismatch. Related is that most popular music is almost always going to be categorized by the performer, but classical music could be categorized by the composer, conductor, the performing ensemble, or a soloist. Should my Toscanini recordings of the Beethoven symphonies be categorized as Beethoven, Toscanini, or NBC Symphony? How an album is sold may affect how the music is categorized, and it could also very easily depend on how the person recording the metadata perceives the album. It's a big old mess.

Other choices

Posted Apr 9, 2026 2:04 UTC (Thu) by felixfix (subscriber, #242) [Link]

When I began ripping mine around 2004, I used cddb and its successor / predecessor until it too disappeared or went private. At first it was annoying having to type everything in, but it didn't take long to parallelize it with the ripping, and I realized it was faster and less annoying than comparing and correcting and standardizing the cddb data, at which point I stopped even checking cddb. I've since found with the few new CDs I still buy that taking a picture and passing it to an AI produces the correct text most of the time, even translating Japanese.

Other choices

Posted Apr 8, 2026 19:44 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (1 responses)

Another option is abcde. It's not been updated for some time but it's worked flawlessly for my needs. It queries musicbrainz/cddb, presents the result in a text editor for you to correct any issues, and then rips to any format, applying normalization/gain/etc.

My computer that has an optical drive doesn't have a display attached to it, so it's useful to have a command-line tool like abcde, allowing to do the whole process over SSH.

Other choices

Posted Apr 9, 2026 9:00 UTC (Thu) by diamond_light (subscriber, #72450) [Link]

I use abcde to rip to FLAC and then Picard to fill in richer metadata. It's been a reliable workflow but I'll also be looking at other recommendations mentioned here.

Other choices

Posted Apr 9, 2026 7:10 UTC (Thu) by cdamian (subscriber, #1271) [Link]

I am a big fan of whipper. It's super reliable and does EAC like things.

I'll have a look at cyanrip for my next rips.

Ogg support...

Posted Apr 10, 2026 5:22 UTC (Fri) by rsidd (subscriber, #2582) [Link] (9 responses)

Android supports ogg, and the most common music player these days is a phone. Not sure if standalone Android-based players exist. But I'm a bit surprised that lack of support of ogg was a factor in 2026!

I have a music collection ripped 15 years ago, and it all lives on my phone now (as well as on a backup), a few hundred CDs. To my ear, a 128kbps ogg sounds better than a 256kbps mp3, and that's important. Most of my rips are VBR oggs, avg 192 kbps, indistinguishable to my ears from FLAC.

Ogg support...

Posted Apr 10, 2026 9:18 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (6 responses)

I'm sorry for nitpicking here: Ogg is a container format, not a codec. Both of you probably mean Ogg+Vorbis (Vorbis being the audio codec packaged inside an Ogg container). That's generally universally supported. More spotty is support for Ogg+Opus, with Opus being the current, modern audio codec by Xiph.

Ogg support...

Posted Apr 10, 2026 10:20 UTC (Fri) by rsidd (subscriber, #2582) [Link] (1 responses)

This is true, but the vorbis audio files generally have the extension .ogg while opus files have .opus. So it is common to say "ogg" when "ogg vorbis" is what is meant.

Ogg support...

Posted Apr 10, 2026 10:39 UTC (Fri) by mbunkus (subscriber, #87248) [Link]

Yeah, absolutely (and some players even only play Ogg+Opus file if they use an .opus extension but not if they use an .ogg extension… potayto, potahto). I only replied as the conversation was about support/compatibility, and there is a noticeable difference in support for Vorbis vs. Opus.

Ogg support...

Posted Apr 10, 2026 18:07 UTC (Fri) by nowster (subscriber, #67) [Link] (3 responses)

You could also potentially have FLAC, PCM, Dirac, Theora and/or Speex inside an Ogg wrapping.

Ogg support...

Posted Apr 10, 2026 18:45 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (2 responses)

Also entirely correct, though FLAC is the odd one out here. Most of those that you've mentioned lack essential information at the bitstream (codec) level that's usually provided at the container (Ogg) level such as timestamps or meta information such as tags, languages or the ability to be multiplexed together with oder media types.

FLAC is odd as it usually does NOT come inside an Ogg container, even though it does have an official mapping for transport in Ogg. Instead of comes with its own meta-information built-in at the bitstream level (such as the "streaminfo" block for free-form tags or the "seek table" for efficient random seek access to arbitrary points). Official tools such as the "flac" command-line encoder can produce FLAC-in-Ogg via the "--ogg" parameter but usually don't.

So it's simple, right? A "song.flac" is FLAC-but-not-in-Ogg, "podcast.opus" is an Opus-in-Ogg file whereas "speach.ogg" is Vorbis-in-Ogg. Oh, and Theora is usually "movie.ogv" (for "Ogg Video", as in "Ogg container with only Video inside it", meaning it's Theora-in-Ogg in this case). Ain't file extensions wonderful? 🤣

Ogg support...

Posted Apr 10, 2026 22:02 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

And then there's the whole Matroska situation, where you have .mkv (video with or without other stuff, any codec), .mka (audio with or without other stuff, but no video, any codec), .mks (subtitles only), .mk3d (stereoscopic video), and debatably .webm (video and/or audio each in one of two specific codecs, generally more opinionated than "regular" Matroska, but probably compatible with a wider range of software).

In principle, you could go through an entire library of multimedia and uniformly encapsulate everything in Matroska, but I'm not sure if there's a point to doing that.

Ogg support...

Posted Apr 11, 2026 2:05 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

You can chain Matroska files into other files by using chapter references. For example, you can have an "seamless season" `.mkv` that plays the episodes of a series' season(s) without intros and outros as a single file by listing the "core" chapter IDs in sibling `.mkv` files in order. For audio, it is probably less useful unless you're cutting (typically) fiction podcasts into chapters with which to then do this. Or someone published chapter metadata for podcasts to cut out in situ ads. Alas, very few podcasts actually use chapters in the first place…

Ogg support...

Posted Apr 10, 2026 11:13 UTC (Fri) by pizza (subscriber, #46) [Link]

> Not sure if standalone Android-based players exist.

Android-based DAPs targeting various levels of audiophile fetishists are the second-most-common types of devices out there today, after the cheap shovelware stuff.

Ogg support...

Posted Apr 10, 2026 13:52 UTC (Fri) by jzb (editor, #7867) [Link]

Oh, Android-based players certainly exist... plenty of them.

Yes, Android does support Ogg Vorbis, but there are many people who don't use Android. My family fits in that category. My wife and daughter will abandon their iPhones shortly after the heat death of the universe and probably not before that. And, of course, my decision to standardize on MP3 predates 2026 by many, many years; I just happened to write about it now.

The player I was referring to was a sub-$25 MP3 player I picked up to send with my daughter when she went to AmeriCorps in 2024. I preloaded some MicroSD cards with a bunch of playlists I had curated for them over the years. The odds of it being lost or mangled were pretty high, so I figured the cheaper, the better. Ogg support was not a consideration. :-) The previous time she went on a trip, I had to buy new glasses because hers were lost in a body of water in Florida...

CLI alternative: Jack the CD ripper

Posted Apr 10, 2026 10:26 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Many years ago I ripped most of my CDs using Jack the CD ripper, a command-line program that seems to still be maintained. Once it is configured the way you want it (file naming, directory structure, etc), it is very fast and efficient. If I plan to rip CDs in the future I will certainly try it again. CLI programs are generally much faster once you set them up.

Can also recommend beets

Posted Apr 10, 2026 11:37 UTC (Fri) by hickinbottoms (subscriber, #14798) [Link]

There are a million ways to do it, but if you're happy to split the ripping step from the tagging/organising then I can recommend beets (https://beets.readthedocs.io/en/stable/index.html).

I've had very good results with that, after first ripping with whipper or abcde.

It handles tagging (from MusicBrainz), ReplayGain, renaming, transcoding, organising the library files, and many other things via plugins (https://beets.readthedocs.io/en/stable/plugins/index.html).

It's configurable, and command-line-based, which means once you've decided your approach to tagging/naming/formats etc you can just script your "ingest" process and do it consistently the same way even if you only occasionally add new media. You can of course join the ripping with the tagging/media management via your own scripts, too.