Improved browse and search for Classical music V4 - 9Dec05 Authors: Ceejay and Listener This is one of a proposed set of enhancements aimed at making the Slimserver/Squeezebox much better suited to the needs of users of Classical music - although it is hoped that they will be useful to other currently-neglected users as well! Requests 1 & 2 go together and provide some of the basis for the following changes Requests 3 & 4 use the new data, as well as existing data in a more flexible way, to make searching and browsing easier especially for Classical Music users in the Remote and Web UIs respectively Request 5 is for a new idea of using User-Defined tags for browse and search A separate "Multi-Level Browse" Enhancement is a more complex UI implementation and builds on the simpler UI enhancements described here. This would be a substantial improvement for users of classical music - but hopefully also for many others with complex collections or browsing requirements. NB: "Current" behaviour in the notes refers to 6.2.2 ================== Request 1 - Recognise additional contributor type "performer". Recognise these tags: "Performer" in Vorbis, TP1/TPE1 in ID3v2.2/2.3. Add to the database as a new contributor role. This is in addition to the existing contributor roles of artist/conductor/composer/band. Note that there could be multiple instances of this tag on a single file, all are equally valid. Reason: this is intended to be used to capture principal soloists Optional extra: Add "Lyricist", "Arranger", "Author" as further (distinct) contributor roles (Possibly unnecessary if Request 5 - User Defined tags - is implemented and allows several user defined tags) Implementation query: not sure why the contributor roles are done in the way they are, possibly it was done on the assumption that the only way this info would be used was in the current model where different kinds of contributor are (on user selection) marked as being equivalent to "Artist". The following requests mean that these roles are to be queried / searched independently. Not sure if this implies a different way of treating this info in the database? ================== Request 2 - Allow alternate Orchestra and Ensemble tags for "band". In Vorbis; recognise "Orchestra" and "Ensemble" tags as equivalent to "Band". Note that there could be multiple instances of this tag on a single file, all are equally valid. Reason: Vorbis preferred standard is "ENSEMBLE", many users will see "ORCHESTRA" as more intuitive. Optional extra: make this behaviour user selectable (in the same way that Conductor, Composer and Band can optionally be treated as equivalent to Artist for browse/search in current Slimserver). However, there doesn't seem to be a downside to having them equivalent, so this may not be necessary. ================== Request 3 - Extend "Advanced Search" in Web interface for more tags [see also Bugs 709, 946, 1274] (1) Add fields to allow search on: - Composer - Conductor - Performer - Ensemble/Band/Orchestra (and Lyricist, Arranger, Author if added under Request 1)(and for maximum flexibility how about COMMENT?) These fields all considered as "AND" to each other and to existing fields. Reason: makes it possible for users to find a particular recording (essential in large libraries) or to look for works by particular conductors etc. (2) Add option (eg by pull down or tick box) to search for Albums instead of Tracks [see also Bug 1121] Reason: in Classical music we are nearly always looking for the whole album to play: current behaviour clutters the search list with all the tracks (movements). (3) Prepopulate the search fields with valid values - in the same way that Genre is today. May want only to do this if there are less than N values to stop this getting out of hand. N could be configurable on this form - default say 50 - or hardwired (pick a number!) (4) For extra credit (but not essential in first release)... Some of these tags can legally have multiple occurrences, so the search should allow for this. Tags which can occur only once (Album, Artist, Year, Title) can just be entry boxes against a fixed label as in the current Advanced Search form. The ones which can be multiple could be accomodated by having a number of flexible labels, each with a pull-down selecting from the valid tag names. You could default the first to "Composer", the second to "Conductor", etc. There are other ways of doing this! =================== Request 4 - Widen list of tags for browsing in Remote UI (simplified version: superceded by Multi-Level Browse) (1) Add a new web form (simple series of tick boxes) to specify which tags are valid for browsing. Default could be "artist", "album", "genre" and "year". Additional valid tags could be "composer", "conductor", "performer", and "ensemble/band/orchestra" (and Lyricist, Arranger, Author if added under Request 1). (just having artist/album/genre/year selected would be identical to current behaviour). (2) Remote UI behaviour same as current: Browse Music -> list of Browse options, one per valid browse tag plus "Music Folder" and "New Music". Select any one of the new valid browse tags (e.g. Browse Conductor) and get a list of values (conductors). After that have a fixed browse sequence as per current model. Browse Albums => Albums => Tracks Browse Artists => Artists => Albums => Tracks Browse Years => Years => Albums => Tracks Browse Genres => Genres => Artists => Albums => Tracks Proposed: Browse Composer => Composers => Albums => Tracks Browse Conductor => Conductors => Artists => Albums => Tracks (and similarly for Performer, Ensemble etc) Same behaviour as at present when you get to albums or tracks: scroll up and down the list: press "play" to play, right to explore tracks etc. (3) In the web interface home page, add a new "browse" link for each valid browse tag. Other behaviour as present, with the same browse sequences as for the Remote UI (above). Note that this functionality could yield long lists of albums: it should be seen as an intermediate step to the Multi-Level Browse, which will make this manageable/usable in large collections. =================== Request 5 - Allow User Defined Tag for Browse and Search Not sure of practicality, or compatibility issues here, but "it would be nice if" the user could tell Slimserver to look for a particular tag with an arbitrary name of the users choice - and then browse or search for it in the same way as some of the other tags above. Browse behaviour same as Genre, for example. This might be a "standard" Vorbis tag that Slimserver happens not to use, or a completely made-up one. An example would be if you wanted to give a concise name of a work e.g. "Symphony no. 1", while wanting to use a fuller name in the "Album" tag (Beethoven Symphony 1 in op .... etc). In this case you could invent the personal tag "Work" and use it this way. Another use which has been requested in the forums would be to tag the music with the owner of the original CD in a shared environment. It could also be used to identify music for age suitability. Some of these uses (the ones with not many possible values) could, admittedly, be kludged by loading extra values into a multivalued Genre tag, but this is ugly and risks breaking other applications which might not like it. There's no particular reason why you would stop at one such tag, except that presumeably each of them becomes an extra column in the table. Have two or three, maybe? UI and Treatment of different tag types: Ideally a user who has a mixed collection of music files (flac, mp3, etc) should be able to specify that his Userdefined tag ("MYOWNTAG", say) corresponds to a particular tag in several different tag formats. So "MYOWNTAG" = "Something1" in Vorbis, "SOMEthing2" in APE, and "ABCD" in ID3v2.3/2.4. ID3v1 considered obsolete? For the ID3v2.3/2.4 tags, this could be a pulldown of all of the known tag values (including the ones which Slimserver is already reading and making use of?). For Vorbis (and Ape?) there should definitely be a free form text box, the whole idea is to be able to use absolutely any value. ====================