Feature Request/Suggestion - External DB access

Hello all,

I'm new here to the community but I am a long time (donating) fan and user of MP3TAG. I recommend it to everyone I know that has a music library.

I have been, and still am, a big database application developer. I love, dealing with, and analyzing, data. Don't ask me why, I don't know.


Now I don't know if this may have already been suggested/considered already. I didn't find anything that seemed relevant. I would like to suggest, and put forth, an idea that I feel could be useful for at least me and possible for others. I currently am the IT person, and an Announcer for a couple Radio Stations. I also manage a couple podcasts for others.

I have run into the situation many times of needing to move information, sometimes bi-directional, between data sources and the media libraries (audio files). I am currently working on creating an "export template" (mte) for one of the podcasts I manage. I have been about 90% successful. To complete it, I have come across the need for what could become a very useful function of MP3Tag.

Those that may be familiar with MS Office and writing apps for Access might have used the DLookup function at times. I would like to suggest something similar for MP3Tag.

DLookup( expr, domain [, criteria] )


Required. An expression that identifies the field whose value you want to return. It can be a string expression retrieved from a field in a mp3 or it can be an expression that performs a calculation on data in the currently referenced MP3. If expr includes a function, that function can be either built-in or user-defined.


Required. The fully qualified path to the external file holding the data. Initially limited to CSV formatted files containing comma separated values with row 1 containing field names. Subsequent rows contain the data with text fields surrounded by single quotes.

Possibility of adding other file formats or database connections such as MySQL, etc. in future development.


Optional. A string expression used to restrict the range of data on which the DLookup function is performed. For example, criteria is often equivalent to the WHERE clause in an SQL expression, without the word WHERE. If criteria is omitted, the DLookup function evaluates expr against the entire domain. Any field that is included in criteria must also be a field in domain; otherwise, the DLookup function returns a Null.

Returned data

All data/values returned will be returned as plain text. User to use other MP3Tag function(s) to manipulate returned value to their format and requirements.


The DLookup function returns a single field value based on the information specified in criteria. Although criteria is an optional argument, if you don't supply a value for criteria, the DLookup function returns the first value found in expr in the domain.

If no record satisfies criteria or if domain contains no records, the DLookup function returns an empty string (''). Up to user to test for this.

If more than one field meets criteria, the DLookup function returns the first occurrence. Criteria must ensure that the field value returned by the DLookup function is unique.

If used in an Export Template, the function would ONLY be used between the $loop() and $loopend() directives.

Examples : [ ] for illustrations only

Domain (File) - C:\podcast\episodedates.csv


expr - [ep_desc]
criteria - [air_date EQ '2020-09-25']
Returned value - '1959'

expr - [air_date]
criteria - [ep_num EQ 10]
Returned value - '2020-11-07'

I hope this makes sense and would be considered for addition to this great package.

I don't know if you are familiar with the function Converter>Text file - Tag and the way it imports data from text files to tags.
You can either choose it to work by sequence or by filename.
So if you include the filename in your podcast database and add it to the record from which you write to the audio file then you could address that file and its fields accurately.
I think it is a question of workflow in which you have to define who the master of information is.

Thank you for that info. Yes pretty much the same as I was suggesting but without the ability to do random look-ups.

I could make that option work with a bit of playing around.

I still like the idea of what I suggested as it would also give the ability to tie into databases possibly.

It is always rather difficult to judge whether a feature is requested because a certain result should be achieved or a certain method should be implemented.

I therefore described a way to get a similar result although not quite with the method that you described.
So, as long as your feature request has not turned into a feature, you may have to use the existing functions to get the result.

1 Like

I'm already getting ready to test this.

Thanks again

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.