Bug 1916974

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.