Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vocalpoint]

Happy Holidays!

Doing a bit of library cleanup this week and had a question on a view that I have that displays recent albums by year. It's very basic - just displays albums releases from a given year and right now I have it showing "stacks" of albums from the year 2000 - 2013.

The view works great but I want to ensure it only displays "full" albums. Right now - I see the occasional "album" that is really a comp but has one track from 2002 so this single track shows up as an "album" in the 2002 stack. Same thing for singles...one or two track single dated 2005 - so it shows in the 2005 view.

I really want to ensure this view shows only albums that are truly full - no single tracks etc. Any expressions or tricks I can try?

Cheers,

VP

[connersw]

Right Click on the View -> Customize View -> Settings -> Set rules for file display -> Rules -> Add New Rule

Drop downs:
1st: Complete Album
2nd: is
3rd: True

[Vocalpoint]

Right Click on the View -> Customize View -> Settings -> Set rules for file display -> Rules -> Add New Rule

Drop downs:
1st: Complete Album
2nd: is
3rd: True

Already have tried this within the view - no change. That said - I do not believe this has any effect within a "view".

Ex: if I have a single track (from a comp) suddenly appearing in my 2002 "albums" view - simply because that track has the year 2002 in it's tag - does not mean the actual comp album it comes from is incomplete. Rather the opposite - the actual comp has 15 tracks and is "complete" so I can see why this track appears in here.

Any other ideas?

VP

[connersw]

Yeah, I don't do that.  I use the year the compilation was released; not when the track originally was.

My suggestion works; just not with the way you keep your tags.  You would need to do something in your view hierarchy to keep the whole album together.  For example, Album Artist. 

[glynor]

You may want to search the forum some more...

I'm reasonably sure I've seen MrC help someone solve this exact query before.

[Vocalpoint]

Yeah, I don't do that.  I use the year the compilation was released; not when the track originally was. My suggestion works; just not with the way you keep your tags.  You would need to do something in your view hierarchy to keep the whole album together.  For example, Album Artist. 

I use Album Artist consistently - but that doesn't matter for this problem. For all my comp albums - every if the Album Artist is a single artist - each track on the comp gets it's orginal release date/year - vs using the release date of the comp.

That way - when I am rocking playlists - the tracks stay within their correct decades/time frames. I can't have a track originally released in 1972 - suddenly appearing in a playlist that is 2005-present - just because the comp album the track is on - was released in 2007.

VP

[MrC]

If you have an album with 9 tracks originally released in 2010 and 1 track from 2000, should that album be included at all, or rejected even from the 20010-2013 grouping (because it would be incomplete, missing the single 2000 track)?  Or should the 9 tracks be included, and the 1 track omitted from all groupings?  What about 8 and 2?  Or 7 and 3?

[Vocalpoint]

If you have an album with 9 tracks originally released in 2010 and 1 track from 2000, should that album be included at all, or rejected even from the 20010-2013 grouping (because it would be incomplete, missing the single 2000 track)

If there is a way to do it - my preference is to completely ignore anything that is NOT a full album - including any comps, singles etc. A comp like a Greatest Hits - to me - is not an "album" in the same sense of something like a newly recorded collection of tracks done for a movie soundtrack or similar.

Take a comp like - Encomium - A Tribute To Led Zeppelin - this one works with it's 3/14/1995 release date as all tracks were released on the same day - while others - like Foo Fighters Greatest Hits (with tracks spanning 1995-2008) - I do not care to see in any album view. I would not tag that collection with a November 3, 2009 date either since it makes no sense to me or the structure of my smartlists.

So - if a comp has just 2 tracks from 2001 on it - I do not want to see that album - at all - in my 2001 view. Or any other view for that matter.

VP

[6233638]

If there is a way to do it - my preference is to completely ignore anything that is NOT a full album - including any comps, singles etc. A comp like a Greatest Hits - to me - is not an "album" in the same sense of something like a newly recorded collection of tracks done for a movie soundtrack or similar.

The easiest way I can think of to do this, though it might require some work, would be using keywords to tag an album as a "compilation" or a "single" and excluding those keywords from your view.

[MrC]

Ok, in that case...

If you want a semi-automated way to do this, you probably want to calculate the range of track dates for your albums.  You'd setup a maintenance view which will be used to calculate the High and Low years of each album, and store those in some field or two.  You could use a single field, such as Track Date Range, and it could be formatted as YearLow;YearHigh and just a single Year when high = low, or set YearLow and YearHigh to be the same thing, or you could use two fields, a YearHigh and a YearLow field and set those only when the dates vary.  You'd assign these fields in your maintenance view, and the view would use global variables to do the cross-track, album-wide calculation.  You'd  use this view to calculate all your albums the first time, and you can manually configure these fields for the future, or re-run the assignment en-masse.

Then, in your smartlist, you will not include any tracks if YearHigh and YearLow differ, or are outside of any single range.

[Vocalpoint]

Ok, in that case...

If you want a semi-automated way to do this, you probably want to calculate the range of track dates for your albums.  You'd setup a maintenance view which will be used to calculate the High and Low years of each album, and store those in some field or two.  You could use a single field, such as Track Date Range, and it could be formatted as YearLow;YearHigh and just a single Year when high = low, or set YearLow and YearHigh to be the same thing, or you could use two fields, a YearHigh and a YearLow field and set those only when the dates vary.  You'd assign these fields in your maintenance view, and the view would use global variables to do the cross-track, album-wide calculation.  You'd  use this view to calculate all your albums the first time, and you can manually configure these fields for the future, or re-run the assignment en-masse.

Then, in your smartlist, you will not include any tracks if YearHigh and YearLow differ, or are outside of any single range.

Thanks for the tips. But I do not think this would work for singles (where say we have a CD single with 3 cuts - all with the same year) - this would still show up.

I think I need a custom field - and while I just stumbled across Album Type - sadly it's a read only field - but does contain data placed by MC - albeit not useful to this issue.

This custom field could assign things like:

Single Artist (Album)
Single Artist (Compilation)
Single Artist (Single)

and so on. My views would use Single Artist (Album) and should be problem solved. Guess I will need to make a custom field and do a little work myself

Cheers,

VP

[MrC]

Of course there is no way to automatically detect what you consider "an album" (i.e. your CD w/3 tracks), so those would need to be tagged manually to differentiate them.

Still, you could use the technique I suggested as a first past, best-guess effort, and then override manually those that need adjustment.  You don't need to use a Hi/Low field, but could use a Boolean field instead that you set either manual, or automatically (initially, at least) based on the Hi/Low evaluation.

The Album Type is auto-generated from MC's album analyzer.  The Complete Album field comes from this analysis too.