Bug 90828 - user-defined meta information for music files
Summary: user-defined meta information for music files
Status: RESOLVED DUPLICATE of bug 89314
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 117854 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-10-06 00:23 UTC by Miles Stevenson
Modified: 2006-06-30 02:25 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miles Stevenson 2004-10-06 00:23:31 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

User-defined meta information
Most casual music listeners don't have a lot of demands when it comes to information about what they are listening to. Most of the time, the name of the track, lead artist, and album name is all that is required. But there are those of us out there that really care a lot about all the details. We love to get obsessive over all these little tidbits of information, such as the names of each musician in the group, who originally wrote the tune, exactly when and where the recording was made (the FULL date, not just the year), make & model of the instruments used in the recording, whether or not this is an original recording or a “digitally remastered” re-issue, which record label released the recording, etc.

The ultimate Amarok would give us “power users” a way to store all of this valuable information about the music on a per-track basis. The per-track basis is especially important because a lot of these details change from track to track on the same album. It is common for a lot of jazz recordings to feature completely different side-men on each track of the same album. It is also common to see different recording dates for each track, not to mention some of the tracks being recorded at a live show, while others are recorded in a studio.

Because each of us have different levels of obsessiveness when it comes to storing this additional information, and because a lot of this info is not always available, the ultimate Amarok would need a flexible, but organized way for the collector to store as much info as they would like. Possibly in a structure similar to a hash table (think Windows Registry). The Ogg-Vorbis format seems to allow an arbitrary amount of this kind of information to be stored inside the file: http://www.xiph.org/ogg/vorbis/doc/v-comment.html

I'm thinking of giving the user a settings panel to define their own fields for tagging the file. This way I would be able to define a tag such as "Recording Label" and be able to search by that tag when creating playlists.

All of this meta-info should also be searchable. This would allow me to specify extremely powerful searches on my collection, such as “show me every tune where Elvin Jones is on drums”, or “how many tracks do I have of Wynton Marsalis playing a song written by Thelonious Monk?”.  The sky is the limit here, and would make for some very interesting playlists! This search functionality could even be extended to provide for regular expression matching for the ultimate in power searches! Just imagine being able to filter out all of the music that you have in your collection, but are not particularly fond of  (random play everything in my collection where artists does NOT equal “Yanni”).

While a simple, arbitrary hash table with user-defined keys would go a long way, I could imagine the need for a three dimensional array type of structure when it comes to listing who is playing what, such as Instrument - > Piano -> Chick Corea, or possibly adding a fourth dimension for model of instrument as well. Being able to easily define  these multidimensional relationships as well as search by them is where the real power is unlocked.
Comment 1 Christian Loose 2004-10-07 10:05:53 UTC
The id3 standard also has much more frames than amaroK offers (http://www.id3.org/id3v2.4.0-frames.txt). 

I'm not sure if it makes sense to add support for all those frames to amaroK. IMVHO it's better to use a dedicated id3 tag program like kid3 to edit this information.

Christian

Comment 2 Isaiah Damron 2005-12-04 07:55:36 UTC
I'm not a big fan of the idea, but it is a reasonable request.  Just wanted to note that if this is implemented, we could provide for boolean custom tags, and use them to provide for this feature: bug 89314
Comment 3 Alexandre Oliveira 2005-12-07 13:08:53 UTC
*** Bug 117854 has been marked as a duplicate of this bug. ***
Comment 4 Seb Ruiz 2006-06-30 02:25:07 UTC
this is just labels!


*** This bug has been marked as a duplicate of 89314 ***