Ideas for a new DB tool...

[aegert]

Here is a post I did over at LL…. I have always respected this forum hey this is the one that got me started… Haven't been around here in the forums for a while... I have been thinking a lot about this lately and would like some thoughts…. Mull this over and let me know

Adam






Hey... I have a wish.... A Usable Shn/ Flac DB should be an app plug in and a stand alone db with UI Which could act like the cddb for shns and flacs with eTree id's... Maybe into winamp or the like...

I don't want to change the shn or flacs by adding tags that will make it hard to seed the exsisting id's using FFP or MD5's from eTree....

I have a pc which serves music to my audio systems around the house... Would be nice to draw meta like data from a db which only had to look at the naming convention of the storage folder which would include the shnid?


The real issue here is that we all use slightly different naming and info.txt files... I think it might be a good project to deal out to people for ratio to do the grunt work on each project to create a txt file that is generated by a DB with a good UI. They enter info into a form from the txt files of the torrents...

A good UI to this DB could populate the show list from a pull down or auto complete the list of song names and -> 's and the like so everyone uses the same syntax and name of song ie is it BIODTL or Beat It On Down The Line... based on shnID

These new files can be system admin available that everyone can use with a defined format so regardless if someone wants to use foobar to tag or any other tagger it can be done at the click...

In its best form, all a good db would need as a key would be: the folder name which would include the shnID of the torrent linking this into Winamp or the like.

for example it would be its own 'freedb'. Winamp would enable the app to pull the info from the txt files imported into the DB when downloaded it could be downloaded in the torrent or post torrent from the server.

If each one of us takes responsibility for 10 ID's we can knock out the Db in a night.. Perfect world I guess...

It would enable most people to use there pc's as there player with the ability to easily report any song or group of songs or shows for comparison...

Reports that’s the key...

write an sql statement and get the results in a play list report... or have a report generator much like the search of the torrents on LL queiriable by Band, date, venue, song set, time etc...

ie Play list all the China Cat Sunflower -> I know You Riders from 72-74 in date order which total a total of 10 minutes or longer... but not 20min long

or

The Scarlet Fire from 09/02/78 Giants Stadium Blows away 05/08/77 which it does .... well punch it up and you tell me no hassling with disks... If you are on the web hit it from your friends house and prove your point all in Flac or shn....

Your PC as a player no CD's CDA's Storage is going down in price... Listen while you seed.. Play list anything flacs shn wma god forbid mpx... in any order based on a whim or your particular way of listening..

With a tool like this you can organize your own dead list easily... email it, print it, share a cool play list in a forum. If it ties into users who have DL'd or seeded you can ask someone specifically to seed something to help out... It would be etree on steroids.... It is a small enough file to be maintained and dispersed centrally as well so once a week additions can be seeded as needed Hey I'm a poet and I know it...



My thoughts have evolved to an online form to update the db with pull downs that help eliminate the naming conventions of songs and transitions...

If the key in the db is the shnid and the identifier of the song is the MD5 or FFp. Upon down load of a torrent a user can import he folder of the torrent into there own person local copy of the db or on line. The db will query the hash and a script will to the DB integration of the files by location on Hd..

The only issue here is the location of the song can't really change.... Im not a DBA so there is probably a standard DB convention that would either eliminate the location dependence or track movement of the file.... I would love some thoughts on this from a dba....



your thoughts?

[A New Face In Hell]

Interestin thoughts