Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: catalog no., isrc, cd-text & other advanced ripping under linux (Read 4183 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

catalog no., isrc, cd-text & other advanced ripping under linux

The freeware Windows application Exact Audio Copy appears to be the most comprehensive software presently available for accurate and complete transfer of audio-CD data to computer files.

The Linux world, it seems, carries nothing quite so sophisticated. The most recent versions of cdparanoia may be reliable for capture of raw audio data, but the application itself is fairly bare, and many of the applications that wrap its core functionality offer only crude interfaces, limited feature sets, or have fallen out of active maintenance. The command-line utility abcde appears to be straightforward, reliable, and featureful, combining the audio extraction capabilities of cdparanoia with generation of cue sheets and queries for metadata retrieval.

One feature abcde appears to lack is capturing certain metadata encoded on the disc, including catalog numbers, ISRCs and CD-Text information. This data is particularly valuable for integration with advanced metadata tools such as MusicBrainz. The utility also saves no information about the environment and progression of the extraction process, or the estimated accuracy of the results. This information is helpful for evaluating the quality of archived assets.

Some utilities claim support for some of these features, but I have found none operating reliably and accurately.

At the moment, are we simply facing a tradeoff between switching to Windows or forgoing these advanced features, or are further options available for use under Linux?


 


Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #2
Whipper looks interesting. I didn't find it listed in any sources reviewing the options for ripping under Linux. I did find Midori, but it seems not to function properly any longer.

Whipper has not reached a release stage. I wonder whether results may be considered reliable.

I think that CUERipper would not work under Mono, since it seems to be just a front end to EAC, which relies on direct access to hardware.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #3
CUERipper is not at all a front-end to EAC, it is developed independently, with source code available. Also it can rip a CD from command-line. Had it been around when I ripped my collection, I might very well have used it for the whole lot. Try it.

Whipper is a fork of morituri. The actual audio extraction is done by good'old cdparanoia, and CD-Text etc is extracted by cdrdao.  And for CDs that verify AccurateRip you don't need the paranoia features. More at https://wiki.hydrogenaud.io/index.php?title=Whipper

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #4
Yes, it was my mistake about the relation between CUERipper and Exact Audio Copy. CUERipper supports some integration with EAC, but is not dependent, the way I said. I think running CUERipper under Mono or even WINE is not possible due to the need for the ripping software to have direct access to the drive hardware. CUETools itself, which only performs file operations, seems to function under Mono, and though the documentation indicates lack of support for certain encoding or decoding in this context, I have been successful with FLAC. When I try to run CUERipper using the same process, an error message returns.

Whipper seems to have promise, but it seems also that it is still impossible to make a rip under Linux nearly as reliably as through EAC. Currently, it seems the project development team for Whipper has some uncertainty about the best approaches for integration with AccurRIp and CTDB, as well as for support for whole-disc images, which is currently not available The dependence on CD Paranoia is also limiting for non-expert users, as managing read offsets and other advanced ripping details is not straightforward.

At least now I know about CUERipper as an alternative, even if not released from dependence on Windows. What are the various advantages of CueRipper versus EAC?



Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #5
When I try to run CUERipper using the same process, an error message returns.

Ask in the CUETools forum then. I vaguely recall that there is not much chance to get it working on USB drives.


What are the various advantages of CueRipper versus EAC?

Can be operated though command-line, that is a feature you asked for.
Generally, you can have a look at https://wiki.hydrogenaud.io/index.php?title=Comparison_of_CD_rippers


Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #7
It's good if the feature list is approaching a greater level of completeness. Unfortunately, my experimentation with fre:ac gave poor results. The interface was extremely flaky, so much so that the application was unusable. I failed even to start a single rip operation. Hopefully  stability issues will be resolved, and I could try again.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #8
It's good if the feature list is approaching a greater level of completeness. Unfortunately, my experimentation with fre:ac gave poor results. The interface was extremely flaky, so much so that the application was unusable. I failed even to start a single rip operation. Hopefully  stability issues will be resolved, and I could try again.
Was that recently or before the official fre:ac 1.1 release? Stability improved a lot since the 1.1 alpha/beta days and I'm continuing to work on improving it. 1.1.5 will fix several crashes and thread synchronization issues. You might want to try the continuous build which already has those changes (and AccurateRip).

Feel free to contact me if it's still unstable and I'll see what I can do. May be issues specific to a certain distribution, desktop environment or another component of the stack.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #9
Was that recently or before the official fre:ac 1.1 release?

It was just a few days ago, with version 1.1.4.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #10
It was just a few days ago, with version 1.1.4.
Ok, if the issues are still present in the continuous builds and/or the upcoming 1.1.5 version, it would be great if you could report them. I can only fix the issues I know about.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #11
I ran fre:ac version 1.1.4 again, without encountering the problems I noticed earlier. I'm not sure whether the application was actually malfunctioning, or whether I was somehow not using it correctly. What I can explain with confidence is that much of the current layout of the UI is confusing. For example, a set of controls for audio playback appears above the track listing in the tab labelled "Joblist", but I may have assumed that these controls relate to ripping, since no controls appearing more closely related to this action appear in the window pane. If I pressed "play" without an audible volume setting on my audio device, then I may have assumed that the control was broken. Since playback functionality is not expected in a ripping application, but ripping is expected, I would suggest putting buttons for beginning and ending encoding in a prominent location and removing the playback feature. Burying the essential function of the application in the last item on the menu bar is not only inconvenient for regular use, but confusing for first use.

I would also add that I personally find the "Joblist" metaphor confusing, as what it appears to represent is a track list.

One final observation is that if a USB drive is connected while the application is running, it is not detected until the application is restarted. I have found this behavior common in ripping software, and would characterize it is a moderate inconvenience, not a critical defect.

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #12
Thank you for your feedback!

Controls for starting, pausing and stopping a rip/conversion are in the main toolbar which I think is more prominent than the playback controls. However, I'm thinking about adding a first-start experience that would display an overlay explaining the most important toolbar buttons and functions. This should help getting new users acquainted with the interface.

The playback functionality is essential and used by many users to e.g. verify the correct order of chapters when creating multi-chapter files or to monitor the effect of DSP filter settings before starting a conversion. Maybe it's not so important when ripping CDs, but there are other conversion tasks where it is needed.

I agree that the Joblist designator is not ideal for the main tab. Track list, however, wouldn't be either as the entries do not necessarily represent tracks. Depending on what you are doing, they can also represent files or chapters inside a file. Maybe Titles would be a better designator. I'll think about it.

Detecting newly attached drives while fre:ac is running is already on my to do list. Currently that is supported on macOS only.

 

Re: catalog no., isrc, cd-text & other advanced ripping under linux

Reply #13
I understand the preference for avoiding the term "tracks",  but I myself would be less hasty to dismiss it, given the general way it has been used recently.

I have no argument against the playback feature. I have never used nor noticed such a feature in a ripping application, but as long as it is useful, it presents no problem.

More generally, though, some better way to express visually and semantically the usage and intention currently captured by the "joblist" would be, I think, very helpful.

Overall, I find several aspects of the interface confusing, including the general presentation of the "joblist", the design of the playback controls, and the location of the "encode" button, and on a very personal note, actually a bit unsettling. I generally perceive a lack of clarity from the visual relationships presently in place.

Most prominently, I would suggest placing an "encode" button in the main window, for example at the bottom, and clearly designating the playback controls as such, probably moving them to a less central position. Note that at least in my environment, both the "play" button and the "encode" button appear as familiar "play" symbols.

The application seems to aim for a rich and powerful feature set, which I respect, only noting that this objective carries with it the challenge of designing a user interface that makes those features accessible, without presenting as overwhelming. Even if advanced usage is a core motivation for the project, the project would be stronger if it is attractive even for basic usage and by inexperienced users.

By the way, as an alternative to a "first start" guide, or in addition, you might consider a "basic" mode, which would keep some of the advanced controls out of the main view.