[thomash72]

As described in many threads in this forum, XBMC does not currently support a good way of organizing a music collection which is a combination of singles and full albums.
Here is a proposal for how this can be resolved:

If the tag ALBUM = <empty>, then XBMC will recognize this track as a 'single' song, without relation to other tracks.

Advantages:
1. It will work for all music formats, since all formats contains an ALBUM tag. No extended tags are needed.
2. It's intuitive and easy to communicate to all users: If a track is a 'single track' without relations to other tracks, then it makes sense that ALBUM tag = <empty>. The track does not belong to any album.

Disadvantages (and why they are not ;-)
1. Some may argue that some albums does not have a title, and hence ALBUM = <> is a valid album name. But to me, it seems like the de-facto standard is this case is that in such cases the ALBUM tag is set to the name of the artist.
2. Some may argue that the proposed solution does not cater for physical single-albums which typically contains 2 - 3 songs. But I would argue that the proposed solution caters for this as well: If you put ALBUM = <single name> for the 2-3 songs, then you want XBMC to treat this as a mini-album. On the other hand, if you set ALBUM = <empty>, then you want the tracks to be organized as individual single tracks.

Proposal for changes in XBMC GUI:
1. All tracks with tag ALBUM = <empty> are removed from Album view.
2. In Artist view, you get a new entry called 'Singles' below the listing of the full albums from this artist. The tracks with ALBUM = <empty> will be available here.
3. XBMC read the embedded image of each file with ALBUM = <empty>.

I look forward to hearing your opinion on this proposal!

[stokedfish]

That doesn't sound too bad.

2. In Artist view, you get a new entry called 'Singles' below the listing of the full albums from this artist. The tracks with ALBUM = <empty> will be available here.

I'd call the GUI entry "Loose Tracks" instead of "Singles".

[jmarshall]

Not a bad solution. We'd still need special-casing for saving of album thumbs I think (actually I think it could be done by _not_ caching an album image if no album tag is present...)

EDIT: No special-casing needed, it appears to already not cache thumbs for the album in that case. Perhaps it caches as the folder thumb - let me check that.

If you could do some tests as to what of the above works and what doesn't that'd be great!

Cheers,
Jonathan

[jmarshall]

Ok, initial implementation in patch form is available here:

http://trac.xbmc.org/ticket/7061/

Things to be discussed:

1. Should these virtual "singles" albums be available in the main album listing? They'd be grouped by artist if sorted by artist, so I'm not sure whether there's a problem with this (perhaps it should thus be optional?). ATM you can only get to singles by browsing via artist or via songs.

2. Do we need any sort of "Singles" node in the library?

3. Any problems with the patch, other than cosmetics (eg the "Singles" string needs to be localised).

Cheers,
Jonathan

[spiff]

4) should we make a more verbose xsp rule? blank album might not be completely intuitive

[stokedfish]

Will this patch be included in Ubuntu PPA SVN builds? Like, tomorrow? Then I could help out with testing.

But please, call it something else than Singles!

http://en.wikipedia.org/wiki/Single_(music)

A Single is a Single Album and has nothing to do with a Loose Track. So why not call it Loose Tracks instead?
Calling something Single that has nothing at all to do with a Single just makes things even more confusing...

[spiff]

the patch obviously won't be commited to svn before its ready.

[seedzero]

A Single is a Single Album and has nothing to do with a Loose Track. So why not call it Loose Tracks instead?
Calling something Single that has nothing at all to do with a Single just makes things even more confusing...

I don't think "loose track" sounds as good as "Single". While it might not fit the classical definition of "Single", these days tracks are purchase on their own from digital retailers and could be defined as such. I don't think it's anything to worry about myself.

[stokedfish]

Well then, how about...Tracks?

When browsing albums you get albums, when browsing TV Shows you get tv shows, when browsing Movies you get movies, but when browsing Singles you get random loose tracks?! This makes no sense at all. That's like calling movies TV Shows...just...wrong. Totally wrong.

[seedzero]

Well then, how about...Tracks?

When browsing albums you get albums, when browsing TV Shows you get tv shows, when browsing Movies you get movies, but when browsing Singles you get random loose tracks?! This makes no sense at all. That's like calling movies TV Shows...just...wrong. Totally wrong.

Yeah but you can have a "Track" within an album. I realise that you can also have a single within an album, but there isn't as much confusion. "Single Track(s)" would be more acceptable. And I don't agree with your analogies re TV shows and movies (sorry)

[thomash72]

Ok, initial implementation in patch form is available here:

http://trac.xbmc.org/ticket/7061/

Things to be discussed:

1. Should these virtual "singles" albums be available in the main album listing? They'd be grouped by artist if sorted by artist, so I'm not sure whether there's a problem with this (perhaps it should thus be optional?). ATM you can only get to singles by browsing via artist or via songs.

2. Do we need any sort of "Singles" node in the library?

3. Any problems with the patch, other than cosmetics (eg the "Singles" string needs to be localised).

Cheers,
Jonathan

My quick 2 cents on these questions:

1. I don't think this is stricly needed, specially not if the answer to question number 2 is yes.

2. Yes - for me it would be logical to have a 'Singles' node in the library. This would make it easy to browse/play all your 'Singles'.

3. I'm afraid I'm not a technical person, so I wont be able to test before the patch is committed to an SVN

I really look forward to testing this in SVN.
For me, with this in place XBMC moves a step closer to perfection

PS I do not have any strong opinions on the naming (ref other discussion in this thread). 'Singles', 'Tracks' and 'Single Tracks' are all OK with me. If I had to choose, I'd go for Singles, since I believe the old meaning of the 'singles mini album' will disappear with more digital purchases of music.

Thanks!

[Dilligaf]

What about artist.nfo? this is stored one level above where the track is. My collection is organized Artist/Album with singles left in the artist folder, this makes the artist.nfo appear one level above the artist folder, can the default behavior be changed to store artist.nfo in the same folder as the single when singles are present?

Mike

[ronie]

3. Any problems with the patch, other than cosmetics (eg the "Singles" string needs to be localised).

i couldn't find any.
works a treat and like a charm too.

thanx for the patch jm.

[thomash72]

As a fanart junkie/perfectionist/lunatic (take your pick, my girlfriend's choice is the latter) I have to ask:

Will the scraper be able to pick up artist fanart from htbackdrops for tracks identified as 'singles'?
And is it maybe a good idea to have the scraper look for local artist-fanart.jpg, where the artist name is read from the tag?
I assume most people will store many singles from different artists in the same folder, so a joint fanart.jpg will not work...

[ronie]

Will the scraper be able to pick up artist fanart from htbackdrops for tracks identified as 'singles'?

yup, with the current patch, the scrapers will download fanart, artist thumb and artist info.