Tony, the best way to improve the db reading time is: store fewer files! :
Seriously though, whatever ‘non-internal’ database is used, mAirList will have to read all of its contents. That is necessarily going to take a certain amount of time per entry, and (with my ‘profeshunul programmer’ hat on ;D) no matter what ‘tricks’ you employ, there is always a finite limit to that. I don’t know how fast or slow an iTunes database is to read, but I bet it’s still faster than an on-the-fly ‘database!’ 
I’m sure Torben has done (and continues to do) his best to reduce the amount of processing time the mAirList code takes to read an iTunes database, or any of the external data-storages which mAirList effectively imports every time it starts, but he is limited by how fast the underlying file-reading processes of the OS are working; or possibly the speed of whichever library (DLL) which his code uses to read the files; and of course the speed of Delphi itself. All code is NOT equally fast, unfortunately; if there’s a ‘bottleneck’ somewhere which is out of your control, that’s just tough luck: either way, quite often there is only one option you can use to do certain tasks, and it’s literally impossible to code around it.
You can mitigate against this problem to a certain extent by using a PC with a faster processor, and sometimes by using a faster HD, or a faster HD controller, or by adding extra RAM on the motherboard; but not necessarily! Even if you try to run multiple processing threads (sorry to get heavily techie here!) within your program, that won’t always necessarily help either: some DLLs just won’t allow you to run multiple instances of themselves, though there are mercifully few of THOSE left nowadays.
The reality for programmers is that no matter how efficient your own code is, at some level you are dependent on the internal speed and efficiency (or lack of it :o) of code within other people’s DLLs, or basic Windows system calls, and there isn’t anything that even an exceptionally talented developer like Torben can do about that.
But to return to the original question, the only real solution to the ‘import on startup’ issue is to have an internal database built into mAirList, and as I’m sure you’re aware, we will all have to wait for V3.0 of mAirList for that.
(opt diatribe n q, for anyone else in the UK old enough to remember the CIX system from the 1980s! ;))
BFN
CAD