Created attachment 1748056 [details] suggested patch for abcde default configuration file Description of problem: Comments in a configuration file for abcde suggest using freedb.org. Unfortunately this is no longer available but gnudb.org may serve as the current replacement immune to aquisitions. It seems to me that patching a configuration file accordingly would be a nice move. Something like an attached patch. Version-Release number of selected component (if applicable): abcde-2.9.3-5.fc33 Additional info: I did not figured out how abcde is supposed to get musicbrainz data, which looks like a default, but I was not getting from there anything usable. OTOH sound-juicer, which is presumably using musicbrainz too, did not have that problem with the same CDs. Configuring abcde with CDDBMETHOD=cddb and pointing it to http://gnudb.gnudb.org/~cddb/cddb.cgi solved for me that issue.
Are you referring to the commented-out options at lines 18 and 30 of /etc/abcde.conf? Indeed, they do refer to freedb. However, the default is to use musicbrainz backend via the /usr/bin/abcde-musicbrainz-tool script. It's documented in the manpage: ... CDDBMETHOD Specifies the methods we want to use to retrieve the track information. Three values are recognized: "cddb", "musicbrainz" and "cdtext". List all the methods desired in a comma delimited list and abcde will attempt them all, returning a list of all search results. The "cddb" value needs the CDDBURL and HELLOINFO variables described below. The "musicbrainz" value uses the Perl helper script abcde-mu‐ sicbrainz-tool to establish a conversation with the Musicbrainz server for information retrieval. "cd‐ text" needs "icedax" or "cdda2wav" to be installed. ... No configuration is actually necessary and CDDB lookup via musicbrainz should work fine out of the box. I've just tried ripping a CD and it worked. Maybe the data for your CD is not available in the database? Try: /usr/bin/abcde-musicbrainz-tool --command data --discid $(/usr/bin/abcde-musicbrainz-tool | cut -d' ' -f1) --workdir $PWD && cat cddbread.1 with your CD in the drive. If you want to provide a patch to point the comments in /etc/abcde.conf to the correct URLs, I'll be happy to forward it upstream.
(In reply to Dominik 'Rathann' Mierzejewski from comment #1) > However, the default is to use musicbrainz backend via the > /usr/bin/abcde-musicbrainz-tool script. As I wrote in the original report: "I did not figured out how abcde is supposed to get musicbrainz data, which looks like a default, but I was not getting from there anything usable". Only after initial failures in a default configuration, and with multiple disks (one or two particular CDs may be not present in a given database) I started to experiment with other methods and eventually, after a web search, I was directed to gnudb.gnudb.org which worked at last. > No configuration is actually necessary and CDDB lookup via musicbrainz > should work fine out of the box. That was my impression too but I was seeing only "Unknown" and "Track1, Track2 ..." no matter which CD I tried. > Try: > > /usr/bin/abcde-musicbrainz-tool --command data --discid \ > $(/usr/bin/abcde-musicbrainz-tool | cut -d' ' -f1) --workdir $PWD && cat \ > cddbread.1 > > with your CD in the drive. MusicBrainz lookup returned an error "Not Found" on multiple CDs for which I got an information from gnudb.gnudb.org. I actually tried something like that before (even if I was not entirely sure what is 'discid' in data returned by abcde-musicbrainz-tool) when I attempted to figure out what is failing. Although I have to admit that eventually I found some disks for which your command was successful. In case of failure, and despite of ' && cat ...', the above shows data for the last CD which was found. > > If you want to provide a patch to point the comments in /etc/abcde.conf to > the correct URLs, I'll be happy to forward it upstream. OK, a bit later.
(In reply to Dominik 'Rathann' Mierzejewski from comment #1) > If you want to provide a patch to point the comments in /etc/abcde.conf to > the correct URLs, I'll be happy to forward it upstream. Wait a minute. What is wrong with a patch I atteched to the original report?
(In reply to Michal Jaegermann from comment #3) > (In reply to Dominik 'Rathann' Mierzejewski from comment #1) > > > If you want to provide a patch to point the comments in /etc/abcde.conf to > > the correct URLs, I'll be happy to forward it upstream. > > Wait a minute. What is wrong with a patch I atteched to the original report? Nothing at all. My apologies, I haven't noticed it at all! Thanks for the patch, I'll apply it to the next build!
FEDORA-2021-969c6aeebe has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-969c6aeebe
FEDORA-2021-95c8cfa5fe has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-95c8cfa5fe
FEDORA-2021-969c6aeebe has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-969c6aeebe` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-969c6aeebe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-95c8cfa5fe has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-95c8cfa5fe` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-95c8cfa5fe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-969c6aeebe has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-95c8cfa5fe has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.