mAirListDB Importing

What with the new “mass edit” feature I was wondering if there’s any chance of an import option for, say, an M3U list ? Using an MP3 tagger, I can create lists of songs with a particular Genre/Style etc and would like to import them into the DB and “Attibute” them accordinly.

At present we can only do folders so it makes things a bit difficult.

No, that’s not possible, because the database relies on the “sync” mechanism to ensure that all files in your music folders - and only in that folders - are listed in the database. This is different from e.g. iTunes, where you just drag&drop any files into the database - but it’s very hard to keep track of which files have been imported already. (I wish iTunes had a sync feature like that.)

Another reason is that only relative file names are stored in the database, along with the ID of the storage, so you can only save files that belong to one of the registered storages.

The only option I see is to make a “filter” button in the sync dialog that lets you load an M3U playlist and then only select the files from that list in the “new files” list.

But mAirListDB imports the Genre tag from ID3 files anyway, so why don’t you just import all files first and then use the attribute tree in mAirListDB to access the files with a particular genre?

Ah - the Genre field I had forgotten about, thanks for that tip. Seems to work with a few of my fields (some are quite custom).

I did try loading an M3U in mAirList and then dragging it to the Database Playlist in the Browser but I don’t see a way to save it. The idea being that I could then run mAirListDB and manipulate it from there.

I think, as Torben says, you would need to import the files individually.

One way to do that would be to use my ‘Attribute assignment’ script. If you’d like a copy, I’ll post it in the Scripts section.

Though having said that, I believe that you would still need to create the Storage in mAirListDB first, for any folders which don’t already have a suitable Storage (and remember that a mAirListDB Storage includes any subfolders on disk) set up in mAirListDB.


I have my music in subfolders according to initial character - so Z:\MUSIC\0 Z:\MUSIC\A and so on. Yes, sub-folders work fine :slight_smile: I was just hoping something simple could be done by Torben before I try the “long way round” :slight_smile:

My first thought is that you should be prepared to have to dump and recreate any custom Folders you’ve created. This may cause a major sense of humour failure.

Having re-read the entire thread, what I’d suggest as the ‘shortest way round’ depends on whether or not you also have an MMD file for each track.

If you do, then all that should be needed is:

  1. Write and run a program to make the necessary changes to the MMD files.
    (I’d suggest Office VBA or VBScript, but you can use any language that supports reading/writing text and/or XML.)

  2. Check a few of the amended MMDs in mAirList or mAirListTag.

  3. If the MMDs look good, open mAirListDB and DELETE the corresponding Storages.

  4. Add the Storages again and allow all the files to import.

If you don’t have existing MMD files for your audio files, then your options are:

  1. Create the MMDs first (which is a very good idea: see below), then proceed as above.

  2. If you are comfortable with SQL, you could either rootle about in the mAirListDB tables yourself, or else ask Torben for the SQL you would need to apply the necessary changes. Note that this would probably need extra programming beyond SQL statements, because a lot of the data stored in mAirListDB tables are long text fields which each contain (effectively) an XML document. (Yes, I’ve looked in there myself. ::slight_smile:

  3. Delete and recreate the storages. This is the worst option, because you will lose any special Item properties which you have added manually.

Depending on the number of tracks you have, none of the above are exactly a short process, but some options will take longer than others.

If anyone reading this thinks it’s weird to have a mAirListDB database AND an MMD file for each audio file, the reason is that the MMDs effectively form a backup for your database. Provided that you remember to save any amendments to the MMD and to the database each time you make a change—a very small price to pay IMHO—you can use your MMDs at any time to re-load your database, retaining all your carefully prepared cue points, colours, settings like ‘this is a Special item,’ and even Actions will all be preserved after the database reload.

All of this does raise a question which I’ve been debating for some time myself: I think we need some kind of ‘Resynchronise Storages’ process in mAirListDB, with specific options for:

Update from:
[font=Wingdings]¤[/font] MMD files only
[font=Wingdings]¡[/font] MMD files if available, otherwise from file tags
[font=Wingdings]¡[/font] File tags only

Fields to update:
Clear a checkbox to leave the existing data in the database unchanged.
General tab
[font=Wingdings]ý[/font] Title
[font=Wingdings]ý[/font] Artists
[font=Wingdings]ý[/font] Ending
[font=Wingdings]ý[/font] Type
[font=Wingdings]ý[/font] Colour and Icon
[font=Wingdings]ý[/font] Comments
Options tab
[font=Wingdings]ý[/font] Start Times
[font=Wingdings]ý[/font] Fade duration
[font=Wingdings]ý[/font] Options
Attributes tab
[font=Wingdings]ý[/font] All atttributes
Actions tab
[font=Wingdings]ý[/font] Actions on start
[font=Wingdings]ý[/font] Actions on stop
Cue Data tab
[font=Wingdings]ý[/font] All cue points

It would also be good to have a dialog like the existing Synchronise dialog, which would allow you to EXCLUDE some files from the ‘re-sync’ processing entirely.


I don’t see a reason why. Once the files are imported into the database, they should only be edited and maintained in the database. Throw away the MMD files, they’re not needed anymore.

If you’re a hacker creating your own MMD files for some sort of “mass update” function (now available in v3.1, by the way), change your scripts so that they work on the database instead.

I still regard MMDs as my ‘ultimate backup.’

If (god forbid) my database is ever broken, then when I come to recreate the database, I still have all the significant mAirList metadata in my MMDs (cue points, etc.). No way do I want to be in a position where that information is irretrievable, or where mAirList has to re-analyse every audio file to re-generate ‘some’ of it.