MariaDB - MySQL

General Discussion
1

Hi Florian,

First of all, thank you for Mp3tag — it has been a core part of my music workflow for many years and remains unmatched for metadata editing and bulk operations.

I wanted to raise a feature request for consideration, aimed primarily at advanced users with large libraries.

The use-case

Some of us maintain large, long-term music collections where Mp3tag acts as the authoritative editor, but where we also want to:

  • Run analytics and reports (e.g. release trends, labels, years, genres)

  • Cross-reference data with other systems (media servers, dashboards, scripts)

  • Preserve historical snapshots of metadata over time

A relational database such as MariaDB / MySQL is well suited for this, but currently requires custom export scripts and external tooling.

Suggested improvement (optional / advanced)

An optional database integration layer, for example:

  • Ability to define a MySQL/MariaDB connection (host, db, user)

  • Map Mp3tag fields to table columns

  • Push updates on demand (or via action)

  • Read-only mode for lookups / validation could also be useful

This would not replace Mp3tag’s file-based model, which is absolutely the right default — but would provide a powerful extension point for users who already operate databases.

Important constraints (to keep scope reasonable)

  • Entirely optional (off by default)

  • Clearly positioned as an advanced feature

  • No requirement to support database-first workflows

  • Even a one-way export / sync would be extremely valuable

Why MariaDB / MySQL specifically

  • Widely used, open-source, and stable

  • Common on NAS devices and home servers

  • Easy to integrate with reporting tools and scripts

  • Long-term storage without touching media files

I completely understand that this is non-trivial and may not align with current priorities — but I wanted to share the idea, as Mp3tag already sits at the perfect point in the workflow to make this kind of integration uniquely valuable.

Thanks again for an excellent piece of software, and for continuing to support it so thoughtfully.

Best regards,
Meo

2

Hi Meo,

thank you for your suggestion and the kind feedback on Mp3tag. Unfortunately, a built-in MariaDB/MySQL layer is not planned.

You could use Mp3tag's export feature to export metadata and file information to text files that can then be imported into a database.

3

Hi @meomizzle interesting timing on your post. I’ve long wanted to be able to store more info about my music (approx 50,000 tracks). MP3Tag is an amazing tag editor, but it’s not designed (nor are tags in general) to store the type of info I want, nor to analyze your files.

So I decided to learn MS Access, and create my own database. I’ve been working on this about two months. I’ve learned how to export tags out, import data in, and create the basic tables I need. I’ve actually got a working database of my files, but it’s still in test mode until I work out all the bugs, and add more features. I hope to have the final working DB up by month end.

4

For future readers, just as an idea:
Another option would be to use a tool designed for collecting and managing music.

These tools often use an SQLite database to read and store all the tag information.
Such a tool will significantly reduce the time you need to spend managing your database (reading new tracks, updating existing informations, deleting no more existing tracks.)
You only need to write your own SQL-queries for your database to answer questions like "How many ABBA albums do I own?" or "How many of my music files are in MP3 or FLAC format?" or any other counting queries like "How many Labels/Genres/Covers/Lyrics etc do I already have in my collection?"

5

I am still looking for that feature that MP3tag cannot offer in respect to querying the data that can be done with an external database and for which it is worth the hastle of importing and updating the database each time something changes in the actual files.

Could be answered with a filter plus an export that loops through the artist and uses $loop(%album%,1) - the preview would show the result.
Admittedly, one would have to load the whole collection into MP3tag which would probably take longer than to load only a database.
But as I can never be sure that the data in the database is the same as in the files, the quickly presented results cannot be relied on.

As soon as a real relational database with several tables that are linked together have been created, the updating process becomes increasingly complicated to avoid duplicates, find out the new entries, link e.g. the artist from the artist table with the artist field in the individual track.
Would each track get its own ID so that e.g. INVOLVEDPEOPLE can be linked properly and I can query the database in which files I have Wynton Marsalis on trumpet? (something that also MP3tag would show with the filter function)

But I am open to learn, that is why I ask.

6

I can only answer for me…

I want to store info such as “First time listened”, “last time listened”, rating, listen comments, “don’t have but want”, “Bootleg y/n”, “Add this to my ‘want to listen’ queue”, and many more. This is info that makes no sense to store in tags. And I’ve researched dozens of music collecting programs, and none offer what I want. Most music programs are designed to track the music you own. My needs are very different.

I’m very active in a music forum, and it’s common to have a thread for each album release. I want to be able to store that URL, so I can go right to it.

Additionally, I have no interest in the tracks of the album (which almost every program is obsessed with). I only care about the album itself. I also have multiple versions of many albums (original, remastered, bonus editions, bootlegs, etc), each of which I want to track. Most programs fail miserably at that. The closest is the site Discogs, but Discogs doesn’t let you add much personal info.

I also have a lot of bootlegs, which aren’t handled well by any program. And a lot of Box Sets, where I need to track my info (as listed above) for each part of the BS, which no program does.

And finally, I don’t add that much music on an ongoing basis. Maybe 3-5 a month, plus the occasional box set release. It’s easy to add them when needed. The vast majority of what I listen to already exists, and is meticulously tagged, so the one-time export/import will work. And it’s rare to change an existing record.

Hence… my own database. I realize my case use is unique, which is why I tried every program I could find, then decided to write my own.

I really tried to find a way to make Tags work, as I love MP3Tag, and this new program will NOT lessen my need for it. But Tags just aren’t designed for this.

7

BTW, at this time, I only plan on three tables. It’s a simple, yet detailed, database.

Album Table

AlbumArtist Table

BoxSet Table

I’m also storing the path to the folder. I can use that to display the cover in my forms, without actually storing the cover image.

I also don’t care who the artists are on a song for my DB, since I’m not storing track info. Typically, I store that in the Tag, under Artist, for example “Taylor Swift feat. BoomDaddy”. But I do care about the AlbumArtist, Taylor Swift in this case. That field is being exported.

I rec’d a lot of help and info from @ohrenkino a couple months back about exports, and the diff between Artist and AlbumArtist.

8

Just an idea:
I think that each ARTIST, ALBUMARTIST, COMPOSER, TITLE, ALBUM, Instrument, Role (and other entities like label, genre and many more) would have to get a separate table.
Most of them would have to get a unique ID and 1:n relations between each other.
1 ALBUMARTIST could have n ALBUMS
1 ALBUM could have n TITLEs
1 TITLE could have n ARTISTs
1 ARTIST could have performed n TITLEs which could appear on n ALBUMs
and on 1 TITLE several other artists could appear as INVOLVEDPEOPLE which in return would mean that 1 ARTIST could play several instruments (including vocals) and be also the producer and/or lyricist. And so on.
This mesh of relations would have to be filled with each update.
And that would be the effort for which I see only very little benefit. But it may not match your requirements.
But even as a sort of notepad to get a list of albums

would need to fill in the details to avoid typos and duplicates.
The database in itself may be useful on its own.
Yet, right now it looks to me as though you have to handle the same data in at least 3 programs: MP3tag, the database and the player (and possibly a network browser). I wonder if one could be left out: the database.

BTW:

are attributes that the plug-in for FOOBAR2000 "Playback statistics" fills automatically - and puts it into the tags as it is a feature of this particular file.
If you

you could store the URL in the standard field WWW and use a tool from within MP3tag to call the network browser to open that address...

Comments could be added to user-defined fields or the standard COMMENT field ...
These suggestions all under the aspect of reducing data redundancies and the multitude of programs.
I don't want to spoil your database project, though.

9

Lots of interesting ideas…

I’m not storing Track or Artist info, which removes all of the above except AlbumArtist>Albums. Which I do have in related tables. One to many.

“Don’t have but Want” is actually the same as any other record (database record, not album record), with the exception of a single Yes/No field that would be checked. Once I acquire it, I’ll uncheck it, and update any fields that might be off. I currently use an Excel spreadsheet to track my wants & wishes, this will enable me to eliminate that by integrating it into my DB.

My music player (Musicolet) stores no data for me, and that’s how I want it. I move music to it when I want to hear it, and delete it at some point. I update another Excel spreadsheet with date listened, rating, comments, etc. This will eliminate that spreadsheet also.

I appreciate the feedback, it’s continually pushing me to make sure I’ve thought everything thru.

10

Is used databases for my physical music collection for decades, starting with Superbase (Commodore C64), dBase (DOS) and last MS-Access. (Windows). If you have physical media this still makes sense. Using a database was the only way to gather details of my media.

Since the invention of music files with embedded metadata I don't need any database.
For me it is much more comfortable to have this metadata which is always up to date and does not get lost. If you want to combine information of physical media and music files, it is still needed.

11

I’ve had this up and running for about a month now. Still making tweaks to it, but it works well for what I wanted.

db
db1920×712 270 KB

12

Have you looked at or checked out beets? https://beets.io

13

Along with your ID, I'd suggest to also store the barcode, as this is truely unique for releases, box sets, remastered… as longs as it's physical media.