Thinking of making MP3 organizing utility but need backend ideas

[Kovacic]

Hi all.. I have no code ready yet, so this is more of a 'what are your thoughts' post.

I have a large music collection that is barely organized. I want to make an app that will make a catalog of all the music, rename the files, and organize them in the proper folders by artist / album / song. I plan on using the Mp3 UDF floating around to fix the Tags as needed, and I have the script to scour the directories. What I am wondering about is what format to keep the music data in. I have over 170,000 tracks, and I am afraid if I just have the data in a csv file or something, it will be slow or crash. I am thinking either SQLite, or XML or something like that. I would like something easy to deploy so if anyone else wants to use it, its an easy install.

 

Does anyone have any experience using autoit with large amounts of data? I wrote an asset tool that manages around 5000 items with an SQL backend (not lite) and works flawlessly, thats why I was thinking SQLite... 

 

Any thoughts on this idea, or was this already done and I am just reinventing the wheel?

 

Thanks!!

[pcjunki]

I was kind of in the same spot, I have a huge amount of music in my collection, on an external tb drive, but got tired of when I put songs on my cell phone, it wouldn't show up right with the artist, song title, ect ect ect

several months ago, I ended up reloading my pc with Linux mint, cause I didn't like win10 at all, and found the program banshee music (kinda like iTunes)

it organized all my music in a catalog, and I was able to write meta data etc etc

well... that didn't really help you at all, just throwing something your way.

[rcmaehl]

Feature request: Duplicate file finding is a must.

Honestly, I think you should just have some Co-processing for loading, sorting, and saving the catalog. No matter what you use otherwise for storage, your program will stall while it does these and you'll get a bunch of invalid bug reports. Pretty much everything else can be done in the main program.

Edited December 7, 2015 by rcmaehl

[TheSaint]

Personally, I find using multiple INI files with one or more index INI files, best serves my catalog needs, but it depends on your end game really. I use multiple INI files to get around the limitations of INI files, and so long as you have a proper Index INI file(s) regime, all is usually fine ... provided you take the other INI file issues into account.

XML also has issues, and I have found speed as a deterrent with them too. Not tried making a multiple version scenario of them to get around the speed issue.

SQLite I am yet to try.

In the end, depending on your anticipated needs, you might well be better served by something already in existence. Been a while since I looked, but I imagine there are a few good freebies around, with Sourceforge being a good place to start looking perhaps, though be aware they no longer enjoy the reputation they once had, due to spam installers, etc.

You may even be able to find something you can easily interact with, with your own coding, to add what may be missing or make your own changes .... kind of like a frontend scenario.

All in all though, there are (probably surprisingly) quite a few factors to take into account when building your own catalog database. It all depends on the level of control you require. When it comes to music, I require a lot of control over all sorts of things ... which has turned out to be quite a huge number of aspects.

Unless you are prepared to go to that trouble or want to go to that, then you just may well be better off with something by a third party.