Code Monkey home page Code Monkey logo

cyanrip's Introduction

Fully featured CD ripping program able to take out most of the tedium. Fully accurate, has advanced features most rippers don't, yet has no bloat and is cross-platform.

Features

Installation

Alpine Linux

apk add cyanrip

Archlinux

pacaur -S cyanrip

Or use your favorite AUR installation method.

Debian (and derivatives)

apt install cyanrip

Void Linux

xbps-install -S cyanrip

FreeBSD

pkg install cyanrip

Or via ports: cd /usr/ports/audio/cyanrip && make install clean.

NixOS

nix-env -iA nixos.cyanrip

Docker

docker pull ep76/cyanrip

Automated Windows builds Windows CI

Latest release Windows build

Latest Windows build

If the latest build is broken, you can find older ones in the nightly release page

Compiling

Complete list of dependencies:

  • FFmpeg (at least 4.0, libavcodec, libswresample, libavutil, libavformat, libavfilter)
  • libcdio-paranoia
  • libmusicbrainz5
  • libcurl

All are available on any up-to-date Linux distribution's package repositories. To compile and install on any *NIX platform:

meson build

ninja -C build

sudo ninja -C build install

cyanrip can be also built and ran under Windows using MinGW

CLI

Arguments are optional, except -s. By default cyanrip will rip all tracks from the default CD drive, output to flac only, enables all cd-paranoia error checking, performs a MusicBrainz lookup, and downloads and embeds the cover art if one is found.

Argument Description
Ripping options
-d string The path or name for a specific device, otherwise uses the default device
-s int Specifies the CD drive offset in samples (same as EAC, default is 0)
-r int Specifies how many times to retry a frame/ripping if it fails, (default is 10)
-Z int Rips tracks until their checksums match <int> number of times. For very damaged CDs.
-S int Sets the drive speed if possible (default is unset, usually maximum)
-p number=string Specifies what to do with the pregap, syntax is described below
-P int Sets the paranoia level to use, by default its max, 0 disables all checking completely
-O Overread into lead-in/lead-out areas, if unsupported by drive may freeze ripping
-H Enable HDCD decoding, read below for details
-E Force CD deemphasis, for CDs mastered with preemphasis without actually signalling it
-W Disable automatic CD deemphasis. Read below for details.
-K Disable ReplayGain tag generation. Read replaygain for details.
Output options
-o list Comma separated list of output formats (encodings). Use "help" to list all. Default is flac
-b int Bitrate in kbps for lossy formats, 256 by default
-D string Directory naming scheme, see below
-F string File naming scheme, see below
-L string Log naming scheme, see below
-M string CUE file naming scheme, see below
-l list Comma separated list of track numbers to rip, (default is it rips all)
-T string Filename sanitation, default is unicode, see below
Metadata options
-I Only print CD metadata and information, will not rip or eject the CD
-a string Album metadata, syntax is described below
-t number=string Track metadata, syntax is described below
-R int or string Sets the MusicBrainz release to use, either as an index starting from 1 or an ID string
-c int/int Tag multi-disc albums as such, syntax is disc/totaldiscs, read below
-C path or url Sets cover image to embed into each track, syntax is described below
-N Disables MusicBrainz lookup and ignores lack of manual metadata to continue
-A Disables AccurateRip database query and comparison
-U Disables Cover art DB database query and retrieval
-m Lookup cover art with max size: 250, 500, 1200, -1 (no limit, default)
-G Disables embedding of cover art images
Misc. options
-Q Eject CD tray if ripping has been successfully completed
-V Print version
-h Print usage (this)
-f Find drive offset (requires a disc with an AccuRip DB entry)

Metadata

In case the MusicBrainz database doesn't contain the disc information, is incomplete, or incorrect, you can manually add metadata via the -a argument for album metadata and -t argument for track metadata:

-a album="Name":album_artist="Artist":date="2018":random_tag="Value"

-t 1=artist="Track Artist":lyrics="Name":random_tag="Value" -t 3=artist="Someone Else"

All key=value pair tags must be separated by :. For track tags, the syntax is -t track_number=key=value:key=value. You need to specify the -t argument separately for each track.

For convenience, if any of the first 2 metadata tags of tracks are missing a key, such as with -t 2=some_title:some_artist:key=value, cyanrip will automatically prepend title= and artist= such that it becomes -t title=some_title:artist=some_artist:key=value. A missing key in tag 1 is always considered a title while a missing key in tag 2 is always considered artist, so either can be skipped with no effect.

The same goes for album tags, with album= and album_artist= being omitable.

For album tags, if either artist or album_artist are unset, their values will be mirrored if one is available.

The precedence of tags is Track tags > Album tags > MusicBrainz tags.

Output

The output encoding(s) can be set via the -o option as a comma-separated list. Currently, the following formats are available:

Format name Description Extension Cover art embedding Notes
flac Standard FLAC files .flac ✔️ Always uses maximum compression
tta TTA (True Audio) files .tta Always uses maximum compression
opus Standard Opus files (in an Ogg container) .opus VBR, use -b to adjust the bitrate, default is 256 (kbps)
aac Standard AAC files .aac Use -b to adjust the bitrate, default is 256 (kbps)
wavpack Standard lossless WavPack files .wv Always uses maximum compression
alac Standard ALAC files .alac Always uses maximum compression
mp3 Standard MP3 files .mp3 ✔️ VBR, use -b to adjust the bitrate, default is 256 (kbps)
vorbis Standard Ogg/Vorbis files (in an OGG container) .ogg Use -b to adjust the bitrate, default is 256 (kbps)
wav Standard WAV files .wav 16-bit little endian signed audio, or 32-bit in HDCD mode
aac_mp4 Standard MP4 files (with AAC encoding) .mp4 ✔️ Use -b to adjust the bitrate, default is 256 (kbps)
opus_mp4 Standard MP4 files (with Opus encoding) .mp4 ✔️ Use -b to adjust the bitrate, default is 256 (kbps)
pcm Raw audio, 16-bits, two channel, little-endian .raw

For example, to make both FLAC and MP3 files simultaneously, use -o flac,mp3. Encodings are done in parallel during ripping, so adding more does not slow down the process.

To adjust the directories and filenames, read the naming scheme section below.

Pregap handling

By default, track 1 pregap is ignored, while any other track's pregap is merged into the previous track. This is identical to EAC's default behaviour.

You can override what's done with each pregap on a per-track basis using the -p track_number=action argument. This argument must be specified separately for each track.

action Description
default Merge into previous track, drop on track 1
drop Drop the pregap entirely
merge Merge into current track
track Split into a new track before the current

If the pregap offset isn't available for a given track, this argument will do nothing.

cyanrip guarantees that there will be no discontinuities between tracks, unless the drop action is used to delete a pregap.

Cover art embedding

cyanrip supports embedding album and track cover art.

To embed cover art for the whole album, specify it with the -C path or -C destination=path parameter. path can be a URL, in which case it will be automatically downloaded.

If destination is a number, the cover art will be embedded only for the track with that number. Otherwise, destination should be a descriptor like Front or Back or Disc. If destination is omitted, Front, then Back will be used.

Cover arts which are not attached to a track will be copied to each output directory as destination with an autodetected extension.

If multiple cover arts are present and no track cover art is specified, only the cover art with Front destination will be embedded, or the first cover art specified if no Front exists. Otherwise, only the specified track cover art will be embedded.

Cover art downloading

If a release ID is specified or detected, and no Front or Back cover arts were specified, a query will be made to the Cover Art Archive and if found, the archive cover art will be downloaded and used.

Multi-disc albums

cyanrip supports ripping multi-disc albums in the same output folder. To enable this manually, specify the -c argument followed by disc/totaldiscs (/totaldiscs is optional), otherwise it'll be done automatically if the MusicBrainz tags indicate so.

The track filenames will be disc.track - title.ext. The logfile will be Album name CD<disc>.log.

As well as using the -c argument, you can also specify the disc=number:totaldiscs=number in the album/track metadata.

If each disc has a title, you should use the discname tag if you're manually setting tags, which is what MusicBrainz will set if available.

HDCD decoding

cyanrip can decode and detect HDCD encoded discs. To check if a suspected disc contains HDCD audio, rip a single track using the -l 1 argument and look at the log. A non-HDCD encoded disc will have:

HDCD detected: no

If the CD does contain HDCD audio something similar to the following will be printed:

HDCD detected: yes, peak_extend: never enabled, max_gain_adj: 0.0 dB, transient_filter: not detected, detectable errors: 0

Should a track be detected as HDCD, it would be safe to proceed decoding all of the disc. The resulting encoded files will have a bit depth of at least 24 bits.

Deemphasis

Old (and not so old) CDs may require deeemphasis. cyanrip is able to detect such discs (using both the TOC and track subcode) and will apply a correction filter automatically. To check whether the CD contains emphasised audio, you can simply run cyanrip -I and read the printout.

Preemphasis:      <status> <action>

for each track.

status can be either none detected or present (TOC) or present (subcode).

Action may be either (deemphasis applied), which applies a deemphasis filter to the audio (default), (deemphasis forced) which does the same, even if no preemphasis is signalled (can be activated via the -E flag, or blank, which deactivates automatic deemphasis, preserving audio data as-is (activated via the -W flag).

The -E flag can be useful for some CDs, which may have been mastered with preemphasis, but don't actually signal it via the track substream properties.

An incomplete list of releases mastered with preemphasis can be found at this wiki page.

ReplayGain

cyanrip will automatically compute ReplayGain tags and add them to all files while ripping. Note, that this requires to hold all compressed audio data for the entire CD in RAM while ripping, which may be from 300 to 600 megabytes, depending on the output used. Low-power and low-RAM devices can turn this off via the -K switch.

The tags generated are ReplayGain 2.0 compliant, which is backwards-compatible with ReplayGain 1.0. The true peak value is calculated and used.

Paranoia status count

At the end of the ripping process, cyanrip will print and log a summary of cdparanoia's status during ripping. This can be used to estimate the disc/drive's health.

An idealized disc and drive will only log READ: $number$ and nothing else. This happens while ripping from a file. In general READ/VERIFY/OVERLAP are normal and will happen when ripping a brand new CD with a new drive. FIXUP_EDGE/FIXUP_ATOM usually happen if cdparanoia is somewhat struggling, but both are recoverable and lossless. FIXUP_DROPPED/FIXUP_DUPED indicate more severe errors, but are still recoverable and lossless, though a hard read error will often follow. READERR indicates that cdparanoia gave up after all retries and outputted zeroes for all samples it couldn't recover.

Naming scheme

cyanrip supports highly flexible naming schemes via a custom syntax. You can extensively customize how all files and directories are named.

The default naming scheme for albums is Album name [Format] if the releasecomment tag is empty or Album name (Release comment) [Format] if it isn't. For tracks, its Track number - Track title.Extension if there's a single disc in the album or Disc Number.Track number - Track title.Extension if there are multiple. The log file will be named Album name.log in each of the output folders unless there are multiple CDs in the album, in which case it'll be Album name CD1.log for the first CD and so on.

If you would like something different, read on. If for a one-off you'd like to specify a different directory name, you can just use -D Directory and not read further.

The syntax is as follows: everything not inside { or } tags gets copied as-is unconditionally. Everything inside { or } tags is interpreted: if what's inside the tags matches a metadata key, the tag along with its outer brackets is replaced as-is. Otherwise only the tag brackets are removed and what's inside is copied literally.

Conditions are possible and must follow this syntax: {if #token1# != #token2#album name is |album|}. Condition tokens must be wrapped in # tags, and both must exist. In between the 2 tokens must be either > or < or == or !=. If any of the tokens inside the # tags matches a metadata key, it is replaced with a value, otherwise its taken literally (so if the album tag exists, #album# resolves to the album name, otherwise to just album).

If the condition is a direct comparison (== or !=), then the 2 tokens are compared as strings. If arithmetic comparison is used and the 2 tokens are integers, they're compared arithmetically.

If an arithmetic comparison is used when both tokens are strings, the result of strcmp is used. If only one is a string, its pointer (always above 0, unless the token did not match a metadata key, in which case 0) is used.

If the condition is true, everything after the last token's # is copied, with any metadata tags there wrapped with |. Otherwise, nothing is copied.

Examples are easier to understand, by default the folder value of {album}{if #releasecomment# > #0# (|releasecomment|)} [{format}] is used. This resolves to Album [FLAC] if there's nothing in the releasecomment key, or Album (Release comment) [FLAC] if there is.

The default track file name syntax is: {if #totaldiscs# > #1#|disc|.}{track} - {title}. So this resolves to 01 - Title.flac if there's a single CD, or 1.01 - Title.flac if there are more than 1 CDs and you're ripping the first one.

A useful example is to have separate directories for each disc: -D "{album}{if #totaldiscs# > #1# CD|disc|} [{format}]" -F "{track} - {title}".

The ripping log name and location can be modified via the -L argument. By default its set to {album}{if #totaldiscs# > #1# CD|disc|}, which resolves to Album name.log for 1 CD and Album name CD1.log if there are multiple CDs and you're ripping the first.

Filename sanitation

If invalid symbols are found in a file or a folder, such as : or /, the symbol is by default substituted with a unicode lookalike, such as or respectively. If this is undesirable, this can be overridden via the -T simple argument. This will replace all invalid symbols with _. In case you're on an operating system with more liberal allowance on filenames, you can use the -T os_unicode option to allow symbols like : not supported on Windows to be passed through. Note that this will make files like these not accessible on Windows, unless renamed, so use this only if you're sure.

CUE sheet

cyanrip will generate a CUE sheet from which a byte-exact duplicate of the disc can be made. By default, pregaps are kept in the CUE sheet as being appended to the previous track (except for the first track, where the pregap is dropped and signalled as silence). This is reffered to as "noncompliant" by hydrogenaudio.

Custom changes in the way pregaps are handled will be reflected in the CUE file. For example, dropping a pregap will signal silence in the CUE sheet. Appending a pregap to the track will accordingly mark the track as having two audio indices.

Links

You can talk about the project and get in touch with developers on:

cyanrip's People

Contributors

1480c1 avatar cyanreg avatar diizzyy avatar gnafuthegreat avatar neheb avatar rossy avatar s-k2 avatar sebastinas avatar tdaede avatar wiiaboo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cyanrip's Issues

building with GCC in MSYS2/MinGW: assignment of member 'video_codec' in read-only object

logs.zip assembled by media-autobuild suite.
Part of cyanrip-git/build-32bit/ab-suite.build.log:

FAILED: src/cyanrip.exe.p/coverart.c.obj 
"gcc.bat" "-Isrc/cyanrip.exe.p" "-Isrc" "-I../src" "-IE:/MABS/local32/opt/cyanffmpeg/include" "-IE:/MABS/local32/include/neon" "-IE:/MABS/local32/include/libxml2" "-IE:/MABS/local32/include" "-fdiagnostics-color=always" "-pipe" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-std=c99" "-O3" "-D_ISOC11_SOURCE" "-D_XOPEN_SOURCE=700" "-U__STRICT_ANSI__" "-Wundef" "-Wmissing-prototypes" "-Wshadow" "-Wparentheses" "-Wpointer-arith" "-Wno-pointer-sign" "-Werror=implicit-function-declaration" "-municode" "-mthreads" "-mtune=generic" "-O2" "-D_FORTIFY_SOURCE=0" "-D__USE_MINGW_ANSI_STDIO=1" "-pthread" "-DCURL_STATICLIB" "-DLIBXML_STATIC" -MD -MQ src/cyanrip.exe.p/coverart.c.obj -MF "src/cyanrip.exe.p/coverart.c.obj.d" -o src/cyanrip.exe.p/coverart.c.obj "-c" ../src/coverart.c
../src/coverart.c: In function 'crip_save_art':
../src/coverart.c:57:31: error: assignment of member 'video_codec' in read-only object
   57 |     avf->oformat->video_codec = st->codecpar->codec_id;
      |                               ^

Inaccurate message when real release is specified that doesn't contain the current disc ID.

Currently, if you specify a release ID with -R but that release doesn't contain the current disc ID, you get this message:

Release ID c6d1d05f-70fc-4f96-a5e1-caee51432d3d not found!

In reality, the release exists; it just doesn't match the current disc ID. It would be nice if the message could instead read something like:

Release ID c6d1d05f-70fc-4f96-a5e1-caee51432d3d does not contain disc ID w7bUQBPlPF.mlsk9PcNudEa1sN8-.

And maybe offer a URL to add it.

Compiling for aarch64 termux platform

Compiles and installed using:
meson build
ninja -C build
ninja -C build install
Installs without error.

Runtime error:

++ WARN: could not retrieve file info for `image.nrg': No such file or directory
++ WARN: can't open nrg image file image.nrg for reading
Unable to init cdio context

Help solving it is needed

Created directory : lacking permissions ?

Hi,

The directory created by cyanrip during a ripping has permissions : drwx------ .
Would it be possible to have it set those to drwxr-xr-x per default ?
(Not a big deal, just a matter of convenience but my NAS client don't detect new directories with the former set of permissions)

Thanks for the nice piece of software !

Cyanrip is very slow in ripping on some drives (caused by non-continuous read operations)

Hi!

On some drives cyanrip is very slow in ripping. I'm observing this behavior on two computers: cyanrip rips a little, then encodes the little bit it has ripped, reads another bit from the CD etc...; please let me know if this is not intended behavior. I haven't looked at the source code to see if this is actually the case, but I'm judging this by looking at iotop and the percentage reported by cyanrip. Cyanrip is not causing continuous I/O activity, desptite it certainly could (encoding is much faster on recent, modern CPUs than reading off the CD).

While this is not optimal, as these operations could be done in parallel (many rippers do this: rip an entire track, move onto the next one while starting another thread for encoding & tagging), there is another problem: another one of my optical drives has a small (but significant) delay at the start of every separate read operation. This causes ripping to be very slow on this drive! I haven't taken a time comparison, but it is around 4x to 10x as slow compared to some (any) other ripper (using cdparanoia).

On another computer (despite cyanrip behaving exactly in the same way) the CD drive does not have this delay for every read, and ripping is much faster.

Using some other ripping tools this difference goes away between these computers / drives.

Cheers!

Pre-Emphasis support?

Hi, I recently recommended cyanrip in a forum discussion here:
https://forums.slimdevices.com/forum/user-forums/ripping-encoding-transcoding-tagging/1630286-what-cd-drive-for-ripping-cds

Which prompted a discussion about pre-emphasis support, which I hadn't heard of. I haven't read much further on it beyond this article:
https://archimago.blogspot.com/2020/09/how-to-cd-pre-emphasis-and-dealing-with.html

I don't see that pre-emphasis detection (or de-emphasis during processing) is currently supported? Is that correct? Is this something you've looked at before and elected not to support? Thanks!

Update README for default offset

Arguments are optional. By default cyanrip will rip all tracks from the default CD drive with an offset of 0, output to flac only, enables all cd-paranoia error checking, performs a MusicBrainz lookup, and downloads and embeds the cover art if one is found.

By default cyanrip will rip all tracks from the default CD drive with an offset of 0

Should be deleted or reworded because of 04d84d3 ?

Can't force a specific MusicBrainz release ID for an unknown disc

One of my CDs comes up as unknown when trying to rip it:

Opening drive...
Unable to find release info for this CD, and metadata hasn't been manually added!
Please help improve the MusicBrainz DB by submitting the disc info via the following URL:

However, I do know exactly what release it is and I also have the MusicBrainz release ID for this disk.

I thought I could use the -R <string> option to force the usage of a specific release, but this just causes the same error as above. I've had this option work before in a situation where there were multiple matching releases, but it does not seem to work if there aren't any.

Is there any other way I can set the release ID?

Windows crash on unknown discs and error otherwise

Hi.
I am having trouble ripping on windows.
If the disc is in the database, it downloads the covers, and then
Unable to open "(data)": Invalid data found when processing input!
If the disc is not in the database, it just crashes after printing the line
tracks:
With unknown discs it creates the folder and writes an empty log file in there, with known discs it doesn't make the folder.
Any ideas?
Thanks,
Marc

README nitpicks

Hello and first of all, thanks for your project replacing the quite bloated whipper for me.

I've had some problems while reading the manual tagging section of the README:

  1. The double quotes in the -a or -t examples are actually included in the tag values, which makes the examples pretty misleading, as I'm sure most people don't want that.
  2. In the same examples, tag keys don't follow the Xiph Vorbis comments spec (https://xiph.org/vorbis/doc/v-comment.html) where everything in it is all caps. I now wonder if the automatic tagging uses the right keys (only used one CD that wasn't in the database, sadly).

Otherwise, no problem to report.

Add cddb/gnudb support?

Any chance to add cddb/gnudb support for tagging?

There are many Classical albums that do not get identified with Musicbrainz, whereas there are matches from gnudb.

Thanks for any consideration!

Allow specifying MusicBrainz release for disc IDs that show up in more than one release

I'd like the option to specify the MusicBrainz release ID for discs that are included in more than one release. For example, this disc shows up in two releases:

https://musicbrainz.org/cdtoc/mHvDYAXODTuDWZ8prKQhmcg0vYg-

The release affects things like date and label information. Perhaps something like:

--release-id af59aeec-de29-4b15-b04d-89c1f0ed2599

in cases where cyanrip defaults to the "wrong" release for the user's particular edition.

Typo in your README.MD file

Hi. I noticed you have a typo in the README.MD file on the project homepage. It lists the track selection flag as "-l", but it should actually be "-t". Thanks for this software - it's really helpful.

[Feature Request] GUI

Hi.

Yes, I know. N00bs, including me (also allergic to CLI), needs its GUI. I'm trying to use cyanrip for the first time on a disc that gave me issues and... my head hurt just tagging the files. I hate automatic lookups for anything (and the disc is not in MusicBrainz anyway).

Please consider a GUI, at least for Windows where most common folks are. It also help folks like me that are more visual and less "imagine what I wrote down".

I understand that might not be in immediate plans as I would understand that you'd like to get the basic software running.
As I tried tagging with everything in one line... I got a "01 - Unknown track.flac" file despite having wrote -t 1=title="Unshakeable":...

Thank you for considering.

aac gets encoded with 96000hz sampling rate

was wondering if this is the intended behaviour. I saw in the code, that you are looking what the specific codec can do and if its above 44.1 you use that maximum, otherwise fall back to 44.1. Now for an audio cd this seems like overkill. I know that for opus encodes everyone tells you to not mess with the 48, but with aac it seems that using 44.1 like you do with flac wouldnt hurt either. Just a suggestion.

Way to specify disc format (CD/HDCD) in folder structure

I organize my library like: [Year] Artist - Album [DiscFormat FLAC]. Is there a way to name folders like this without manually specifying CDs and HDCDs? I've got the rest down ([{year}] {album_artist} - {album} [CD FLAC] if curious) but can't find an option to specify the disc format. I've tried {format} but that just shows FLAC.

[Feature Request] Easier metadata editing via text file

It would be nice if it were easier to edit the metadata prior to ripping.

What if there were an option similar to -I that would export the metadata (or a blank template) to some sort of text file (JSON might be good for this)?
Then that file could be opened in $EDITOR, changed as needed, and imported into cyanrip with another command line option.

"Unknown disc" is written in "Album" tag.

Hey, I mainly want to check this is the intended behaviour. When ripping some CDs using v0.8.0 their "Album" tags start with "Unknown disc" and the actual title appended on (e.g. Album: Unknown discいくつもの絵). This wasn't the case with v0.7.0 (I've downgraded and confirmed). Commit db18b53 seems to be where the change occurred.

If this is the intended behaviour, do you mind telling me where I can correct this in MusicBrainz?

Thank you.

[Feature Request] autoloader support

A few autoloaders on the market allow the processing of a stack of discs (FIFO), like the Acronova/Datatronics Nimbie and Primera. It would be very helpful to implement/document a procedure to use autoloaders with cyanrip.

Windows version outputs to wrong folder

Hello. I wonder if there is a problem with my command. This is what I used:

cyanrip.exe -d D: -D "C:\Users\sduell\Desktop\Converted CD" -t 01 -o mp3 -b 256 -f -n

When the conversion is complete, I find "C:\Users\sduell\Desktop\Converted CD" is empty, but there is a new folder created called 'Converted CD [MP3]' instead, and the converted file is in there. How can I make cyanrip output only into the folder I specify in the command, rather than into a newly generated one?

I'm using cyanrip version 0.1-rc2 on a Windows 10 box.

Thanks for your time.

MinGW, GCC: Multiple deprecation warnings and cyanrip_encode.c.obj fails

I tried to build cyanrip using the media-autobuild suite which usually worked well but now fails; apparently cyanrip uses an ffmpeg API which is now deprecated.

The suite collected several log files while building, this archive should contain all details you may need, hopefully.

It is a set of Windows batch and Unix shell scripts which automate building Windows targets of ffmpeg or similar software and embedded codec libraries, keeping itself up-to-date in an MSYS2/MinGW environment.

Unofficial tag names for MusicBrainz release/recording ID's

Running the current latest nightly build for Windows (cyanrip-win64-20230714-55cd5d.exe)

I notice by default, cyanrip embeds MusicBrainz release ID's into track tags as release_id instead of MUSICBRAINZ_ALBUMID and recording ID's as mbid instead of MUSICBRAINZ_TRACKID. While I fully approve this data being stored, using unofficial tag names means MusicBrainz Picard doesn't automatically load the release when the files are dragged in. This makes re-tagging afterwards with a different edition more tedious.

Multi-disc collections use the same album title for all discs instead of per-disc titles

I have some multi-disc collections that are listed under a single release in MusicBrainz, but each disc has its own title because it's an individual album within that larger box set. For example, this Talking Heads collection where each disc is a separate album:

https://musicbrainz.org/release/56d295fc-84fb-4f17-aa78-c53249cf44bd

morituri/whipper (as an example) shows separate album titles for each disc and uses those in metadata and folder names, e.g. "Talking Heads (Disc 1 of 16): Talking Heads: 77". cyanrip just uses "Talking Heads" for the album title for all discs, so the individual album titles don't show up in folder names or metadata. Ideally, I would like for the album title to reflect the disc title, e.g. "Talking Heads: 77", and forego the collection title altogether. Otherwise, the way morituri/whipper does it at least keeps the per-disc titles even if it's a little verbose.

Is there a way to see whether MusicBrainz has disc titles for a release and then use those instead of the overall album/collection title when present? I don't know what fields MusicBrainz provides externally, and I may be using the wrong terminology here.

I see @tdaede contributed at least some of the current MusicBrainz code, so I don't know if they'd have some insight into how this could be improved. Please let me know if there are specific logs I can provide to help identify what's going on.

encoding failed

I am compiling cyanrip via the media-autobuild script on windows (so mingw). This worked in the past reasonably well, but now I got a suspiciously small file (only 6MB compared to the old one working with 47MB). Running it seems to work until the programm gets to the encoding part after ripping; here it always says "encoding failed" no matter what coder I try and I end up with a tiny file. Opening reveals that it only has some meta data in it, but nothing more.

I tried to compile it myself on the shell by going by your instructions, but ninja gives me this and I have no clue how to get rid of that double mentioning, so maybe you could give me a pointer?

$ ninja -v -C build ninja: Entering directory build'
[1/4] gcc @src/25a6634@@cyanrip@exe/cyanrip_log.c.obj.rsp
[2/4] gcc @src/25a6634@@cyanrip@exe/cyanrip_encode.c.obj.rsp
[3/4] gcc @src/25a6634@@cyanrip@exe/cyanrip_main.c.obj.rsp
[4/4] gcc @src/cyanrip.exe.rsp
FAILED: src/cyanrip.exe
gcc @src/cyanrip.exe.rsp
C:/ffmpegbuild/local64/lib/libsrt.a(md5.cpp.o):md5.cpp:(.text+0x890): multiple definition of md5_init' C:/ffmpegbuild/msys64/mingw64/lib/libssh.a(libcrypto.c.obj):(.text+0xa30): first defined here collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed.
Although I am not even sure I should be able to compile that manually without other stuff going on in the main script, because if I remove the .exe the media-autobuild script created somehow, my manuell try does not give me the crippled version, so I was wondering if you rely on external programs now with 0.2.0 and ffmpeg and the mentioned libraries have to be present in the same directory or something like that for cyanrip to work properly?

For reference, the version I managed to build and which does encoding ist ce3cc0d-git

CUE file writing?

Just adding this as an issue to get some feedback.

Would users like to see CUE file writing added as a feature?

If so, why?
CUE files only support a single source file, but cyanrip always rips all tracks out separately. So CUE files are not useful for playback.
For creating identical duplicates of CDs? Most ripping programs by default cannot create exact duplicates, as the pregap of the first track is usually stripped. cyanrip also behaves like this by default. If you concatenate all tracks written, you will get the entire exact audio and offsets with some math and the logfile. CUE files still only support a single source file, so it's not that useful.

Accurip found but also not found

    Accurip:          found (max confidence: 2)
    EAC CRC32:        0D28EDC4
    Accurip v1:       0C0BF6BD (not found in the Accurip database)
    Accurip v2:       A34CF5D9 (not found in the Accurip database)
    Accurip v1 450:   48D78CE5 (not found in the Accurip database)

Accurip result returns "found (max confidence: 2)", even though both v1 and v2 returned "not found in the Accurip database"
This happens with all the tracks on the CD.

Before this I ripped another CD not present in the database, and it didn't have this issue. Main difference is that one also wasn't in MB's db, so it was ripped as Unknown disc. The former disc is also badly damaged and unable to rip properly.

    Accurip:          not found
    EAC CRC32:        7E5A37B0
    Accurip v1:       5D99F435
    Accurip v2:       C061540D
    Accurip v1 450:   EE8483F9

ReplayGain support

Adding this issue as a question for users:

Would you like to see ReplayGain metadata generation supported?

Support for CTDB

CTDB has some advantages over AccurateRip, including the potential for repairing bad rips. It’d be nice if cyanrip could optionally support CTDB

  • Verification
  • Repair
  • Submission

I don’t really understand the technical side of this; it might or might not be possible without also doing the majority of the work required for ripping the whole disc as one file instead of one-file-per-track.

[Feature Suggestion] Display disc ID when a rip "fails" due to multiple release IDs.

When ripping a disc with multiple MusicBrainz release IDs and no release specified, the rip stops and cyanrip helpfully displays the available release IDs. It would be nice if the disc ID was shown as well in the event a user feels none of the current releases match their disc and they want to add it to another release in MusicBrainz.

Currently, you'd need to specify one of the available release IDs to start a rip long enough to see the discid listed in the opening output.

[Feature Request] Some log enhancements

  1. Peak levels (along with the sector information, called Start/End LSN in cyanrip) are useful for determining differences between different pressings of the same album.
  2. Pre-gap length is the pause/silence before a track and it can also help differentiate between different pressings of an album.

How other rippers show this info:

EAC example:

Track 11

     Filename C:\Folder\11 - Track.wav

     Pre-gap length  0:00:20.00

     Peak level 99.8 %
     Extraction speed 4.4 X
     Track quality 100.0 %
     Test CRC 6FAFABD1
     Copy CRC 6FAFABD1
     Accurately ripped (confidence 3)  [C2C18BA2]  (AR v2)
     Copy OK

XLD example:

Track 06
    Filename : /Users/Username/Folder/06 Track.flac
    Pre-gap length : 00:06:57

    Track gain               : -5.11 dB
    Peak                     : 0.996552
    CRC32 hash (test run)    : CDE2B054
    CRC32 hash               : CDE2B054
    CRC32 hash (skip zero)   : AA576BE0
    AccurateRip v1 signature : 6F06FDEE
    AccurateRip v2 signature : 0A3A418F
        ->Accurately ripped (v1+v2, confidence 2+5/7)
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Title metadata should use track title instead of recording title

At the moment the title is read from the MusicBrainz record title if present. I think it would make more sense to use the track title in every case instead.

The reason for this is that MusicBrainz allows one record to have multiple tracks in different albums and the track title of the album might be different than the recording title. So in my opinion it would make sense to have the track title as listed on the CD / booklet instead of the recording title which might be different.

(Thanks for the great software btw, it works really well :) )

Add (lib)fdk-aac support?

Unless I'm reading the code incorrectly it doesn't seem to support this library at all via ffmpeg, as it is superior it would be nice if it would be an option and/or possible default one.

Malformed disc ID and submission URL for PlayStation disc with audio tracks.

I seem to get an invalid disc ID when I try to rip a PlayStation disc with audio tracks at the end. For example, disc one of Lunar gives me this:

https://musicbrainz.org/cdtoc/attach?toc=1+3+261488+246922+258219&tracks=3&id=.A8KH4tSiiHfbJzXPyWJghuCyOY-

I also tried running cyanrip on a cdrdao rip of the same disc, and I got a different TOC and disc ID:

https://musicbrainz.org/cdtoc/attach?toc=1+3+261338+246772+258069&tracks=3&id=buK8JSCWgFudBEX4H6Ye4KxLQ3E-

Passing -n to get a quick rip going did rip and encode the audio tracks, and I'm attaching the log from that.

I would consider this very low priority--I'm certainly not planning on ripping the audio tracks from my PlayStation games anytime soon--but I thought it could potentially point to a more serious issue, so I wanted to log it. Here are some pages with release information for this game:

https://musicbrainz.org/release/a1f8bb08-ec5c-4ae5-af4d-7576b8c4af90

http://redump.org/disc/2676/

lunar-d1.log

mp3 rips are monaural (when built from master)

I just compiled cyanrip from master's HEAD (daf8161)
Ripping a cd using e.g. cyanrip -o mp3 -b 192 -s 667 results in mono mp3 files:

$ file 01.mp3
01.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, Monaural

I tried with a different format (FLAC), which gave stereo files as expected.

I retried compiling cyanrip from tag v0.9.0 which works fine.

Tested on Fedora 38.

Some discs have more than one "good" result in AccurateRip database.

It appears that some discs have more than one "good" result in the AccurateRip database. These seem to be given a confidence rating based on how many people have submitted that particular set of checksums for that particular disc. cyanrip appears to only compare against the result with the highest confidence, where whipper appears to be able to compare against lower confidence results when the highest confidence result doesn't match. That may also be entirely the wrong way to describe what's going on, but it's how I've come to understand it.

Attached are a couple examples of logs from both cyanrip and whipper to show how they report a different confidence rating and how cyanrip reports "inaccurate" where whipper reports "accurate". You can see the checksums match between the two programs, so they're definitely getting the same results from the disc.

I'm sure AccurateRip's database isn't the most accessible, so I don't know how complex a "fix" for this would be. I just wanted to log it in the hope that the AccurateRip lookup can be improved in the future. Please let me know if I can provide additional information about specific discs that present this behavior.

gordon-cyanrip.log
gordon-whipper.log

Please Verify SPDX License Identifier

Hello, I am packaging cyanrip for Alpine Linux and they prefer that the license be from the SPDX License List when possible. Can you clarify which I should use:

LGPL-3.0-only
LGPL-3.0-or-later

I've read the license you link to and I believe "LGPL-3.0-only" is the correct choice but just wanted to make sure. Thanks.

[Feature Request] CDtext in MusicBrainz upload link

When a given discid does not exist, Cyanrip will helpfully generate a link to create the release in MusicBrainz. I'm wondering if it would be possible to also scan the disc for CDtext and send that along with the TOC to MusicBrainz ?

Edit: I'm currently re-ripping the entire collection and already encountered a couple that weren't in MB. If I encounter more and they have CDtext I'll set them aside for testing.

Track Numbering for Mixed Mode CDs

One of the CDs used for testing deemphasis support was the original 1996 Quake CD which is a mixed mode game disk with track 1 being data and the audio tracks starting with track 2, which cyanrip by default names accordingly, so the first ripped audio track gets the filename 02 - Quake Theme.flac.

This is probably a bit of an edge case that could be fixed by using a custom file name scheme (haven't tried yet) but maybe it makes sense to default to only numbering audio tracks and ignore data tracks?

I'm not really sure this would even be the right thing to do. Depending on where you look, the Quake Theme is either track 1 or Track 2 in the listing:

https://www.discogs.com/release/9447246-Nine-Inch-Nails-Quake
https://www.nin.wiki/Quake_Soundtrack

It's disconcerting to be "missing" track 1 when browsing through your audio collection though, it just doesn't look right.

Cd's gets encoded to 24-bit

Hello,

Ripped cd's to alac today, the output gets encoded in 24-bit if using the -o alac argument.
It works fine if using -o flac argument.
Rips get stuck after first track if using -o wavpack argument, the messege is flushing encoders.

[Feature Request] Utilize the Disambiguation information from MusicBrainz.

Some releases on MusicBrainz include information in a Disambiguation field to denote things like special editions or anniversary re-releases. It appears some rippers just include this information on the end of the album title. Here are examples of some such releases:

Weezer have released six self-titled albums to date. To differentiate, the traditional addition to the album title has related to the album cover's color. So we have "Weezer (Blue Album)", "Weezer (Green Album)", etc. MusicBrainz stores those extra titles in the albums' respective Disambiguation fields and displays it on the release page in parentheses after the main title. Another extended example of this within Weezer's catalog is something like this, which is the "Deluxe Edition" of the "Blue Album".

Another example would be the 25th anniversary releases of Paul Simon's Graceland, like this.

I'm not sure of the best way to handle this information. I personally don't mind including it in the album title, but that is perhaps less "correct". The issue with not including it in the title is that you might have all of the albums titled "Weezer" listed under the same album in a music player. Otherwise, perhaps just pulling in this information and including it in the metadata so it's there would be nice.

In the meantime, a user can simply override the album title and include this information however they see fit. I just wanted to document this case.

Metadata query generates a lot of noise

cyanrip -d /dev/cd0 -s 618 -I

Checking /dev/cd0 for cdrom...
                CDROM sensed: BENQ     DVD DD DW1650    BCIC


Opening drive...
Unrecognised disc element: 'offset-list'
Unrecognised artist attribute: 'type-id'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised artist attribute: 'type-id'
Unrecognised release element: 'release-event-list'
Unrecognised release element: 'cover-art-archive'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised disc element: 'offset-list'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Unrecognised track attribute: 'id'
Unrecognised artist attribute: 'type-id'
Multiple releases found in database for DiscID wTkS6G6kcY9_cjK10YVBYSVuzD4-:
    1 (ID: 08dade63-5fa5-4860-9c60-43b445862ccd): Head Over Heels (1995)
    2 (ID: 5a52c85d-2dcc-33cd-83cf-04fa0487177c): Head Over Heels (1995-06-16)

Please specify which release to use by adding the -R argument with an index or ID.

OS: FreeBSD 12.1-RELEASE-p9
Cyanrip master branch, commit fe03e2e
libmusicbrainz 5.1.0
(lib)curl 7.72.0
libcdio-paranoia 10.2+2.0.1

Great software! Keep up the good work!

Don't embed cover

cyanrip by default both downloads the cover to the output directory and embeds it in every each flac file.
A lot of covers are upwards of several MB in size and this can result in a significant total size increase (e.g. 3 MB size cover for 15 tracks will result in 45 MB additional size, which could make up 10-15% of the total size).

There should probably be an option to select between embedding cover, only downloading to a file and not downloading cover at all.

Windows/MinGW stopped working with meson rebuild

Just leaving this here as a reminder/to-do.

1 - musicbrainz5 needs static: True to get additional libs
2 - port wmain/unicode check from waf to meson
3 - meson doesn't deduplicate pkg-config -L/-l options and doesn't accept pkg-config wrapper scripts

Disc unknown in MusicBrainz gets ripped as album_artist/album

I noticed today that a disc was not recognized (did not show title, artist etc) but still ripped. When I went to inspect the log, I found that there were a lot more mp3 files than I had allowed it to rip, and they were older.

I identified them by sound and tried again with that disc, too - both are unknown in MB. When using Picard to start entering the data, however, I found for both discs that there did exist a stub.

My guess is that the MB API return for "does not exist but has a stub" is sufficiently similar that the CyanRIP code continues ripping with the default variable contents.

[Feature request] Configuration file support

First of all, I want to thank you for providing an excellent tool that has now become my de facto replacement for ripit. It's fast, it's good, and it does everything I want. Well, almost, or I wouldn't be making RFIs :-)

It would be nice if Cyanrip were to support configuration files - preferably the usual cascade of them in /etc > ~/ > $PWD. Right now I've configured my defaults using an alias, but that's comparatively more clunky to manage as well as not being very intuitive.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.