I'm using the taglib library (1.7.2) in my Qt application, to read some metadatas of mp3 files from a music folder. The problem is that I find it very slow.
For example, this is the code:
QString path = "C:/Music/";
QDir d(path);
QStringList fileTypes;
fileTypes << "*.mp3" ;
d.setNameFilters(fileTypes);
QStringList pathList = d.entryList( QDir::NoDotAndDotDot | QDir::Files);
QTime t;
t.start();
foreach (QString fileName, pathList) {
fileName = path + fileName;
TagLib::FileRef *f = new TagLib::FileRef(fileName.toStdWString().c_str());
}
qDebug()<<t.elapsed();
This code takes about 11s to load a folder containing 400 songs, ie about 28ms for each file. This is the line very slow:
TagLib::FileRef *f = new TagLib::FileRef(pathFile.toStdWString().c_str());
Is it normal it's so long ? I've tried using multi threading, but it doesn't change anything, and it doesn't come from my PC, as it's enough powerful. The weird thing is that once all the files have been loaded, the next time it load the folder again, it's done instantaneous (until i reboot the os).
I have also another problem.
Sometimes, when a tag is not set, the app crashes, and output:
HEAP[myapp.exe]:
Invalid address specified to RtlFreeHeap( 0ED90000, 0ED92CC0 )
On the following line for example:
if (!f->tag()->genre().isNull())
I'm using Windows 7.
Thanks.
Sometimes, when a tag is not set, the app crashes, and output...
It is one of the many strange design decisions in the TagLib. The AudioProperties object is NULL when there are no tags. You have to live with it and add some extra code to check for NULLs.
The weird thing is that once all the files have been loaded, the next time it load the folder again, it's done instantaneous (until i reboot the os)
It's not weird, since Windows 7 has a very advanced and very aggressive disk I/O caching mechanism. Once you "touch" the file, it gets to the RAM and the next time you access it - it's almost instantaneous. 400 mp3 files is not much and it all fits into the RAM.
11s to load a folder containing 400 songs
400 times you have to perform a disk seek which usually takes 9-11ms on a typical hard disk drive (yes, it's only 0.1ms for the SSD). So you have at least 10*400 = 4 seconds just to "rewind" the drive's head, if the folder is fragmented. Since id3 tags may occur at the beginning and at the end of the file this virtually increases the number of reads twice (you have to rewind to the end of the file), thus giving the 2x time (about 8 seconds).
Resume: The time to read the folder is close to something realistic. There is a number of quircks in TagLib (like NULLs or the inability to overload the file operations to allow, e.g. reading from archives), but they are avoidable. The functionality of TagLib is really good and in many aspects it is unique (broad format support).
来源:https://stackoverflow.com/questions/11284154/taglib-performance-and-crashes-problems