>No, it does not. It stores a contributor that is used only for album >sorting (by artist) purposes. It does not store an album artist role in >the contributor_album table for the album. If there is no ALBUMARTIST >tag, then every time it puts together an 'album_name by artist' string >it has to retrieve the artists for every track on the album and then >parse them to construct the string. This is why, if you have no >ALBUMARTIST tags for non-compilations, generating a single page full of >albums requires hundreds of queries. As an example, if you had a page of >100 albums with an average of 12 tracks per album, it will take a >minimum of 1200 queries just to generate that one web page. It's little >wonder that it takes a couple of seconds to spit out a page on even the >fastest servers. Doing it the other way would take _one_ query.
The thing is, you can have more than one album artist per album. It is possible to retrieve the correct info in less queries. eg. one query to return a list of unique artists for all songs on an album, so would require 1 query for the list of 100 albums, and 100 queries (1 per album) to get a list of the artists on each album. If there were a rule that there should only be one album artist per album, then it may as well use album.contributor for quickly returning this. That wouldn't work well for me, because I like having albums appearing under each primary album artist. eg. "No Pussyfooting" appearing under "Robert Fripp" and also under "Brian Eno", rather than nominally choosing only one of those artists to list under. I'd also not like to create an aggregated name, eg "Fripp & Eno" as the album artist for it to only appear under, as I could not then see all Brian Eno work in one list. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
