2005-06-04, 13:50
hi,
a week or so ago i posted up this question in the support forum. given the lack of any comments, i guess it wasn't the best place for it, so apologies for that if that was the case.
anyway, i thought i'd look at this some more, and come up with a patch for it. the problem is that aac tag retrieval currently involves pulling the *entire* file over into memory so that libmp4 can be used to parse the tags. i don't have any really large aacs (say, > 20mb), but pulling all that data across just to get the metadata seemed a little excessive..
after looking at a number of mp4 tag parsing modules on the web, i've written a replacement for musicinfotagloadermp4.cpp, which rather than reading the entire file, seeks through the atoms present in the mp4 file to pull out the stuff that's needed (artist, genre, track name, album name etc).
my tests here with approximately 4500 aacs show that rather than the 20 to 60+ seconds per track retrieval overhead (on an 802.11g network, with files accessed via samba), the tag retrieval now takes in the order of < 0.25 seconds. regardless of how big the file is. i was able to do a full scan of my itunes music directory over samba in just a few minutes. as a consequence of this change, musicinfotagloadermp4.cpp doesn't use libmp4 either (reducing the memory footprint a little).
i still need to tidy up the code a little, and i've yet to test extraction/caching of the 'covr' atom data (cover art), but i was after some opinions as to whether i should look at making this faster tag processing optional (in which case, what is the best way of doing this), or just submit the patch as is..
cheers,
arnie pie
a week or so ago i posted up this question in the support forum. given the lack of any comments, i guess it wasn't the best place for it, so apologies for that if that was the case.
anyway, i thought i'd look at this some more, and come up with a patch for it. the problem is that aac tag retrieval currently involves pulling the *entire* file over into memory so that libmp4 can be used to parse the tags. i don't have any really large aacs (say, > 20mb), but pulling all that data across just to get the metadata seemed a little excessive..
after looking at a number of mp4 tag parsing modules on the web, i've written a replacement for musicinfotagloadermp4.cpp, which rather than reading the entire file, seeks through the atoms present in the mp4 file to pull out the stuff that's needed (artist, genre, track name, album name etc).
my tests here with approximately 4500 aacs show that rather than the 20 to 60+ seconds per track retrieval overhead (on an 802.11g network, with files accessed via samba), the tag retrieval now takes in the order of < 0.25 seconds. regardless of how big the file is. i was able to do a full scan of my itunes music directory over samba in just a few minutes. as a consequence of this change, musicinfotagloadermp4.cpp doesn't use libmp4 either (reducing the memory footprint a little).
i still need to tidy up the code a little, and i've yet to test extraction/caching of the 'covr' atom data (cover art), but i was after some opinions as to whether i should look at making this faster tag processing optional (in which case, what is the best way of doing this), or just submit the patch as is..
cheers,
arnie pie
