OstDB DEV: Difference between revisions
mNo edit summary |
m (→Approach 1) |
||
| Line 43: | Line 43: | ||
* 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?) | ||
* album<->song relation needs int trackno attribute | |||
* ... | * ... | ||
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 | ||
Revision as of 09:21, 8 February 2007
General
this is the place to contribute ideas on a possible future addition of anime OST data to anidb.
For other areas of active development on AniDB, check: Development
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). Known audio files could automatically be added to the users my(ost)list, could be renamed or their ID3/Comment data could be updated.
Data
What are the things we should be able to store/provide?
... list all entities and their attributes here ...
Album
...
Song
...
Audio File
...
...
Implementation
General
One key factor to allow for a certain degree of automation is the automatic identification of audio files. There are some services out there like music brainz which do this but tend to list only the very well known OSTs. Reimplementing something like this for anidb would be clearly inveasible. One possible approach would be to generate normal SHA1 hashes over the raw audio data (still in compressed form but without any ID3 Tags, Comments, ..., basically this would mostly mean skipping the header for hash generation). This could be extended by storing additional TRM IDs from music brainz, where available. Content hashes would differ for the same song from encode to encode. However, matching of audio files to songs could probably automated to a certain degree by using ID3/Comment values found on the files in question.
Database
Approach 1
Here is one possible way of realizing the database structure, not exactly 100% correct UML but you should get the idea. Classes are supposed to represent database entities. Lots of attributes are still missing. But I'd like some feedback on whether this general structure would be viable.
umbrello uml modeller source: http://anidb.info/tmp/draft1.xmi
To Fix:
- store type with song<->artist relations (i.e. composer, lyrics, singer, ...)
- rename some tables to make them more generic (ID3-Tags, Album?)
- album<->song relation needs int trackno attribute
- ...
Don't Fix?:
- we can't store very complex cases, but maybe we don't need to