PDA

View Full Version : Using Composer / Conductor / Band tags effectively



ceejay
2005-12-03, 17:15
I've been looking into the use of the Composer/Conductor/Band tags so I can describe them in the BeginnersGuide, not having used them before - and also in response to a query by "Listener". I've looked at the tags and how Slimserver uses them, and it seems to be well less than ideal.

First, here is my understanding of how it works - if I've got this wrong could someone tell me?

- if the composer/conductor/band tags are present (in any combination) Slimserver will add them to the database as contributors... artist/composer/conductor/band are all flagged in the database as different "roles", so in principle any software querying the database could look up any combination of these tags to make a selection

- Slimserver, however, currently makes a very crude use of them: you can tell it to include any or all of these as "artists" for the purposes of browse or search. So, for example, I might then find "Karajan" and "Berlin Phil" in the Artists list as well as Beethoven. Drawback - get a cluttered Artists list.

Second, I was wondering how it might be better? I can easily imagine extending the web search form so you could put some or all of these in. I'm having much more trouble imagining how you would construct the UI using the remote to do this (eg via a Plugin).

Lets say an "Extended Browse" function (built-in or plugin) allowed you to choose between browsing Album, Artist, Song, Conductor, Composer or Band. You choose Conductor, get a list of Conductors, from which you choose Karajan.

Now - do you just get a list of the Albums where Conductor=Karajan (presumeably this wouldn't be too hard to do)?

Or, for extra points, do you have an extra choice at the top of the menu for a further search by Composer or Band? You could then choose Band, get a list from which you choose Berlin Phil, which now presents you with a list of all albums by Karajan AND Berlin Phil. Ideally this functionality would allow you to make your selection of Composer, Conductor and Band in any sequence.


Thought, anyone? Two points of view:

- is this going along the right lines for functionality? Or is what I've just described too complicated to be usable, especially via the remote?

- is this implementable? Or even in progress? A quick search of the bugs list gave me bug 709, a very old enhancement request, which is quite similar. http://bugs.slimdevices.com/show_bug.cgi?id=709

Regards

Ceejay

Dan Sully
2005-12-03, 17:25
* ceejay shaped the electrons to say...

>- if the composer/conductor/band tags are present (in any combination)
>Slimserver will add them to the database as contributors...
>artist/composer/conductor/band are all flagged in the database as
>different "roles", so in principle any software querying the database
>could look up any combination of these tags to make a selection
>
>- Slimserver, however, currently makes a very crude use of them: you
>can tell it to include any or all of these as "artists" for the
>purposes of browse or search. So, for example, I might then find
>"Karajan" and "Berlin Phil" in the Artists list as well as Beethoven.
>Drawback - get a cluttered Artists list.

That is correct. There hasn't been time or inclination (as frankly, I don't
have much Classical music) to work on this. The correct solution is as you
describe below:

>Lets say an "Extended Browse" function (built-in or plugin) allowed you
>to choose between browsing Album, Artist, Song, Conductor, Composer or
>Band. You choose Conductor, get a list of Conductors, from which you
>choose Karajan.
>
>Or, for extra points, do you have an extra choice at the top of the
>menu for a further search by Composer or Band? You could then choose
>Band, get a list from which you choose Berlin Phil, which now presents
>you with a list of all albums by Karajan AND Berlin Phil. Ideally this
>functionality would allow you to make your selection of Composer,
>Conductor and Band in any sequence.

This isn't too difficult from a programming perspective. In fact, it will
likely just work once you figure out the right UI for the Settings to make it happen.

-D
--
Ya gotta love UNIX, where else do you wonder whether
you can kill a zombie spawned by a daemon's fork?

Listener
2005-12-03, 18:52
> ... the use of the Composer/Conductor/Band tags ...
> it seems to be well less than ideal.

I agree.

> Thought, anyone? Two points of view:

Since you posted the Beginners guide to classical music,I have been thinking about how you might select classical music from the one line display of the Squeezebox and the remote.

The SB/remote combo has major limitations: 1) the one line display makes picking from long lists very tedious. 2) The one line doesn't display many characters. Horizontal scrolling takes time. 3) the remote keyboard is not useful for typing more than a few characters. (One for me.) The UI needs to work well within those limitations and to scale well for larger libraries.

How I'd like to select things: I'd like to make a series of selections each based on the value of a different tag. This might allow me to keep the list managable at each stage. So I want a browse/search strategy implemented by menu text and actions taken when I click on the right arrow which include a database search. I might want more than one such stratgey available.


One approach:

new menu choice on the top level menu:
Browse music by tags (Say the user selects it with the right arrow button.)

Action: Display a list of available tags to browse:
artist, album, composer, etc. One menu choice in the list should be for displaying all files that meet the criteria at this point. The text should show the number of files that meet the criteria sop far. (Let's say the User selects Composer with the right arrow key.)

Action: Display a list of DISTINCT composer values. The user would then select one with the right arrow key. (Beethoven for example.)

Action: Display the list of available tags again for the next level of selection. (Say the user picks Album title at this stage.)

Action: Display a list of DISTINCT album values for the Composer value specified at the earlier step. (Say the user picks Sym. 3)

Action: Display the list of available tags again for the next level of selection. (Say the user picks Artist title at this stage.)

Action: Display a list of DISTINCT artist values for the Composer value and Album value specified at earlier steps. (Say the user picks Szell.)

Action: Display the list of available tags again for the next level of selection. (Say the user picks Artist title at this stage.) If there is only one file at this stage, the server should skip the menu and go directly to displaying the file's name. (If there are 4 files left and they correspond to four movements of the work chosen at an earlier step, the user might just press play to play them all in order.

This approach requires more levels of selection than the current scheme; it alternates between choosing a tag to browse on and choosing a value for that tag. It is quite general and it lends itself to streamlining.

A Streamlined Approach:

The server could provide a setup page that allows the user to build a browse by picking one tag from a drop-down list for each step of the process. The user would provide a top-level menu name for his browse and the name would then be displayed in the top level menu.

This approach gets the job done with one selection level for each tag used. Every list displayed would be uncluttered and compact.

----
I think the first approach is good for casual use. The second approach is good once a user decides he will use a particular browse strategy regularly.

Typing the first letter of an item in the list to jump to the coprresponding list position would help make lists manageable. (I've used it with the current Browse Artists method.)

---
I have no idea whether this approach fits with the internal structure of Slimserver or the Squeezebox. I can certainly see how it translates to SQL Select statements.

Bill

ceejay
2005-12-04, 10:00
OK, so this is in principle do-able - I think it would be a good idea to try to converge on what we want before asking Dan or anyone else to code it up.

As I see it, the request for additional functionality in web search is fairly straightforward - simply add some more fields in the "advanced search" page so we can enter as many or as few search restrictions as we like.

I think there are two main topics for debate (if anyone sees others now would be the time to jump in!).

(1) What tags do we want to search on (in addition to Artist/Album/Track which are givens)?
I've been searching for standards and not come up with very much:
http://www.xiph.org/vorbis/doc/v-comment.html and
http://reactor-core.org/ogg-tagging.html both discuss vorbis comments which is fine for FLAC but I'm not sure how this extends to other formats.

Anyway, I guess that COMPOSER and CONDUCTOR are straightforward.

I'd also like to vote for PERFORMER (not SOLOIST).

And should it be ENSEMBLE or BAND or ORCHESTRA? "Ensemble" seems to be recommended by the Vorbis folks... Slimserver currently seems to read only BAND ... and I've read several references to ORCHESTRA. My vote would be for Slimserver to read all three of these but to treat them as equivalent.

Note for coder: there could be multiple instances of any of these tags in one file, all should be considered equally valid.


(2) The second problem is the desired UI behaviour when using the remote. I sketched one model two posts ago - Listener has decribed another slightly different one. I like mine - obviously! Has anyone else got any suggestions to throw into the pot?

The only thing I'd add in either case might be a Settings option to make searching or browsing by these extra tags to be optional, otherwise we'll be cluttering the UI for people who don't want to do this.

More comments from anyone?

Ceejay

Listener
2005-12-04, 16:12
> OK, so this is in principle do-able - I think it would be a
> good idea to try to converge on what we want before asking Dan
> or anyone else to code it up.

I agree that we should think a bit more before asking anyone to write code.

I have made three dummy web pages to illustrate what I've done so far. (A setup page for selecting which tags to add to the Browse by tags menu, a setup page for creating a custom browse and a web interface advanced search page.) I haven't uploaded anything before so I'll try to upload them in separate steps.

Some things to think out: 1) how would these changes work in a mixed library of classical and other things. 2)Are there any benefits for genres other than classical? 3) Are there things specific to opera or choral works? 4) How about hymns and religious music? 4) Anything different about jazz, blues, hip-hop or rap?

There is a prospect that these changes could make Slimserver capable of using whatever tags are present in the music files. I don't know the table layout of the database but if it uses two tables, it should be doable:

music file table (MT): MT primary key, file name, other stuff

tag table (TT): TT primary key, foreign key reference to MT primary key, tag name, tag value

This sort of structure provides several benefits: a) SS can store all the tags found in music files in the database. No need to cast choices in stone (code). b) The choice of which tags to list in the menus can be done in a setup page. c) SS does a Select query on the database to get a list of Distinct tag names in the database, keeps those the user has chosen in the setup screen and display the resulting list in the menu and in the drop-down lists to build a custom browse. d) Multiple Artist values can be accommodated easily.

Some tags may not have a well defined text name and we don't want to display a cryptic mix of letters and numbers. The setup page that lets the user select which tags to put into the menu should contain a column for specifying a display name to be shown in place of the cryptic text. We can build a set of defaults once.

i.e.
checkbox tag name from file display name
...

If the tag info is currently in the same table as the file name in fixed fields, a two table design would require a more complex Select query (and take more time.) However, it is clean and would make SS/SB more flexible than most players.

> As I see it, the request for additional functionality in web
> search is fairly straightforward - simply add some more fields
> in the "advanced search" page so we can enter as many or as
> few search restrictions as we like.

Some thoughts about search: 1) Browsing in a list is often better than typing criteria for a search. If you can type a single character and jump into the list, it extends the size of a list that you can browse effectively. 2) Search needs to provide a way to find things that you can't find easily by browsing. 3) If we are making the Browse capabilities more flexible, we should try to do the same for search.

I have a dummy advanced search screen for the web interface. I made the search field names drop-down boxes rather than text labels. And I added a couple of fields.

I also experimented with the idea of adding a column with a drop-down box containing all the values for that tag chosen on that line. I understand that if you change the tag name in that drop-down box, you have to re-populate the drop-down box with available values. It will be clearer when you see the dummy page.

Populating a drop-down box from the database rather than from a pre-determined list is especially important for genre. Specifying other for genre doesn't help much.

I think that the key ideas for advanced search are 1) let the user to specify any tag to search on from the SB menu, 2) selectively display available values to making searching easier.



> I think there are two main topics for debate (if anyone sees
> others now would be the time to jump in!).

> (1) What tags do we want to search on (in addition to
> Artist/Album/Track which are givens)?
> ...
> ... Anyway, I guess that COMPOSER and CONDUCTOR are
> straightforward.

> I'd also like to vote for PERFORMER (not SOLOIST).

I think we have an opportunity to make SS/SB flexible and able to use the tags in finds in the users music files. We don't have to wire in our choices.

One additional capability might be good: Combining tags when they are equivalent. A user may have music files from different sources containing different tags. So his music library would be inconsistent. It would be better if SS can adapt to what it finds rather than requiring the user to have been completely consistent.

SS has a setup option to lump Composer, Conductor and Band with Artist. A more general setup page might let the user specify one or more tags to lump with another tag. The user whould pick a tag he wants to browse and one or more tags to be combined. You don't have to lose the original information; you just change the SQL Select statement for a Browse or Search.

> Note for coder: there could be multiple instances of any of
> these tags in one file, all should be considered equally valid.


> (2) The second problem is the desired UI behaviour when using
> the remote. I sketched one model two posts ago - Listener has
> decribed another slightly different one. I like mine -
> obviously! Has anyone else got any suggestions to throw into
> the pot?

I do not agree that my proposal is slightly different. To me, this is the difference between a solution I can really use and something that just won't work well enough for me. I thought I could really see the light at the end of the tunnel.

Thinking about how SS/SB should work for playing classical music has given me some principles for design:

1) It is important for classical music libraries to provide a method that allows a series of browses on different tags to narrow the list of music files.
2) No one order of browsing tags will fit all needs. The user needs to be able to pick the browsing order tht fits his current need.
3) The list you browse needs to be kept manageable at each step.
4) SS/SB should be database driven and flexible enough to use the tags that are present in existing music files. This will decrease the need for the user to tag his files in exactly the way we specify.

I proposed a framework for performing a series of browses where the user can specify which tag to browse on at each step. It frees the SS/SB from a rigid choice of tags and browsing steps and it makes it far easier for the user to use SS/SB with an music files however they are tagged.

Your approach as I understand would display one item for each full album title. With the album display you favor - Composer, work / conductor / conductor / year - that makes for a long list to browse. If I browse on conductor or first, I get a list with lots of "Beethoven - Symphony 3 - ..." entries. On the SB, that quickly becomes unworkable for me.

My approach fits best with making the album title just the work name "Symphony 1". When I browse by conductor and select Beethoven, I get just one DISTINCT item for "Symphony 3". This scales much better. I'm beginning to see how to genre to separate Symphony from Concerto from chamber music. That really helps the UI scale even better. However, if you have more stuff in the album title, my approach still works as well as yours.

> The only thing I'd add in either case might be a Settings
> option to make searching or browsing by these extra tags
> to be optional, otherwise we'll be cluttering the UI for
> people who don't want to do this.

There already is a setup page for tailoring the main menu. (Player settings / menus.) I think that adding a Browse by tag choice to the list is reasonable. And custom browse methods could be added to that page as well. I have a dummy webpage showing how that might work.

----
I'll try to upload the dummy pages I described.

Bill

Listener
2005-12-04, 16:20
I'm uploading an HTML file with the extension changed to .txt.

Browsing_setup_tag_selection.txt

Change the extension to .htm.

This dummy webpage shows a setup process for defining which tags are displayed when the "Browse by Tags" menu item is selected.

Listener
2005-12-04, 16:29
Another HTML file with extension changed to .htm.

This dummy web page shows a setup pag for creating a custom browse.

When the user chooses this custom browse from the main SB menu, a list of DISTINCT values for the specified tag are displayed on the SB. (One at a time of course.)

The user selects a value with the right arrow and SS builds a list of DISTINCT values for the tag specified for the 2nd step for files that have the specified value for the 1st step.

This lets the user specify a hierarchy of browses to narrow down the list of files until he gets to what he wants.

This is useful for classical music libraries where you might browse on Composer then Album (work), then Artist or Conductor.

Bill

Listener
2005-12-04, 16:34
Another HTML file with file extnsiuon changed to .txt.

This one shows a proposal for makes the advanced search more general.

The right column shows a not fully worked out idea for providing a list of values for the attribute named on the left. This seems quite useful for the genre tag and possibly useful for other tags.

I realize that if you change the tag specified on a line, you have to requery and repopulate the dropdown box on the right.

Bill

ceejay
2005-12-04, 16:54
Hmmm, this could get tricky!

First, the database as it is... has many tables! But it has the notion of a "contributor", with several possible "roles". So a track can have many different contributors associated, and each contributor can be any one of several different roles (artist, conductor, composer, band - as far as I can see). This is wired into the current database design. Adding an extra role doesn't look hard, if needed.

This means that code along the lines I was thinking of, allowing the user to do queries on different roles, can be done without any changes to the database (I think). I was trying to keep it relatively simple (if we don't, it won't happen).

I suspect your completely general approach to using any tag in any way you like just might be a step too far.

I was thinking more of a browse than a search model - and I was, BTW, allowing for a multi-level selection, at least in the more advanced of the options I described. You select, say, "conductor", and get a list of all the conductors... choose Karajan, get a list of all albums that match (this is the potentially long list you are worried about) BUT with an added set of selectors at the top for each of the other valid browse tags. So if you want to now specify a further value for ENSEMBLE, you can. Properly coded, this would give you the flexibility you want to specify selectors for any of the valid tags, in any order.

I don't think this is very different from what you described, except that I am visualising a limited set of tags for which this will work (trying to keep the changes simple).

Enough of that. Maybe I'll just have a go at writing it myself.

The other function, though, is "Search", which is quite different (I think). The current standard Search functionality allows you to search (in albums, artists and songs) by typing (mobile phone fashion) in on the keypad. The new Lazy Search plugin makes this easier, by allowing you to type in just one keypad number for each letter.

Clearly the standard Search could be extended to look for Conductor etc, but I think the Lazy Search plugin would require more work and possibly changes to the database, from what I recall of how it works.

Ideally I suppose you'd like to enter partial searches on each of several different tags. I have a feeling that might be too difficult to use using the remote UI, though of course easy to do with a web interface. Maybe the right answer is to tell everyone that wants to do this to go out and buy a wireless PDA to use as their remote!!

BTW, keeping the Album title really short ("Symphony 1") won't work - it MUST contain enough information to make it unique vs all other albums, otherwise Slimserver (and other music players) will merge the tracks of the ambiguous albums.

Lets give it some more thought and see if anyone else will join in our mad ramblings....

Ceejay.

pfarrell
2005-12-04, 17:14
On Sun, 2005-12-04 at 15:54 -0800, ceejay wrote:
> First, the database as it is... has many tables!

All useful relational databases have lots of tables.
Having lots of relationships is why the 6.* series
went to the database.


> This means that code along the lines I was thinking of, allowing the
> user to do queries on different roles, can be done without any changes
> to the database (I think).

An admirable goal. Adding queries is fairly safe.
Altho the database schema is a little bit of a moving target
right now.


> I suspect your completely general approach to using any tag in any way
> you like just might be a step too far.

Most likely.

> Ideally I suppose you'd like to enter partial searches on each of
> several different tags.

Right, both predefined as part of the standard release,
and then whatever folks need for the way their library is
implemented.

> BTW, keeping the Album title really short ("Symphony 1") won't work -
> it MUST contain enough information to make it unique vs all other
> albums, otherwise Slimserver (and other music players) will merge the
> tracks of the ambiguous albums.

It should not do this. Using the name is bad design.

Each tune/song should be identified not by its tags, but by
the music itself. Tags are just comments for us humans.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Listener
2005-12-04, 19:01
I read Ceejay's last post and Pat's. I tried to find some information of the DB design as it exists.

I looked around in the SS v6.2.1 source and found a dbcreate.sql file for SQLLite and one for MySQL. Based on what I see in those files and your comments, I made some observations:

1. The album table plays a fairly central role. The album tag value is probably taken from this table with hardwired logic. That makes it harder to treat it as just another tag to make a datadriven UI.

2. I see a role field in the contributor_track and contributor_album tables. Are these fields derived from the tab name? If not, maybe the original information about tab name and value has been lost. And it probably isn't easy to separate composer from artist so that you can browse one and not the other. If you can translate the role back into the original meaning (composer, conductor, artist), perhaps you could search on just one of the roles. And in a later step, search on another role. If not, then step-by-step browsing isn't going to work for me.

3. It looks as though the tag database is not very general and it is intertwined with the general functionality of Slimserver. That makes it any changes harder to implement and less likely to happen.

4. I see that there are genres and genre_track tables. So that is hardwired too. I'd guess that if a tag doesn't have a table defined for it, that tag isn't kept in the database.

5. If I were making decisions, I'd consider separating out the tag info into a new track_tag table with the following fields:

a primary key of course,
a reference to the corresponding track,
a tag name and
a value for that tag.

Then you could make the browse and search logic data driven and quite general. I'm certainly not making the decision and I'm not likely to be doing the work so it probably won't happen.

6. Stuffing various tag values into the contributor table makes browse lists bigger and means that the UI won't scale well for me.
---
I could have been looking at the wrong file to see the database design or not understanding it correctly. So my observations might be completely wrong.

---
Now I understand Ceejay's concern for making the album tag unique. However, depending on an album name that is set outside SS by software you don't specify and don't control is a risk. Suppose two sets of tracks have the same album name. As I found, SS/SB will return both sets when I browse by artist and then select an album. They individual tracks will play in some mixed up order. If one set of tracks has a severe replay gain settng, what happens you you play the other set?

Perhaps the Beginner's Guide for Classical Music and other SS/SB documentation should contain a strong warning that if the album name isn't unique, BAD THINGS MAY HAPPEN.

---
Altogether, not encourging.

Bill

pfarrell
2005-12-04, 19:20
On Sun, 2005-12-04 at 18:01 -0800, Listener wrote:
> I read Ceejay's last post and Pat's. I tried to find some information
> of the DB design as it exists.

I've not seen a lot of documentation, but sqlitebrower
and other tools make it pretty easy to figure out.

> I could have been looking at the wrong file to see the database design
> or not understanding it correctly. So my observations might be
> completely wrong.

I posted a lot about design way back on the developers list
in the pre-6.0 times. Some was accepted, some not.
I stepped out to let the hard work get done.

> Perhaps the Beginner's Guide for Classical Music and other SS/SB
> documentation should contain a strong warning that if the album name
> isn't unique, BAD THINGS MAY HAPPEN.

Beethoven's Ninth Symphony is not
likely to be uniquely named in any large classical collection

> Altogether, not encourging.

Its a work in progress. I don't think it is time to be discouraged.
But setting up a proper library for non-pop is a non-trivial effort.

It isn't going to be fixed with a new table and five new Sql statements.

And there are philosophical questions to answer: what is a band?


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Listener
2005-12-04, 20:47
> I was thinking more of a browse than a search model -
> and I was, BTW, allowing for a multi-level selection,
> at least in the more advanced of the options I described.

> You select, say, "conductor", and get a list of all the
> conductors... choose Karajan,
> get a list of all albums that match
> (this is the potentially long list you are worried about)
> BUT with an added set of selectors at the top for each
> of the other valid browse tags. So if you want to now
> specify a further value for ENSEMBLE, you can.
> Properly coded, this would give you the flexibility
> you want to specify selectors for any of the valid
> tags, in any order.

I understand what you propose now. It could give me the sequence of browse steps I want. However, there is a problem with using the album name as the name of the work.

Most often, I'd like to browse first on Composer, then the genre (symphony) if there are a lot of works, then on the name of the work, then on performer (artist). At the stage where I want to search for the work, a list of album names for one composer would be too long. For Beethoven, it would still be 100 album names for just Beethoven Symphonies. In my scheme using just the name of the work as the album name and displaying only distinct values, I would have a list of 9 works to select from.

Your scheme:
Select Browse composer => list of 40-60 names
I use 1st letter to jump, select "Beethoven" from effectively 2-10 names.

Select Genre for next browse ==> list of 6 names
(symphony, concerto, quartet, piano sonata, chamber, other)
I select symphony from the list.

Select Album for next browse ==> list of 100+ albums
(of the form "Beethoven - Symphony 3 - Szell - 1958")
I can't type one letter an jump because they all start with Beethoven. I wade through the whole list and pick the extact work and performer I want.

I'm done but the last step was a killer! I'd probably give up before finishing. If my wife was selecting music, she would give up and come kick me for my bad choice of the system.

My scheme:

Select Browse composer => list of 40-60 names
I use 1st letter to jump, select "Beethoven" from effectively 2-10 names.

Select Genre for next browse ==> list of 6 names
(symphony, concerto, quartet, piano sonata, chamber, other)
I select symphony from the list.

Select Work for next browse ==> list of 9 work names
(of the form "Symphony 3")
I can get through a list of 9 names.

Select Performer for next browse ==> list of 8-12 names
(of the form "Karajan")
I can get through a list of 12 names.

I'm done and it was all feasible for me. My scheme depended on having a NON UNIQUE work name and presenting only distinct values to keep the list short.



Some ideas come to mind:

- Why not browse for conductor before work?
When you get a sizeable library, you don't remember everything in it. The point of a browse interface is to let the computer present choices rather than making you guess.

- If SS depends heavily on the album name internally, why not put the short Work name in a different tag? That would let you browse on a long unique album name, keep SS happy and I could browse on a different tag with a short, non-unique work name.
This work tag is analogous to the album nme as you proposed but it could probably be wedged into the contributor table with a different role. UGLY but it is a thought.


---
> The other function, though, is "Search", which is quite
> different (I think). The current standard Search
> functionality allows you to search (in albums, artists and songs) by typing (mobile phone fashion) in on the keypad. The new Lazy Search plugin makes this easier, by allowing you to type in just one keypad number for each letter.

As I understand it, you can make a single search step using the SB remote and display, then you get a list of album names to scroll through. It doesn't scale well.

I'd just add composer and conductor (performer) to the list of tags you can browse and let it go at that.

For the web interface, the advanced search function could be extended with fixed fields for composer and conductor (performer). The genre portion should have a a textbox allowing the user to specify a value for an other genre in the dropdown list.


> Clearly the standard Search could be extended to look for
> Conductor etc, but I think the Lazy Search plugin
> would require more work and possibly changes to
> the database, from what I recall of how it works.

Well, Lazy Search beats the current method. Maybe it should be incorporated in SS so that it works cleanly for any tag.

> Searching
> Ideally I suppose you'd like to enter partial searches
> on each of several different tags. I have a feeling
> that might be too difficult to use using the remote
> UI, though of course easy to do with a web interface.
> Maybe the right answer is to tell everyone that wants
> to do this to go out and buy a wireless PDA to use
> as their remote!!

I looked at buying a wireless remote as part of the system but at the time, it cost much more tha an SB. That just seems wrong. I can't stand the web interface UI on a full PC screen so using it on a PDA didn't thrill me.

I thought I saw a way to make the SB/remote workable for me. And perhaps, the web interface could be modified to provide the same functionality. The lengths of lists would matter less in that case. However, the current browse methods wouldn't be satisfactory on the web interface either.

There is another idea here about the SS/SB system. When you buy one SB, you are also making a decision on other purchases: server, lots of hard disk space and perhaps a PDA or laptop to use as a remote. And ripping and tagging 1500 CDs is a huge time commitment.

> BTW, keeping the Album title really short ("Symphony 1")
> won't work - it MUST contain enough information to make
> it unique vs all other albums, otherwise Slimserver
> (and other music players) will merge the tracks of
> the ambiguous albums.

I've absorbed the idea now but I think it is pretty dumb design in the SS software. An F in Database 101. Assume that a field you don't control will be unique.

As the market progresses, more users will want to use music files they already have and not be sensitive to what's in the tags. A recipe for problems.

Bill

Listener
2005-12-05, 01:01
Ceejay> (1) What tags do we want to search on (in addition to
> Artist/Album/Track which are givens)?

I didn't answer this earlier.

- I need a tag with just the name of the short Work name (For example, "Symphony 3").

- I need a tag that can describe the type of work (symphony, concerto, string quartet, chamber music) so that I can split of the works by one composer. Can I use Genre for this purpose?

- I can mostly live using the Artist tag for a concatenation of soloist/conductor/orchestra. So I could live without conductor, soloist and band tags but I'd use them if they were present. In the long run, it would be quite useful to have those tags and perhaps Lyracist to document what's in the library. Once I put the CDs into storage, I'll be relying on the information in the database to tell me what's in the library.

----
I found an interesting table comparing tag use by different standards and formats at

http://www.matroska.org/technical/specs/tagging/othertagsystems/comparetable.html

I notice that iTunes supprts a tag they describe as Grouping. Would this be a useful tag for a short Work name (For example, "Symphony 3")?

Pat> But setting up a proper library for non-pop is a
Pat> non-trivial effort.

I've been struggling to see how to make a usable solution given the current functionality of SlimServer/SB. How do you use tags? Do you use the SB display and the remote to select music or a PDA or a Laptop?

Pat> It isn't going to be fixed with a new table and five
Pat> new Sql statements.

I think that getting beyond the limits of the current browse methods would help a lot.

I'd be interested to hear your shopping list of things that need to be changed/added or just figured out to provide really good support for classical music.

Pat> And there are philosophical questions to answer:
Pat> what is a band?

There may be more than one way to skin the cat. Does SS/SB require that files be tagged in a particular way or can it adapt and/or be configured to use a mixed library.

Right now, I need to understand one way to skin the whole cat.


Bill

ceejay
2005-12-05, 02:05
>
Select Album for next browse ==> list of 100+ albums
(of the form "Beethoven - Symphony 3 - Szell - 1958")
I can't type one letter an jump because they all start with Beethoven. I wade through the whole list and pick the extact work and performer I want.

I'm done but the last step was a killer! I'd probably give up before finishing. If my wife was selecting music, she would give up and come kick me for my bad choice of the system.


So why stop there? If you know what you want, make a further selection by Conductor and/or Ensemble? That would get the list down to something manageable!



- Why not browse for conductor before work?
When you get a sizeable library, you don't remember everything in it. The point of a browse interface is to let the computer present choices rather than making you guess.


Agreed. My scheme would allow you to make selection by any of the approved tags, in any order.



- If SS depends heavily on the album name internally, why not put the short Work name in a different tag? That would let you browse on a long unique album name, keep SS happy and I could browse on a different tag with a short, non-unique work name.
This work tag is analogous to the album nme as you proposed but it could probably be wedged into the contributor table with a different role. UGLY but it is a thought.

Unfortunately the official recommended tag list isn't available just at the moment, but I have seen reference to a "TITLE" tag in this context, could be "Symphony 9". Wedging it into the contributor table is, as you say, ugly. The neatest way would be to add this into a table as a separate column, but this is now a database redesign (and the owners of the DB schema are understandably reluctant to shove new data in for every possible requirement). Maybe this could be a separate enhancement request for a later date. [Edit: whoops! Silly mistake - "title" is of course the track title, we can't reuse that...]



As I understand it, you can make a single search step using the SB remote and display, then you get a list of album names to scroll through. It doesn't scale well.

I'd just add composer and conductor (performer) to the list of tags you can browse and let it go at that.

Good! I think we're agreed on this point.


For the web interface, the advanced search function could be extended with fixed fields for composer and conductor (performer). The genre portion should have a a textbox allowing the user to specify a value for an other genre in the dropdown list.

Or, if we are getting really fancy, SEVERAL Genre boxes in an AND or OR configuration! EG "Romantic" and ("Concerto" or "Chamber"). But maybe thats going a bit far... The current Advanced Search web page gives a dropdown list populated with all the Genre values that have been found in the database, thats a pretty good start.




- I need a tag that can describe the type of work (symphony, concerto, string quartet, chamber music) so that I can split of the works by one composer. Can I use Genre for this purpose?


Yes. See my notes on multiple genres. We'd need "genre" to be included in the extended browsing functionality that we have been debating.


Regards

Ceejay

ceejay
2005-12-05, 06:33
Hello again Bill and anyone else who's following this debate...

Attached is an attempt at specifying a set of enhancement requests. I've broken it down into a series of bite-sized chunks (though the last one is a bit bigger than the others).

The idea is to make substantial improvement for classical users without breaking too much of the current technology. Note that we could certainly go a lot further, but I figured that incremental is good.

The separate requests are:
(1) Add "Performer" contributor type
(2) Allow "Ensemble" and "orchestra" as equivalent to "Band"
(3) Expand the Advanced Search function in the Web interface
(4) Allow browsing by additional tags (eg Conductor)
(5) Add new multi-level browsing capability

I think I've incorporated just about everything of my and Bill's ideas, with just a couple of notes:

- I don't think we need the web page to construct a custom browse pattern if we have a fully flexible browse function

- I've left out the idea of a new "Work" tag for the moment, although I can certainly see how it might be handy. Trouble is, it doesn't seem to be in general use anywhere?

Debate and new versions most welcome. Note in particular that Multi-Level Browsing should be of interest not just to Classical users!

When we have some consensus I would hope can post this as an official enhancement request.

Regards
Ceejay

Robert Goldman
2005-12-05, 09:36
Ceejay wrote:

The separate requests are:
(1) Add "Performer" contributor type
(2) Allow "Ensemble" and "orchestra" as equivalent to "Band"
(3) Expand the Advanced Search function in the Web interface
(4) Allow browsing by additional tags (eg Conductor)
(5) Add new multi-level browsing capability

So is "Performer" intended to be effectively "soloist"?

ceejay
2005-12-05, 10:45
So is "Performer" intended to be effectively "soloist"?

That would be the idea, yes. "Performer" is the recommended standard for this in Vorbis, as far as I can see. You are apparently allowed to have as many as you like.

BTW - welcome to the debate - any views on the rest of the stuff we've been talking about, e.g. the suggested spec attached to my last post?

Ceejay

Listener
2005-12-05, 13:18
> The separate requests are:
> (1) Add "Performer" contributor type

What does SS do with it? Is it combined with Artist in the Artist search? Is it a separate Browsable tag?

> (2) Allow "Ensemble" and "orchestra" as equivalent to "Band"

I'd be OK with doing this automatically or by a checkbox on the setup page for (4). See below.

> (3) Expand the Advanced Search function in the Web interface

The menu of search fields on the SB should be based on the list of Browsable tags from (2). Should the advanced search page include just the Browsable tags from (2) or all the tags SS stores in the Database?

> (4) Allow browsing by additional tags (eg Conductor)

If the user checks for browsing on Composer or conductor, should that contributor still be added to the artist tag values for an artist browse? I'd put a second level checkbox under artist and band.

---- Sample setup page (default)

Browse on these tags

(X) Album
(X) Artist
( ) combine Composer tag with Artist
( ) combine Conductor tag with Artist
( ) combine Band with tag Artist

(X) Song Title (track title)
( ) Composer
( ) Conductor
( ) Band (this tag may contain an orchestra
or ensemble name)

( ) combine Ensemble tag with Band
( ) combine Orchestra tag with Band

You may alo browse on multiple tags successively to narrow
the list of albums or tracks that fit your criteria.

( ) add multi-level Browse to main menu

---- end sample page

> (5) Add new multi-level browsing capability

With the current browse artist, album and genre methods, you get to a list of albums. If you select one album from the list, you get a list of tracks. The description in the enhancement request text file says that after you select a value for the browse list, SS will present a list of tags that can be browsed next and a list of albums that meet the tag criteria already selected. At some point, you may need to display tracks rather than albums.

I'm not clear why Ceejay wants a list of albums to be displayed at each stage of the multi-level browse. I did a few experiments with Softsqueeze.

- If I use Browse Album, I get a list of albums after I select an Artist value and the choice "All Songs" is added to the list. If I select an album, I get the tracks that match the the Album I selected. If the Album name was not unique, I get all those tracks with the Album value I previously specified. They may come from several CDs.

- If I use Browse Artist, I get a list of albums after I select an Artist value and the choice "All Albums" is added to the list. If I select an album, I get the tracks that match the Artist and the Album I selected. If the Album name was not unique, I get only those tracks with the Artist value I previously specified. I I press play when the Album name is displayed, only those tracks that meet the selection criteria are queued up.

- If I use Browse Genre, I get a list of Artists after I select a Genre. If I select an Artist value, I get a list of Album values and the choice "All Albums" is added to the list. If I select an album, I get the tracks that match the Genre and the Album I selected. If my Album name is not unique, I get all the tracks with that Album

- If I use "Browse Year", I get a list of Album values and the "All Songs" choice is added to the list. If I select an album, I get the tracks that match the Artist and the Album I selected. If the Album name was not unique, I get only those tracks with the Artist value I previously specified.

Ceejay suggested that the multi-level browse should display a list of Albums after each Browse step. That isn't consistent with the way SS works now and I don't know that it fits for all stages for all previous selections. However, I'll propose a way to do what Ceejay wants.

A suggestion: After the user browses on one tag, display the list of browsable tags. If the user has already browsed the Album tag and selected one Album value, display the track titles that match the previously selected tag values. If the user has not yet browsed the Album tag, display the distinct album values for tracks that match the previously selected tag values.

The user should be able to press the "Play" or "Add" buttons to play the displayed Track or Album. However, the selections the user has already made may eliminate some tracks because they don't have the right tag values. That is how "Browse Artist" works now. That is how I think the multi-level browse should work.

---
The enhancement request text file calls it "Multi-mode browsing" which does not convey the sense that you can browse on some tag to narrow the list, then browse the list again with a different attribute to narrow the list further.

---
Even if the user has already browsed on a tag, he might want to do it again. (If Artist contains both Composers and performers and conductors and bands.) Why not present the same list of browsable tags at each stage?

ceejay
2005-12-05, 14:05
>
> (1) Add "Performer" contributor type

What does SS do with it? Is it combined with Artist in the Artist search? Is it a separate Browsable tag?


I'm sure this needs to be a separate browsable tag. That would allow you to browse (or search from the web page) for a case where performer=x AND conductor=y AND ensemble=z, for example.



The menu of search fields on the SB should be based on the list of Browsable tags from (2). Should the advanced search page include just the Browsable tags from (2) or all the tags SS stores in the Database?

I think just the browsable tags, but wouldn't want to defend this choice on the barricades. I was looking for simplicity.



If the user checks for browsing on Composer or conductor, should that contributor still be added to the artist tag values for an artist browse?

I can see that the scheme gives more flexibility, though I was hoping to keep it simple (to code and to use!) and I'm not sure this buys a lot. Given a capability to browse on Composer/conductor/band, I'd have thought you could drop the functionality to merge these tags with "artist", though backwards compatibility is of course a good thing.




Ceejay suggested that the multi-level browse should display a list of Albums after each Browse step. That isn't consistent with the way SS works now and I don't know that it fits for all stages for all previous selections.

Yes. I did give this quite a lot of thought. If you are narrowing down your selection I think it is critical to show the reduced data set as you go... otherwise its far too easy to end up specifying a combination with no matches, and then you're not sure where you went wrong. Similarly if you are applying selection criteria and get to a point where you have, say 3 or 4 items on your list, you might as well just scroll and select.

Agreed that if you ever select an album on your list, it must be time to drop into the tracks.



A suggestion: After the user browses on one tag, display the list of browsable tags. If the user has already browsed the Album tag and selected one Album value, display the track titles that match the previously selected tag values. If the user has not yet browsed the Album tag, display the distinct album values for tracks that match the previously selected tag values.

The user should be able to press the "Play" or "Add" buttons to play the displayed Track or Album. However, the selections the user has already made may eliminate some tracks because they don't have the right tag values. That is how "Browse Artist" works now. That is how I think the multi-level browse should work.

OK, this is definitely more complex than I was thinking of but I think I can see where you are going.

This note has reminded me of an unstated assumption that we should check. Is is safe to assume that all of the tracks within a single album will always have the same tags?

In my collection I have ensured that this is ALWAYS the case, because I can foresee some nasty sideeffects were it to be otherwise. It would certainly simplify things here if we could assume it. So far I've thought of just one case where this might realistically occur - you have an album of short songs (not long enought to be tagged as Albums in their own right) with different singers. Does this browser need to take this into account?



Even if the user has already browsed on a tag, he might want to do it again. (If Artist contains both Composers and performers and conductors and bands.) Why not present the same list of browsable tags at each stage?

No particular reason, again I thought it would be simpler. Actually the best reason I can think of for allowing a selection from a given tag type more than once is that some of these may well legitimately have multiple values for a single album/track. For example, a piece with multiple PERFORMERs, or with multiple GENREs. So, yes, present the same list of searchable tags each time. The coding might well have to impose a limit on the number of levels of search you can do, though.


Regards,
Ceejay

Listener
2005-12-05, 15:18
Bill> If the user checks for browsing on Composer or conductor,
> should that contributor still be added to the artist
> tag values for an artist browse?

Ceejay> I can see that the scheme gives more flexibility,
> though I was hoping to keep it simple (to code and to use!)
> and I'm not sure this buys a lot.
> Given a capability to browse on Composer/conductor/band,
> I'd have thought you could drop the functionality
> to merge these tags with "artist", though
> backwards compatibility is of course a good thing.

I agree that it would be simple and clean to drop the merge capability. I asked because it hadn't been settled.

> If you are narrowing down your selection I think it is critical to show the reduced data set as you go...

There is a distinction here between the web interface and the SB/remote interface. On a webpage, we can show the number of albums, artists, tracks that match. And you might as well display some values on the web page. On the SB display, you can't show much and scrolling takes more time than does scanning down the web page.

How about incorporating the number of matches into the menu choices:

Browse again for 6 Albums
Browse again for 75 Songs (Tracks)
Browse Again for 3 Conductors
...

With this feedback, you can see how the search is going at each stage and pick the best next step. If you want to tack a list of matching albums on after the browse choices, OK.

For the web interface, I think displaying a list of Albums (or Tracks if you have narrowed it to one Album) is reasonable.

> Agreed that if you ever select an album on your list, it
> must be time to drop into the tracks.

Good. Allowing the user to browse tracks at any stage gives him a way to choose whether to end with an album or a track.

Bill> The user should be able to press the "Play" or "Add"
> buttons to play the displayed Track or Album. However,
> the selections the user has already made may eliminate
> some tracks because they don't have the right tag values.
> That is how "Browse Artist" works now. That is how I
> think the multi-level browse should work.

Ceejay> OK, this is definitely more complex than I was
> thinking of but I think I can see where you are going.

Well, the SS does this logic for Browses now. I makes sense and it is consistent with what's being done now. I think you are building up the role of the Album in a way that is not necessary.

> This note has reminded me of an unstated assumption that
> we should check. Is is safe to assume that all of the
> tracks within a single album will always have the same tags?

> In my collection I have ensured that this is ALWAYS
> the case, because I can foresee some nasty sideeffects
> were it to be otherwise. It would certainly simplify
> things here if we could assume it. So far I've thought
> of just one case where this might realistically occur
> - you have an album of short songs (not long enought
> to be tagged as Albums in their own right) with different
> singers. Does this browser need to take this into account?

It is fairly common for the tags to be different for tracks on one classical CD. I recommended a Sony CD recently with an excellent performance of Beethoven's 4th symphony by Bruno Walter and an excellent performance of Beethoven's 8th symphony by George Szell. And it is common for a CD to have a concerto and a sonata. Same soloist but no conductor and orchestra for the sonata. Sometimes a CD has a symphony and a concerto. Sometimes a Cd has several symphonies or concerti with different composers, conductors, soloists and orchestras.

You might be careful to creat a different album name for each work but not everyone knows to do that or will make the effort. It isn't a safe assumption for SS to make.

Outside classical music, there are lots of Songbook CDs where the greatest hits of a composer like Gershwin, Porter or Berlin (or someone who is not yet dead) are song by various artists. You would want to keep the same album name for all tracks because you want to be able to find and play all the songs from the album. Maybe you could use the composer, but the name of the songbook is the natural way to do it.

SS does rely on the album name as a way to group tracks and collect properties. And you have gone farther in building a conceptual model. I think that extending the browse facilities in SS will go better if you don't organize browsing around your concept of an album. If you browse tags in a uniform way for all (browsable) tags, you get a better interface and one that handles things like tag values that are not the same for every track in an album. And it can better handle tracks with multiple values for a tag such as Artist.

> So, yes, present the same list of searchable tags each time.
> The coding might well have to impose a limit on the number
> of levels of search you can do, though.

Showing the number of Albums, etc. left to browse would help the user get to the end and stop there.

It seems as though we are converging on a detailed proposal.

Bill

ceejay
2005-12-05, 15:46
Bill,

yes, it looks as though we will soon be sorted, all we need is agreement for someone to code it for us! Pressing on with the remaining issues:


Bill> If the user checks for browsing on Composer or conductor,
> should that contributor still be added to the artist
> tag values for an artist browse?
...
I agree that it would be simple and clean to drop the merge capability. I asked because it hadn't been settled.

Can we then agree on the simple solution? i.e. we suggest that the merge capability be dropped?



> If you are narrowing down your selection I think it is critical to show the reduced data set as you go...
If you want to tack a list of matching albums on after the browse choices, OK.

This is exactly what I was thinking of. Have the "And Browse..." items at the top of the list, so you come to them first. Have the currently matching Albums (or tracks) below, so you can scroll into them if you wish. Top line of the display gives a clue as to how many there are, eg: "Browsing Beethoven / Karajan (57)"




It is fairly common for the tags to be different for tracks on one classical CD. I recommended a Sony CD recently with an excellent performance of Beethoven's 4th symphony by Bruno Walter and an excellent performance of Beethoven's 8th symphony by George Szell. And it is common for a CD to have a concerto and a sonata. Same soloist but no conductor and orchestra for the sonata. Sometimes a CD has a symphony and a concerto. Sometimes a Cd has several symphonies or concerti with different composers, conductors, soloists and orchestras.

You might be careful to creat a different album name for each work but not everyone knows to do that or will make the effort. It isn't a safe assumption for SS to make.

I'm going to disagree here... I think we have to state the asusmption that the music has been tagged correctly, which I take to mean with one Album per Piece (NOT CD). So the examples you've given would all be different Albums in my book. Apart from anything else, ALL other computer music players work on an assumption that the basic collection of tracks is an Album, so if you want to play this music on any other player, you are going to want it tagged this way. I for one really don't want differently tagged music for different players (and I really do use several).



Outside classical music, there are lots of Songbook CDs where the greatest hits of a composer like Gershwin, Porter or Berlin (or someone who is not yet dead) are song by various artists. You would want to keep the same album name for all tracks because you want to be able to find and play all the songs from the album. Maybe you could use the composer, but the name of the songbook is the natural way to do it.

Here I'll agree, this is similar to the example I gave. This should be tagged with Album = "Gershwin Songbook xx", track titles = song names, and "Performer" = singer for each track. The only dilemma here is how you use "Artist": the Vorbis standard implies this is meant to be a summary of the other information for players with limited display capbilities, ie you're supposed to choose the "most important" summary. In this example I'd probably go for "Gershwin" rather than the song singer, but I suspect this can remain a personal choice and doesn't need to be enforced in a standard.



SS does rely on the album name as a way to group tracks and collect properties. And you have gone farther in building a conceptual model. I think that extending the browse facilities in SS will go better if you don't organize browsing around your concept of an album. If you browse tags in a uniform way for all (browsable) tags, you get a better interface and one that handles things like tag values that are not the same for every track in an album. And it can better handle tracks with multiple values for a tag such as Artist.

Careful. "Artist", in the Vorbis standard, should only appear once. You can have multiple Performers, though.

And, as per my note above, all tags are not equal. "Album" and "Artist" have special meaning for most players, and to retain any kind of compatibility we have to respect that.

Regards

Ceejay

Listener
2005-12-05, 16:12
Bill> It is fairly common for the tags to be different for tracks
> on one classical CD. ...
> You might be careful to creat a different album name for each
> work but not everyone knows to do that or will make the
> effort. It isn't a safe assumption for SS to make.

> I'm going to disagree here... I think we have to state the
> asusmption that the music has been tagged correctly,
> which I take to mean with one Album per Piece (NOT CD).
> Apart from anything else, ALL other computer music players
> work on an assumption that the basic collection of tracks
> is an Album, so if you want to play this music on any
> other player, you are going to want it tagged this way.

I have been using iTunes, Foobar and MusikCube on a daily basis for some time and see NO evidence that they work on this assumption. Each of these players displays a list of tracks in rows with tag values in columns. I select tracks and perform some operation on them. It works fine when the other tags are noit the same for all the tracks with the same album value.

> I for one really don't want differently tagged music for
> different players (and I really do use several).

What other players do you use?

Bill> And it can better handle tracks with multiple values
> for a tag such as Artist.

Ceejay> Careful. "Artist", in the Vorbis standard,
> should only appear once.
> You can have multiple Performers, though.

Yes, I used Artist loosely. There are double concerti, and violin sonatas usually involve a piano player too. And operas and choral works will have more than one singer. I was referring to a practical need.

ceejay
2005-12-05, 16:31
Bill> It is fairly common for the tags to be different for tracks
> on one classical CD. ...
> You might be careful to creat a different album name for each
> work but not everyone knows to do that or will make the
> effort. It isn't a safe assumption for SS to make.

> I'm going to disagree here... I think we have to state the
> asusmption that the music has been tagged correctly,
> which I take to mean with one Album per Piece (NOT CD).
> Apart from anything else, ALL other computer music players
> work on an assumption that the basic collection of tracks
> is an Album, so if you want to play this music on any
> other player, you are going to want it tagged this way.

I have been using iTunes, Foobar and MusikCube on a daily basis for some time and see NO evidence that they work on this assumption. Each of these players displays a list of tracks in rows with tag values in columns. I select tracks and perform some operation on them. It works fine when the other tags are noit the same for all the tracks with the same album value.

> I for one really don't want differently tagged music for
> different players (and I really do use several).

What other players do you use?



OK, two different assumptions at work here.

(1) other tags not the same for all tracks with the same album value ... agreed, this is not a problem. I think we have established some good examples (songs) where you can have an album where one of the tags (certainly performer, possibly genre) might vary from one track to another.

(2) the assumption I think we should enforce for classical music... that "album" is set consistently for a Piece (eg Symphony).

I use iTunes, and Foobar, and MusicMagicMixer, as well as Slimserver, Softsqueeze and Squeezeboxes. And if you want to play, say, a Symphony in iTunes then by far the easiest option is to search by Artist and then Album. I really do not want to be fiddling with sets of tracks to make up the Symphony, or to be selecting ones from a CD. This is why I think "Album" is so important - it comes naturally not just to Slimserver in its current state, but also to other players as well.

Fortunately I don't think this needs distract us too much - I think we've nearly agreed on what will work, and it should be a strength rather than a weakness that the scheme can be used in more than one way.

Unfortunately its my bedtime now (I don't know which time zone you're in!) so I need to sign off. If you feel like writing up a new version of the enhancement request I posted, please do!

Regards

Ceejay.

Listener
2005-12-05, 17:25
One thing that perhaps hasn't been stated: The web interface should be extended with the multi-level browse command as we defined it for the SB/remote interface. And the Advanced browse should provide for searching all the browsable fields.

---
> And if you want to play, say, a Symphony in iTunes then by far
> the easiest option is to search by Artist and then Album.

Your way of using iTunes seems different than mine. I use the Composer attribute and sort tracks on it, select subsets withe the Browser window and now I'm using the Grouping attribute to associate tracks that make up a work. I hardly ever use the Search function.

Bill

ceejay
2005-12-07, 10:49
Bill and others

Please find attached V2 of the Enhancement request. I've split it into two parts - one for the "easy" bits (1-4) and a separate one for the Multi-Level Browse

(1) Add "Performer" contributor type
(2) Allow "Ensemble" and "orchestra" as equivalent to "Band"
(3) Expand the Advanced Search function in the Web interface
(4) Allow browsing by additional tags (eg Conductor)
(5) Add new multi-level browsing capability

I've done it this way because I propose to enter these as two separate entries into the Bugs database. We can then seek the easy stuff done being done quickly (maybe even 6.5) and take a little longer over the last one.

Also because I think the last one might be doable as a Plugin, and someone outside Slim might take that on.

I think I've incorporated all the stuff we've debated over the last few days.

Have a look...


BTW, I've seen a couple of unrelated threads which I think would be satisfied by the same Multi-Level Browse functionality that we have described, so we may be able to get support from outside the Classical users for that one.

Regards

Ceejay

Listener
2005-12-07, 16:16
Ceejay,

I attached my revision with a few notes and an alternative (search for "Bill's".) The multi-browse document was a text file. I used a text editor to view and it the file. For convenience, I added a few CR/LF. I hope this doesn't cause you an problems.

I added a more detailed explanation of the purpose of the multi-level Browse command. I think we are more likely to get some action from the developers if we provide justification.

Later I added to the exmple material to provide more detail on how we saw the new command working. I'd like to improve our chances of getting what we wanted after a developer puts in a significant amount of effort.

I changed the phrase "multi-mode" to "multi-level" (as I suggested in an earlier message.)


"And Browse 13 Conductors"

I proposed that each menu line describe how many values would be in the browse list if you choose that tag for the next browse. It provides feedback. I don't understand why you dropped that idea without giving a reason or informing me.

I changed "Artist" to "Composer" where it referred to Beethoven. Since SS is already storing Composer, I think the example is much clearer if we user Composer to refer to the actual composer.

I noticed that in the example you provided album names like "Symphony no 1". A day or two ago, you seemed adamant that the Album name should include the Composer name and the conductor name. I used the long form in the example material I wrote.

In the top line example, I changed "Browse Beethoven/Karajan" to "Browsed Beethoven/Karajan" to reflect its informational character as opposed to the second line items where "And Browse ..." are command to be executed.

Bill

Listener
2005-12-07, 17:37
Ceejay,

I have few comments on the text file for requests 1-4.

> Recognise these tags: "Performer" in Vorbis,
> TP1/TPE1 in ID3v2.2/2.3.

What Does SS use as Artist now? It seems reasonable that it is using TP1/TPE1.

> Request 2 - Alternate tags for "band".

I agree. One clarification. SS should always load all the contributor tags. These settings for adding other tags to Artist should just affect what is queried.

> Request 3 - Improve "Advanced Search" in Web interface
> (simplified version: superceded by Multi-Level Browse)

I don't see the advanced search as being superceded by the Multi-Level Browse. That allows you to specify several tags at once and see the result. Since this is a web interface only command, it is more tolerable to get a sizeable result set.

Some people would probably prefer to type two words (Composer and Conductor names) in the search form and get the answer in one step. I'd usually prefer to browse and avoid typing. SS should cater to both preferences.

> May want only to do this if there are less than N values to
> stop this getting out of hand. Ideally N should be
> configurable on this form - default say 50?

I'd say more like 20-30 items max in the list. However, for Genre, I'd show them all.

I think the developers should find a max. number that works well on the screen and wire it in.

> (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.

I don't understand why this has to be much more complicated than the single occurrence case. I see three ways to keep it simple:

a. Let the user pick one and only one value for a tag that may occur more than once (You specify John Williams. You get all the albums with John Williams, the guitarist solo and the albums with John and Julian Bream.)

b. Let the user specify more than one value with the logic being "choice 1 and choice 2". Specify "multiple (choices)" in the HTML defining the drop-down list. The SS code that handles the users input gets more than one value for the drop-down list control. Works just right for the two John and Julian Bream albums.

c. Let the user specify more than one value with the logic being "choice 1 or choice 2". Same HTML as for b. This would work for finding a performance of the Beethoven Violin Concerto with either Heifetz or Grumiaux as soloist. Worse than than a. for John Williams and Julian Bream albums.

I think that b. is the way to go.

> Request 4 - Widen list of tags for browsing (simplified
> version: superceded by Multi-Level Browse)

I presume that that the sequence of browse steps will be hard-wired for request. My preference for the hard-wired sequencesl:

Browse Composer => Album => Tracks
(like Browse Artist now.)
This is a pity. You want to listen to the fifth symphony. You don't remember all the conductor's performances in your library. You need to narrow it down to the fifth symphony and see what you have. So you have to hard-wire the sequence with album before conductor. However, if you have long album names, you already pick one album with one conductor. No point in browsing by conductor, after the long Album name is selected.

--- as aside
We really need to find a tag that can be given a short name for the work. I looked in the OGG Vorbis recommendations and don't see any easy answer in the standard tags. I do have a suggestion. Let the user specify a tag name for an OGG Vorbis tag he wants to store and use to browse. It would appear in the "Browse <tag>" list and in the "And Browse <nn> <tag>" menu items list.

I'd define "Work" as a tag to browse and use a tag editor to fill it out from the Album name." Someone else could choose whatever tag he has placed in his music files.

---
Browse Conductor => Composer => Album => Tracks
(same for performer or band. Note that this is different from
the way Browse Artist works now.)
If the composer field is empty for all the matches, skip that step.

Browse Genre or Year or Album - as it is now.
(none of the additional tags appear in the browse sequence for these commands.)

Bill

ceejay
2005-12-07, 17:49
Bill

thanks. No conspiracy involved in my last effort, just a few typos and simple errors! On the whole I agree with your changes: where you put in a fuller explanation of "why" I've deleted mine as its now redundant.

In the same way you changed my example where I had Artist=Beethoven to Composer=, I've changed your example of Artist=Haifetz to Performer=. This should make the example clear without getting caught up in a debate about how people choose to use "Artist" when we have this abundance of new tags to play with.

Just a couple of things I don't understand:

(1) In the web form section you wrote "Bill's Alternative: Just add a new "Browse by Tags" command to the main menu. The first step is for the user to select a tag to browse. This keeps the regular browse commands the same way they are now. I'm a bit leary of adding 6 or more lines to the list of choices in the existing Browse commands. I understand that it might be easier to implement the Multi-level Browse as a change to the behavior of the existing commands. However, I think it makes those commands more cumbersome to use." I don't understand the relevance of this to the web form. Did you mean this to go at the beginning of the discussion on the Remote UI behaviour?

(2) Your note "Bill's Note: this isn't consistent with your specification about removing a menu item for browsing a tag that has already been browsed." ... I changed the spec to work the way I think you wanted it, there shouldn't be any more references to removing a menu item, unless I missed one (apart from where I said you can't browse a tag twice if its only legal to have one of them, eg Artist)

(3) in the Web interface bit, you wrote "Bill's Note: I don't think this is a useful alternative. If you want to define a multi-level search, fine. It isn't a replacement for a browse.". Actually, I think it is - if you have the ability to see the result of the selection criteria you have entered so far, and if the selection boxes are prepopulated like Genre is, it is exactly equivalent to a browse. I wrote this because it occurred to me that the multi-level search (the extended version of today's Advanced Search) could be combined with the web version of the Multi-Level Browse. However, I'm not that bothered to be honest - I can see that some users will be more comfortable with seeing "browse" and "search" kept separate, if only because it maps better on to the Remote UI functions (which really do have to be different).

Other than these, and a few minor tidies I've put in, no real issues. Here's a further amended version. Your turn!

Regards
Ceejay

ceejay
2005-12-07, 18:29
And now we have two interleaved threads going, this is really going to confuse people!!



> Recognise these tags: "Performer" in Vorbis,
> TP1/TPE1 in ID3v2.2/2.3.
What Does SS use as Artist now? It seems reasonable that it is using TP1/TPE1.
Should be using TOPE/TOA.


> Request 2 - Alternate tags for "band".
I agree. One clarification. SS should always load all the contributor tags. These settings for adding other tags to Artist should just affect what is queried.
Sorry, don't understand.


> Request 3 - Improve "Advanced Search" in Web interface
> (simplified version: superceded by Multi-Level Browse)

I don't see the advanced search as being superceded by the Multi-Level Browse. That allows you to specify several tags at once and see the result. Since this is a web interface only command, it is more tolerable to get a sizeable result set.
I think I just responded to this in the other thread - ok, no problem with keeping browse and search separated in the web interface.


> May want only to do this if there are less than N values to
> stop this getting out of hand. Ideally N should be
> configurable on this form - default say 50?
I'd say more like 20-30 items max in the list. However, for Genre, I'd show them all. I think the developers should find a max. number that works well on the screen and wire it in.
ok


> (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.

I don't understand why this has to be much more complicated than the single occurrence case. I see three ways to keep it simple:

a. Let the user pick one and only one value for a tag that may occur more than once (You specify John Williams. You get all the albums with John Williams, the guitarist solo and the albums with John and Julian Bream.)

b. Let the user specify more than one value with the logic being "choice 1 and choice 2". Specify "multiple (choices)" in the HTML defining the drop-down list. The SS code that handles the users input gets more than one value for the drop-down list control. Works just right for the two John and Julian Bream albums.

c. Let the user specify more than one value with the logic being "choice 1 or choice 2". Same HTML as for b. This would work for finding a performance of the Beethoven Violin Concerto with either Heifetz or Grumiaux as soloist. Worse than than a. for John Williams and Julian Bream albums.

I think that b. is the way to go.
I thought I was keeping it simple. Your option "a" is the same as not doing the (4) "extra credit" and is certainly the simplest option.

I don't like your option "b" so much. Where the number of possible values is large, so having a pull down list is not practical, I want to be lazy and just type in part of a name (e.g. "Kara" or "Haif"). To make this work for both short and long lists, I'd prefer my idea of having selectable labels from the valid tags and value boxes which are either open or prepopulated as appropriate.


> Request 4 - Widen list of tags for browsing (simplified
> version: superceded by Multi-Level Browse)

I presume that that the sequence of browse steps will be hard-wired for request. My preference for the hard-wired sequencesl:

Browse Composer => Album => Tracks
Browse Conductor => Composer => Album => Tracks
Browse Genre or Year or Album - as it is now.

Yes, I think the sequence will have to be hardwired at this point. At the risk of being controversial, should it be Conductor=>Artist instead of Conductor=>Composer ? This would be on the grounds that "Artist" should always be populated with something, but "Composer" may well not be. It would also be consistent with "Genre".


We really need to find a tag that can be given a short name for the work. I looked in the OGG Vorbis recommendations and don't see any easy answer in the standard tags. I do have a suggestion. Let the user specify a tag name for an OGG Vorbis tag he wants to store and use to browse. It would appear in the "Browse <tag>" list and in the "And Browse <nn> <tag>" menu items list.

I'd define "Work" as a tag to browse and use a tag editor to fill it out from the Album name." Someone else could choose whatever tag he has placed in his music files.
Nice idea - a user defined arbitrary tag that you tell slim to look for and that you can then search or browse on ... I have no idea if this would create an implementation problem, but we can always ask. An "optional extra", perhaps?

Regards

Ceejay (past my bedtime again...)

Listener
2005-12-07, 18:49
> Just a couple of things I don't understand:

> (1) In the web form section you wrote "Bill's Alternative: Just
> add a new "Browse by Tags" command to the main menu. The first
> step is for the user to select a tag to browse. This keeps the
> regular browse commands the same way they are now. I'm a bit
> leary of adding 6 or more lines to the list of choices in the
> existing Browse commands. I understand that it might be easier
> to implement the Multi-level Browse as a change to the
> behavior of the existing commands. However, I think it makes
> those commands more cumbersome to use."

> I don't understand the relevance of this to the web form.
> Did you mean this to go at
>the beginning of the discussion on the Remote UI behaviour?

It relates to the way the multi-level Browse should work.

My alternative takes one more step to choose the first kind of tag to browse on. The advantage is that all the existing browse commands work exactly the way they do now.

A few cycles of posts ago, I proposed a setup screen to define a custom browse. The user picks a name for the browse and specifies the tag to be used at each step of the browse. This can be made shorter than the method you described or my alternative. You and Pat Farrell thought it was too much work to implement but I'm not sure.

> (2) Your note "Bill's Note: this isn't consistent with your
> specification about removing a menu item for browsing a tag
> that has already been browsed." ... I changed the spec to
> work the way I think you wanted it, there shouldn't be any
> more references to removing a menu item, unless I missed
> one (apart from where I said you can't browse a tag twice
> if its only legal to have one of them, eg Artist)

I wrote two notes about this. First you said

" The multi-level Browse process could in principle continue forever"

then later you said

"The tags (Album, Artist, Year, Title, etc.) should only occur once so can be omitted from the "And Browse" entries"

If you omit a "And Browse <nn> <tag>< menu item for an already browsed tag, the process end when you have browsed all tags.

> (3) in the Web interface bit, you wrote "Bill's Note: I don't
> think this is a useful alternative. If you want to define a
> multi-level search, fine.

> It isn't a replacement for a browse.". Actually, I think it
> is - if you have the ability to see the result of the
> selection criteria you have entered so far, and if the
> selection boxes are prepopulated like Genre is, it is
> exactly equivalent to a browse. I wrote this because it
> occurred to me that the multi-level search (the extended
> version of today's Advanced Search) could be combined with
> the web version of the Multi-Level Browse. However, I'm not
> that bothered to be honest - I can see that some users
> will be more comfortable with seeing "browse" and "search" kept
> separate, if only because it maps better on to the Remote UI
> functions (which really do have to be different).

You reply was mushed together with my test you quoted.
I think I understand your original text now. I do have a comment about such a search:

When you populate the lists initially, some will be too,long to be useful. So you may need to do a second or third step an requery the DB and repopulate the drop-down list.

ceejay
2005-12-08, 15:43
Bill and others (is anyone else reading this??)

V3 attached. Again have generally incorporated most recent discussions. A few points to note:

(1) I've added the "User Defined" tag as Request 5 in the "easy" file. I thought of a couple more uses for this, have put them in to reinforce the case.

(2) In request 4 I've added examples to show the proposed hardwired browse sequence. I've kept "Artist" as the second level for some of them rather than "composer" - I'm fairly sure this is right, all albums should have an Artist tag associated... and if we don't do it this way we risk breaking the behaviour big-time for non-classical users.

(3) in the MLB one I've added the text "Certain tags (Album, Artist, Year, Title) should only occur once so can be omitted from the "And Browse" entries if they have already been used. All others can be used multiple times and so should continue to appear as options in successive browse levels." to clarify the bit about which tags can be used more than once in the query.

I think (hope?) we are nearly done on this - I think its time to submit what we have and seek support. Any comments?

Regards
Ceejay

Listener
2005-12-08, 17:52
--- Comments on enhancement req classical v3.txt
Other than the comments below, I think it is fine.

> Request 5 - User Defined Tag

I appreciate your adding this request.

You worded it in terms of an Ogg Vorbis user defined tag.
My idea was just to let the user specify the name of some tag to be treated as Composer, etc. can be used. That includes standard Ogg Vorbis tags and ID3 tags. For example, iTunes lets you specify a Grouping attribute for tracks and the value in the CONTENTGROUP tag (ID3V2).

I'd like to just specify a tag that exists in my files and tell Slimserver to start using it. This should work for MP3 files or FLAC files.

I realize that for ID3v2 tags, the identifier stored in the file may be an appreviation but I think that complication can be handled one way or another.

A question: If the user is able to choose any tag he wants to use, how do we predefine the hard-wired browse order for a not-yet-defined tag?

An observation: Getting a short Work name is the key step for me to be able to use SS/SB successfully. However, the solution also requires being able to Browse Tags in the right sequence: Composer, Work, Conductor, album would be the most common sequence for me. That browsing sequence won't make sense for everybody and every possible additional tag. Request #5 becomes much more useful with the Multi-level browse capability.


---- enhancement req mlb v3.txt

It looks finished to me. Thanks for all the work you have put in on this and the beginners guide.

Bill

ceejay
2005-12-09, 02:11
OK, lets declare it done then.

Re Request 5: I've added some words to the "User Defined Tag" request to clarify treatment of different tag types. The Browse sequence, as I previously wrote, should I think be the same as for Genre, that covers most possibilities. I also agree that this really comes into its own when the Multi-Level Browse comes into play, but I can see it would have several uses even as a standalone improvement.

Final versions of the documents attached.

I will now post a whole load of bug requests and start a new thread in the Forum for discussion - this one has gone on long enough!

Ceejay

Listener
2005-12-09, 11:33
Ceejay,

Thanks for putting a lot of thought and effort into these requests.

As you stated in the new thread, there aren't any players that support classical music libraries very well now. These enhancements will give the Slimserver/SB combo the best UI around for classical music.

Bill