Tag sources: isn't MP3Tag supposed to read Audio-CD?

I'm just exploring how MP3Tag can obtain tag data for a CD. As I understand it you're supposed to put a CD in the drive, and MP3Tag reads it (like Audiograbber would) and goes up to FreeDB (or GNUDB now) or accesses a local version of the FreeDB database, and populates the presented information (just like Audiograbber would certainly do, I am guessing).

I've never used this functionality before now. But tonight I decided to try it (since finally I now also have a local version of the FreeDB database in compact Windows-form). And nothing happened. MP3tag never read the CD that was in the drive, or did anything!

Am I supposed to do something to make this happen? Or is it just supposed to happen by itself when you launch the program with a CD in the tray already, or if you insert a CD later after the program is already open?

Is there a "read CD" action or button or something??

Please point me in the right direction.

If you open Tags-Sources>Freedb ...
the you can use the option to get the ID from the inserted CD.
You would need to have converted the CD tracks before to a suitable file format.

I don't follow. Or something else is not right.

I have a CD inserted right now, and when I select Tags-Source from the Menu Bar the dropdown shows the freedb items grayed-out.

Is that what you wanted me to use?

Yes. You have to configure the freedb access first.
See Tools>Options>Tag-Sources>Freedb and ...>Local freedb.

I've already done that. And I've pushed the "create local index" button and that went fine.

And you have to select at least 1 file in the files list.

What is a "files list"?

I call it that way. It is the table where a list of loaded files and some of their properties are displayed. The default is that the files list is to the right of the tag panel (which you can show and hide with Ctrl-Q to see what I mean), below the toolbar and above the filter input box.

Sorry, I don't understand what you're saying.

Here is my window. I can show/hide the tag panel on the left using CTRL+Q as you say. But what does that have to do with anything? The rest of the window is blank. Isn't it supposed to populate with the tracks from the inserted CD? Or am I not understanding what this functionality is supposed to do?

I'm not opening a folder with MP3/FLAC files in it, which of course does populate the main window area with all of the files in that folder. I was expecting the tracks of the inserted CD to appear here automatically, exactly as happens when you run Audiograbber or EAC. Am I misinterpreting the functionality?

If the window is empty then you cannot select a file in the files list and all tag-related functions are not available.
As I said:

and then load them into MP3tag.
And then tag them - perhaps with data from the local freedb. Or a different tag source. Or just add data manually.

Well now you've really lost me. I didn't understand what you said when you said it earlier, and I still don't understand it now.

What does "converted the CD tracks to a suitable file format" mean??

And what does "load them into MP3Tag mean"?

Are you saying that, for example, I need to use Audiograbber to do exactly what it does right now... except to NOT use FreeDB (cloud or local, or GNUDB) automatically in order to get the tag data at ripping time. Instead, leave all the album/artist/track etc. data blank, and just rip the files to MP3 or FLAC as usual. Unnamed except generically "Track 1", "Track 2", etc., and with no tag data populated inside the files. But the files are placed in a folder, same as they always would be (normally \Artist\Album) but simply with no names on the tracks, placed in some folder.

And then I point to that folder in MP3Tag, same as I always would normally where the data is already pre-populated probably correctly by Audiograbber, and I just maybe want to review and/or edit genre or year or something. That's why I opened the pretty much perfect result out of Audiograbber in MP3Tag. So in this case, I'm now pointing to an identical looking folder but with generic track names and no tag data pre-inserted.

And NOW, MP3Tag can be used to populate the tag data, same as Audiograbber would have had I not prevented it from doing so for this experiment?

And then I need to use MP3Tag to CONVERT and rename the files from the tag title??

Is that what this functionality is meant to do??

Yes, more or less.
freedb has a record of really poor data quality and is more or less a leftover from the very early days of tagging.
That is why there are already other tag sources on offer.
If you have a program that already adds the data that you find suitable, then continue to use it.
However, you will find that tagging with freedb as source will probably lead to very variable titles for albums with several CDs, genres won't fit, special characters don't match, artist names vary esp. if they have a "the" in the name etc.
And for all these tidying up tasks you may use MP3tag, but there is no obligation.

Ok. I've now experimented doing exactly what I described above.

I used Audiograbber to rip the first two tracks off of a CD that is inserted. I erased the otherwise obtained correctly data about the CD, and created a "Test Artist" and "Test Album", with "Track 1" and "Track 2".

I then opened MP3Tag pointing to the \Test Artist\Test Album folder, and as expected the two tracks are there.

I then selected the two tracks, and let Audiograbber do its thing. It created the two tracks in the specified target folder.

I then went to MP3Tag and opened that folder. I then selected the two tracks, and clicked on Tags Sources. And now sure enough the FreeDB and local FreeDB items were no longer grayed out. I selected "local FreeDB" where my newly created 6/1/2020 local Windows-form database now lives. I was presented with a dialog where I clicked on "develop FreeDB disc ID from inserted CD" and pushed NEXT.

Apparently this worked, and I then was presented with a multiple-choice selection dialog (as this CD exists in FreeDB three times):

I selected the first one, and then pushed the PREVIEW button:

Looks good. I then pushed NEXT and was presented with the retrieved information from that FreeDB DISCID entry now inserted into the corresponding tag fields, as well as matching up against the track list. I didn't know what to do now, but simply selected the first two tracks on both sides.

And then I pushed OK, and apparently all of the tag data was correctly assigned to the corresponding fields of the tags in these two tracks. As I suspected, everything in the tag fields was populated, but the external file name was left exactly untouched.

So I would now than use CONVERT -> Tag - Filename and set it up to rename the files to match the title, or whatever.

Ok. I would naturally NEVER use this workflow. I have Audiograbber and all of this would be done automatcally at the time of ripping, not after-the-fact here. Audiograbber has access to FreeDB online, or local FreeDB database offline. And now it has been updated to recognize the death of FreeDB, with the latest 2020 version now accessing GNUDB which is the natural successor to FreeDB. But I believe GNUDB has the same data, and possibly the same data issues as FreeDB had.

Or, I can use EAC which uses MusicBrainz as its successor to FreeDB. MusicBrainz is more robust and accurate than FreeDB/GNUDB, and contains more data per CD. But it requires that the client program be modified since it's not the generic universal FreeDB Protocol query that must be used, but rather the proprietary MusicBrainz client interface.

Anyway, I think I now understand what this MP3Tag functionality is all about, and how it works. I would, of course, never use it. But I've now learned all about it.

Thank you very much for the guidance.