staff
2,096
edits
OstDB DEV: Difference between revisions
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
{{TOCright}} | {{TOCright}} | ||
=General= | ==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]] | For other areas of active development on AniDB, check: [[Development]] | ||
| Line 8: | Line 8: | ||
Directly related: [[Generic PersonCompany DEV]], [[OstDB DEV Foosic]] | Directly related: [[Generic PersonCompany DEV]], [[OstDB DEV Foosic]] | ||
=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 user base. For so far unknown audio files interested users (aka work monkeys) would either use a client or the web interface 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 user base. For so far unknown audio files interested users (aka work monkeys) would either use a client or the web interface 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. | ||
=Data= | ==Data= | ||
What are the things we should be able to store/provide? | What are the things we should be able to store/provide? | ||
... list all entities and their attributes here ... | ... list all entities and their attributes here ... | ||
==Artist== | ===Artist=== | ||
<tt>copied from [[Generic PersonCompany DEV#Artist|PersonDB - Artist]]</tt> | <tt>copied from [[Generic PersonCompany DEV#Artist|PersonDB - Artist]]</tt> | ||
* | * relid - entity id | ||
* typeid - type of entity | * typeid - type of entity | ||
** 2 - person | ** 2 - person | ||
| Line 31: | Line 31: | ||
* ... | * ... | ||
==Artist Group (Band)== | ===Artist Group (Band)=== | ||
Data stored: | Data stored: | ||
* founded on | * founded on | ||
| Line 39: | Line 38: | ||
... | ... | ||
==Collection (Album)== | ===Collection (Album)=== | ||
Data stored: | Data stored: | ||
* number of tracks | * number of tracks | ||
| Line 46: | Line 44: | ||
... | ... | ||
==Song== | ===Song=== | ||
Representation of a specific song. Each song may be included in an arbitrary number of collections (at least one). A song can also be directly added as OP/ED for an anime (also stored: first ep the song was used in). A song is related to files. Each file can contain one or more songs (i.e. full CD image). And each song has lots of files. | Representation of a specific song. Each song may be included in an arbitrary number of collections (at least one). A song can also be directly added as OP/ED for an anime (also stored: first ep the song was used in). A song is related to files. Each file can contain one or more songs (i.e. full CD image). And each song has lots of files. | ||
| Line 62: | Line 60: | ||
* ... | * ... | ||
==Audio File== | ===Audio File=== | ||
Representation of an actual physical file which was encountered by an AniDB client at least once (it is not possible to add files manually). Files are initially not linked to any songs, albums or artists. Once known to AniDB a file can be manually linked to a song via the web interface or an AniDB client. Linking will be supported by the file meta data known to AniDB. I.e. if AniDB collected ID3 Tag data for song title, artist, track number, album, ... the available data will be used to suggest some likely matchings for each file. It will be up to the user to verify the correctness of the suggested matchings. | Representation of an actual physical file which was encountered by an AniDB client at least once (it is not possible to add files manually). Files are initially not linked to any songs, albums or artists. Once known to AniDB a file can be manually linked to a song via the web interface or an AniDB client. Linking will be supported by the file meta data known to AniDB. I.e. if AniDB collected ID3 Tag data for song title, artist, track number, album, ... the available data will be used to suggest some likely matchings for each file. It will be up to the user to verify the correctness of the suggested matchings. | ||
| Line 90: | Line 88: | ||
... | ... | ||
=Implementation= | ==Implementation== | ||
===General=== | |||
==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 infeasible. 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. | 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 infeasible. 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. | 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. | ||
| Line 101: | Line 98: | ||
See also [[OstDB DEV Foosic]] | See also [[OstDB DEV Foosic]] | ||
==Database== | ===Database=== | ||
====Approach 1==== | |||
===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. | 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. | ||
| Line 133: | Line 129: | ||
* multiplicities of released-by relation between audio file and audio group are wrong (switched) in diagram | * multiplicities of released-by relation between audio file and audio group are wrong (switched) in diagram | ||
* anime<->song relation with attributes (type: OP/ED, first-ep: eid) | * anime<->song relation with attributes (type: OP/ED, first-ep: eid) | ||
Changes to diagram: | Changes to diagram: | ||