Ripping on Linux?

1

Currently I’m ripping my CD’s with Exact Audio Copy (EAC), running under Windows 10.
I’m pissed off by Win10 (and MS at all) [Yesterday’s update took around 2 hour, nearly 10 restarts (fine, on a dual-boot system with Windows not the primary system), problem with to less space (even if more than 6 GB free disc space). I want to get rid of MS!]
EAC itself seems not very alive. The last update is older than 3 years, the website looks unrepentant (e.g. forum not available).
Even if EAC did the main job well, I’m not happy at all.
I’ve chosen EAC (and Windows) because it is/was kind of best-free qualitative ripping software. EAC is also the only reason for also having a Windows partition on my HTPC, the only PC with an optical drive.

I guess it’s possible to run EAC also und Wine, but as EAC is not very recent and I will not go on with it in future.

I need an alternative way of doing the audio extraction and it should run on Linux.
It should also be possible to do everything in the shell because I just want to do it remote by SSH connection. Actually I don’t need a GUI for it.
It should work accurately (AccurateRip) and have a feasible error correction. The output will be FLAC always.
It should be open source (with providing a deb-Package).

On Linux cdparanoia is the main component of many other CD ripper but Paranoia III is very old (from 2008), and so I’m not sure if this is the right horse. I don’t see anything going on for Paranoia IV.

How to go on with ripping on Linux?

1 Like
2

Did you see how contradictory your post is? One side says “Windows has too many updates” and then on the EAC side you say “not enough updates”.

The nice thing about EAC is the very usable error checking. I find it very good with damaged CDs. And the links to MusicBrainz and Discogs via the CUETOOLS addon is very handy.

But that is just me.

/Avoids irrelevant Windows conversation…

EAC is ripping CDs. Why do you think it needs to be constantly updated? CDs are ancient tech, and so is FLAC. So as long as things work to standards then they don’t need constant re-writes. Old software is stable software.

Try EAC on Wine and see if Wine gives enough access to the hardware.

But stuff Windows, there will be more Linux’y options. Certainly can do this all from scripts and command line. And again don’t be worried about lack of updates to things like cdparanoia. Software like this is going have been written ages ago and the only reason an update is needed is someone wants to change a GUI or an OS library is changed. Once the bugs have been shaken out then nothing should need to be changed.

Rip to WAV and then convert to FLAC. The command line for converting to FLAC is already waiting for you in EAC.

I think this could be a handy place to try. The FLAC consortium lists software that works well
https://xiph.org/flac/links.html#software

3

https://wiki.archlinux.org/index.php/Optical_disc_drive#Audio_CD Lists a few good options. Since you mentioned accuracy, whipper might be what you want (I’ve used it before and it worked OK, but I’m not a frequent ripper).

1 Like
4

4 posts were split to a new topic: EAC development is still active

5

I use abcde, which is a command-line tool and is libre. I am very satisfied with it.

https://abcde.einval.com

3 Likes
6

Maybe you read a different post because this is not what I’ve written!
I’m not talking about the number of updates. An OS nowadays needs frequent update just for security reasons.
I’m talking about how updates are handled.
It’s just crazy to get a full new installation of the whole Windows OS twice a year (if you want to be up-to-date).
It’s just crazy that an update-cycle needs more than 6 GB free disk space to work (on a system, where nearly everything is de-installed and deactivated what is not necessary to run just EAC).
It’s just crazy if one update-cycle (even if more than one update packages are included) needs to reboot the system several times.
It’s just crazy if you can not use a system for about 2 hours just because of an update-cycle.
It’s just crazy if an update didn’t work with the actual used account (even if it’s the only account on this system and it’s an administrator account).
It’s just crazy.

Everyone how uses a tidy operating system (like most GNU Linux distributions) knows how updates can be processed, like on my Linux Mint: A lot of updates, every few days, but typically very small and fast processing, forcing a mandatory reboot very rarely; even a major update is much more faster, much smaller and much less complicated then on Win10.

I also don’t say EAC has to less updates in particular. I just noticed that the last update (also in the news section of the website) is from Sep. 2016. This looks to me the software is not being developed further.
Updates here are mainly not about security but about general improvements, new features and maybe also fixes. I would have several ideas and wishes for EAC. Beside there is a “Planned For The Next Releases” on the website, but I you don’t see any notes for further development, you can get the impression the software is going down.

Yes, to error checking. This works quite good! This was one of the reasons for me to use EAC.
Well, I would not see the integration of MusicBrainz in EAC so positive. There are several things which could be improved.

Hey guy, come on! Are you on the payroll of Microsoft?
(For me) Win10 it’s also relevant, at least as relevant as EAC itself, since it’s nearly the only by MS supported OS. Beside it’s an OS which can not even be used without violating legal European regulations.

As already written: No Updates requested by me.
Nobody is talking about “constant re-writes”. It’s just a question if anything is going on with this software.
And as already mentioned: There is always space for improvement, and it’s also on his roadmap.
Also standards can be developed (of course, not the Red Book and maybe not FLAC and VorbisComment itself but maybe the commonly used tags),.
“Stable” is no measurement for software quality, it’s just a different word for stalemate.

I don’t plan to use Wine for several reasons (but it might be take some time to explain them all …).

Well, this is not true at all.
Paranoia is not as good as it could be and it’s not on a level, the creators would like to have it and they also didn’t keep quite with it. See CDDA Paranoia Frequently Asked Questions and https://www.xiph.org/paranoia/faq.html#devstatus.
This was years ago (2008?) but sadly I don’t see anything new – for what reason ever.
Maybe there will be minor updates if technically necessary but I don’t see new features (better HW support, better error handling and reconstruction ability).

8

Well, I already heard about it and maybe I’ll try it (even if I’m not sure if it’s also based on cdparanoia).

9

Yes let’s avoid this, but I’m with you about Windows …
Anyway, left Windows behind but move to Mac OS instead of Linux.
Replaced EAC with XLD, and MP3Tag with Picard.
XLD is Mac OS only, I’m afraid.

1 Like
10

I would check out whipper as a Linux ripper.
It supports Accurate Rip and musicbrainz.
@Freso is a developer.

4 Likes
11

As @dns_server mentions, I am involved with the whipper project (and was involved with morituri pre-fork), so feel free to check my bias.

That said, whipper is currently (as best I know) the only Linux ripper that uncompromisingly puts rip accuracy above speed or anything else. As such, it is in the process of being approved as a ripper for a number of private trackers (AFAIK, it’s already been approved of one), which have rather strict demands for correct and verifiably correct rips as I understand it.

I would absolutely recommend using whipper for ripping under Linux. I usually run it via my rip-disc script which also processes the ripped files for replaygain, sends them through #picard (for additional tagging and/or #acoustid submission), and submits #acousticbrainz analyses.

7 Likes
12

whipper: Not available for Linux Mint 19.3 (Ubuntu 18.04 / Debian stable).

It’s too hard to install it: needs unstable libs and Python3.7.

13

According to what is specified in the whipper sources Python 3.5 is sufficient. So that should work on Ubuntu 18.04… Don’t know about the rest of the requirements, though.

I had expected you should be able to install whipper with pip3 install whipper, but unfortunately it seems whipper is not on PyPi. But installation from source should be possible.

1 Like
14

Yeah, it’s a work‐in‐progress:

Anyway, as @outsidecontext says, it can be installed (or just run) from source:

You can also try and figure out the path to get it packaged for Ubuntu/Mint. All of this is open source, driven by volunteers—and I don’t think any of the whipper devs use Ubuntu or Mint… :slight_smile:

2 Likes
15

I was not able to install it.

As you can see on http://www.deb-multimedia.org/dists/testing/main/binary-amd64/package/whipper:

  • python3 (<< 3.8).
  • python3 (>= 3.7~).

The problem seems to be on http://www.deb-multimedia.org/dists/testing/main/binary-amd64/package/python3-cdio.php:

  • python3 (<< 3.8).
  • python3 (>= 3.7~).

The problem is the missing cd-paranoia binary, as described in the linked bugs of GitHub - whipper-team/whipper: Python CD-DA ripper preferring accuracy over speed

Following whipper › Wiki › ubuntuusers.de (and Bug #1750264 “program 'cd-paranoia' is missing from package in 1...” : Bugs : libcdio package : Ubuntu, but libcdio18 is already libcdio19 on deb-multimedia.org) I tried to use the packages of deb-multimedia.org. Finally I failed at python3-cdio.
I tried to install python3.7 (which went basically OK), I also set update-alternatives for python3 from my installed 3.6 to 3.7 but I was not able to install python3-cdio (since still python 3.6 was reported as missing dependency and 3.7 was not detected).

Before trying the package whipper from deb-multimedia.org I tried to build it from source but it failed (and I don’t know exactly why).

Maybe I was just a tiny step away but I was actually not able to fix the problem.

16

If you’re up for trying to figure out how to get it working, feel free to open an issue at https://github.com/whipper-team/whipper or come join the #whipper chatroom on IRC (the chat can be somewhat slow so you might have to wait around in there a bit if you go that route, but might still be faster than going the issue-opening route).

1 Like
17

You could always go with the docker route.

  • Install docker (from ubuntu or use the docker.com repositories)
  • Add your user to the docker group to give your user permission to run it.
  • pull the image
  • Set up the alias to run whipper.
    alias whipper=“docker run -ti --rm --device=/dev/cdrom
    –mount type=bind,source=~/.config/whipper,target=/home/worker/.config/whipper
    –mount type=bind,source=${PWD}/output,target=/output
    whipperteam/whipper”

You should then be able to run whipper and it should not make a difference that it is running in a container running a different python that you have as the magic of docker sets this up and keeps everything contained.

3 Likes
18

Docker is no way for me.
There are several reasons why I don’t use docker (but it’s not necessary to discuss them here).