cyanreg / cyanrip Goto Github PK

    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

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.

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.

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?

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.

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.

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

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.

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!

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;
      |                               ^

Adding this issue as a question for users:

Would you like to see ReplayGain metadata generation supported?

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

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.

Thanks for enhancing the metadata into the logfile in the latest release! It would be great if also Catalog Number and Label was added, thank you.

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 ?

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

Earlier this year GitHub announced that generated source archives are only stable for a year, this will likely cause major issues for anyone trying to package Cyanrip longterm. Please consider uploading release source code archives.

Reference:
https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/

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.

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.

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.

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.

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.

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.

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 :) )

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.

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 !

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.

This appears it should be skipping entry_size - (tell() % entry_size)

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

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.

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

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.

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

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.

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.

Hello,
I don't understand nor see how I can choose the encoding (MP3, opus...) in the only help manual there is, aka "cyanrip -h"
Slight Request for enhancement then: dedicate a whole line to this in the help manual :)
Thank you

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!

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.

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.

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!

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.

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!

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.

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.

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.

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

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.

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.

The new preemphasis logs show deemphasis forced when it was not forced.

I think cyanrip_log.c:85 should check settings.force_deemphasis

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.