OstDB DEV: Difference between revisions

No change in size ,  4 February 2007
m
Line 35: Line 35:


To Fix:
To Fix:
- store type with song<->artist relations (i.e. composer, lyrics, singer, ...)
* store type with song<->artist relations (i.e. composer, lyrics, singer, ...)
- rename some tables to make them more generic (ID3-Tags, Album?)
* rename some tables to make them more generic (ID3-Tags, Album?)
- ...
* ...


Don't Fix?:
Don't Fix?:
- we can't store very complex cases, but maybe we don't need to
* we can't store very complex cases, but maybe we don't need to


=Vision=
=Vision=
The general idea would be that AniDB clients would be extended with audio file support and would automatically provide anidb with lots of raw data on audio files being collected by it's userbase. For so far unknown audio files interested users (aka work monkeys) would either use a client or the webinterface to specify the song (or add it, if it is not yet listed on anidb).
The general idea would be that AniDB clients would be extended with audio file support and would automatically provide anidb with lots of raw data on audio files being collected by it's userbase. For so far unknown audio files interested users (aka work monkeys) would either use a client or the webinterface to specify the song (or add it, if it is not yet listed on anidb).
Known audio files could automatically be added to the users my(ost)list, could be renamed or their ID3/Comment data could be updated.
Known audio files could automatically be added to the users my(ost)list, could be renamed or their ID3/Comment data could be updated.
MediaWiki spam blocked by CleanTalk.
MediaWiki spam blocked by CleanTalk.