Playground/MediaPlayer: Difference between revisions
(Created page with "Discussion here is easier than on the etherpad. Please ''follow'' the page to now when it is updated. == Description of the interactions == We keep one collection that can m...") |
|||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Discussion here is easier than on the etherpad. Please '' | Discussion here is easier than on the etherpad. Please ''watch'' the page to know when it is updated. | ||
== Useful doc == | |||
* http://wiki.hydrogenaud.io/index.php?title=APE_key | |||
* http://id3.org/id3v2.4.0-frames | |||
* http://taglib.github.io/api | |||
== Description of the interactions == | == Description of the interactions == | ||
| Line 14: | Line 19: | ||
=== Albums === | === Albums === | ||
Left panel: click on albums | Left panel: click on albums | ||
Middle Pannel > ?? show album covers grid view | Middle Pannel > ?? show album covers grid view, double clicking an album cover replaces Now Playing with all the tracks from that album | ||
=== Genre === | === Genre === | ||
Left Panel click on Genre | Left Panel click on Genre | ||
| Line 30: | Line 33: | ||
== Database == | == Database == | ||
After some reflection and I think we should use a no-sql database, not to have to deal with other keys. See http://quodlibet.readthedocs.io/en/latest/development/faq.html#what-about-my-favourite-nosql-db-then. | |||
'**' do we really need so much metadata, most of it is not directly editable by end users => yes but they might want to see it, and it's faster to read the database than compute something on the file each time we want to show it. | |||
**do we really need so much metadata, most of it is not directly editable by end users => yes but they might want to see it, and it's faster to read the database than compute something on the file each time we want to show it. | |||
foreign key relationships need to be defined properly before we implement in code | foreign key relationships need to be defined properly before we implement in code | ||
=> True for the foreing key relationship | => True for the foreing key relationship | ||
All these tag should be tracked: http://taglib.github.io/api/classTagLib_1_1PropertyMap.html | |||
QuodLibet does this and IIMO it's a great thing that most music players lack.... | |||
=== Tracks === | === Tracks === | ||
| Line 44: | Line 50: | ||
* duration | * duration | ||
* album_id | * album_id | ||
* ? artist_id ? it could be recovered with track->album->artist by that logic track_artist_id can be recovered, so let's choose one _artist_id and recover the others as necessary | * ? artist_id ? it could be recovered with track->album->artist by that logic track_artist_id can be recovered, so let's choose one _artist_id and recover the others as necessary. !!There needs to be an album artist id tracked, it will greatly help with the organization of music libraries inside the player!! | ||
* track_artist_id | * track_artist_id | ||
* composer | * composer | ||
| Line 68: | Line 74: | ||
* artist_id | * artist_id | ||
* year | * year | ||
* cover_path this should be filepath to a local cache dir << Why cache? isn't .local/share/MusicPlayer/covers good ? that's a fine | * cover_path this should be filepath to a local cache dir << Why cache? isn't .local/share/MusicPlayer/covers good ? that's a fine. << I think it should be local, in order for the cover art to stay with the music in case of a library migration or something as simple as redoing a linux partition completely. cover art should be kept locally, and If I recall correctly, MP3s actually are embedded with cover art | ||
Latest revision as of 10:34, 27 August 2016
Discussion here is easier than on the etherpad. Please watch the page to know when it is updated.
Useful doc
- http://wiki.hydrogenaud.io/index.php?title=APE_key
- http://id3.org/id3v2.4.0-frames
- http://taglib.github.io/api
Description of the interactions
We keep one collection that can morphed into different views (possibly a tree view, list, grid, whatever) 3 modules: database manager, collection manager, ui
Artists
Left panel: click on artists Middle Pannel > ??? collection view sorts by artists(highest rated or alphabetically)
Albums
Left panel: click on albums Middle Pannel > ?? show album covers grid view, double clicking an album cover replaces Now Playing with all the tracks from that album
Genre
Left Panel click on Genre Middle Panel > collection view sorts by Genre
Year
Left Panel click on Year Middle Panel > collection view sorts by Year ....
Database
After some reflection and I think we should use a no-sql database, not to have to deal with other keys. See http://quodlibet.readthedocs.io/en/latest/development/faq.html#what-about-my-favourite-nosql-db-then.
'**' do we really need so much metadata, most of it is not directly editable by end users => yes but they might want to see it, and it's faster to read the database than compute something on the file each time we want to show it. foreign key relationships need to be defined properly before we implement in code
=> True for the foreing key relationship
All these tag should be tracked: http://taglib.github.io/api/classTagLib_1_1PropertyMap.html
QuodLibet does this and IIMO it's a great thing that most music players lack....
Tracks
- id
- title
- id_rootpath
- complementary_path why do we need 2 path colums?? I based myself on Amarok: you have several folder, so you have a * relative path and a root path selected by the user. ok
- duration
- album_id
- ? artist_id ? it could be recovered with track->album->artist by that logic track_artist_id can be recovered, so let's choose one _artist_id and recover the others as necessary. !!There needs to be an album artist id tracked, it will greatly help with the organization of music libraries inside the player!!
- track_artist_id
- composer
- sample_rate**
- bitrate**
- bpm**
- creation_date**
- modification_date**
- file_size**
- file_type = format**
- user_rate
Do we do 3 tables Artist/Album artist/Composer or do we add a int in it to tell which type it is? For instance track artist = 1, album artist = 2, composer = 4 so that 3 means the two first (and so on)
Artists
- id
- name
- type (int: Composer/album artist/track artist) prefer the integer enum, no need to duplicate data
Albums
- id
- name
- artist_id
- year
- cover_path this should be filepath to a local cache dir << Why cache? isn't .local/share/MusicPlayer/covers good ? that's a fine. << I think it should be local, in order for the cover art to stay with the music in case of a library migration or something as simple as redoing a linux partition completely. cover art should be kept locally, and If I recall correctly, MP3s actually are embedded with cover art