Amarok/Proposals/Support for multiple tags

From KDE Community Wiki
Revision as of 09:22, 8 December 2012 by Mayankmadan (talk | contribs) (→‎Proposals/Support for multiple tags)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Proposals/Support for multiple tags

State: Draft Target release: 2.4.3
Percent Completed: 2 Creator: Horrendus
Scope/Difficulty: 5 Driver: Horrendus
Priority: 4 Assignee: Horrendus

Summary

  • Add Support for Multiple Artist/Album/Genre/... Tags to Amarok

Extended information and rationale

  • ID3v2 and many other Tagging Systems allow Multiple Tags. Amarok ignores them. Users wish for mutliple Tags to be read & to be editable by Amarok.

Related bug reports and branches

Discussion

Please discuss this proposal on its discussion page.

TODO

  • Try how TagLib Support looks - done, example file see tagtest.cpp Gist
  • Plan how to save multiple Tags in the XML File of the Collection Scanner - planning example: http://piratepad.net/QYDQn3Ardp
  • Change Collection Scanner to scan all the Multiple Tags and put them in the XML File
  • Plan how to save them in the Database
  • Change MetaTrack to return lists for genre and others. So instead of a GenrePtr genre() const; we should have GenreList genres() const;
  • Change Database. We would have a standard normalized database table layout. e.g. since Tracks<->Genre is a n:m relation we need a relation table. (change DatabaseUpdater)
  • Change Classes (SqlMeta, SqlRegistry and SqlRegistryPrivate) to handle the changed database layout.
  • Change the ScanManager to use all the new stuff.
  • Plan how to display multiple Tags in the UI
  • Change UI (CollectionBrowser, CurrentTrack Applet, Meta Data editor, Playlist items)

Working Mode

  • Start after 2.4.2 release
  • Use independent changes. E.g. changing the collection scanner XML but for a first step not using the information. Or returning GenreLists but for a first try just using the first entry, disregarding further genre results. This working mode allows us to always have a running Amarok and no need for a big merge when everything is done.
  • Work on a separate branch when we need to put all the parts together.