Print

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

[shdmn]

Hi guys,

I've been looking for a solution to this little quirk for a while now and have come up dry. What I would like to be able to do is to have JRiver display albums with multiple artists as:

%Album% by %Album Artist%

instead of

%Album% by "Various Artists"

This is not an issue with sorting, as JRiver is organizing my music in accordance with my folder structure, and I'm thinking this is most likely just how JRiver handles mutliple artist albums internally, but would like to get confirmation that this is either the case, or a workaround exists.

Here is a picture highlighting what I am referring to.

[Arindelle]

Although I can get into this and make a real long post about custom views and maybe push  the need for both artist and album artist based views ... especially if you have a lot of compilation type albums I'll avoid that for now

What you are seeing is the way JRiver by defaults groups albums. You should read the wiki on topics like album artist and album artist (auto) fields, but long story short this will self-regulate if you retag the album differently. The problem (I guess its my opinion that is really a problem, but hey  ) is that all tags in the album will display Various Artists if they don't have the same Artist for each track. That is not to say you can't have an album with 2 or more artists .. if they are the same on each track they will not show up as various artists.

The reason I think dates to mp3 tagging where the metadata is really very limited so you often see Feat. or Featuring in the artist tag.

In your example if all the tracks were tagged with Eric Prydz that's what it would say instead of Various Artists. So either you edit the tag and remove the two tracks that are messing this up, or you live with it like it is.  I personally refuse both of those options What I do is just move the featured people to the Soloists tag. That way you can still search for them or even make views based on the soloist field.  A simple way to retag is just to select the tracks in question and in the soloist (or the field of your choice) type =[Artist] from the tag window. Then just edit out the "Eric Prydz feat." -- there is a find and replace tool if there are lots of to do BTW).

On a side note, for real "Various Artists" albums like compilations, if you remove the "feat." and replace it with a semicolon, it will give the opportunity to displat and search for both "artists" separately. Which is a real plus. eg. Eric Prydz feat. The Cut would become Eric Prydz; The Cut. As I said there is a tool to do this so it doesn't have to be manually done for each track. You don't want to do this for your example though as it really is Eric Prydz's album.

You could ask for a change in a feature request, but this is really a basic part of how JRiver groups things and some users' dependence on not filling out the Album Artist field, why I sort of doubt this will change any time soon (why the Album Artist (Auto) field is there. ) here's some more info on that https://wiki.jriver.com/index.php/Album_Artist_and_Album_Artist_(Auto)

[blgentry]

There's a relatively simple fix, but it's not exactly obvious how to do it.  The text that you see displayed there is indeed generated by MC because it sees different values for [Artist] in the songs on the album.  This display is controlled by the Group By setting.

In your screen shot, in the header of the file listing, see where it says "Opus Files" ?  Click on that and you'll get a menu.  On that menu is Group By.  Group By controls what text is displayed there.  The default is what you see.  But there's a little wrinkle here:  Group By will only display single fields from MC's Library.  So what if you want something custom there?  You make a new library field with custom data.

In your case, I'd make a field named something like [Album by Album Artist] .  The contents of that field should be "calculated data".  In the calculated data put something like:

Code: [Select]

[Album] by [Album Artist (auto)]
Then, go to the Group By menu and select your new field you just built.

I just tried this and it seemed to work correctly for both "regular" albums and albums with more than one artist listed, displaying the way you want it to.

Good luck.

Brian.

[Arindelle]

Yep, this is an interesting work-around that Brian is suggesting.

But this is going to be a per view fix and could lead to some hassles if you want to import views from Standard Mode into Theater or Remote modes. If the tags are corrected it will work for everything, on the other hand ... regardless of how many Views you actually are using and in what mode.

If you think that the actual tag should really be "x featuring so and so", however Brian's idea works nicely. But at the end of the day, the choice might be what's easier for you.

[shdmn]

There's a relatively simple fix, but it's not exactly obvious how to do it.  The text that you see displayed there is indeed generated by MC because it sees different values for [Artist] in the songs on the album.  This display is controlled by the Group By setting.

In your screen shot, in the header of the file listing, see where it says "Opus Files" ?  Click on that and you'll get a menu.  On that menu is Group By.  Group By controls what text is displayed there.  The default is what you see.  But there's a little wrinkle here:  Group By will only display single fields from MC's Library.  So what if you want something custom there?  You make a new library field with custom data.

In your case, I'd make a field named something like [Album by Album Artist] .  The contents of that field should be "calculated data".  In the calculated data put something like:

Code: [Select]

[Album] by [Album Artist (auto)]
Then, go to the Group By menu and select your new field you just built.

I just tried this and it seemed to work correctly for both "regular" albums and albums with more than one artist listed, displaying the way you want it to.

Good luck.

Brian.

That's fantastic, thanks for the solution. I certainly wouldn't have thought to make a calculated field, but that makes sense. Thanks Brian.

Yep, this is an interesting work-around that Brian is suggesting.

But this is going to be a per view fix and could lead to some hassles if you want to import views from Standard Mode into Theater or Remote modes. If the tags are corrected it will work for everything, on the other hand ... regardless of how many Views you actually are using and in what mode.

If you think that the actual tag should really be "x featuring so and so", however Brian's idea works nicely. But at the end of the day, the choice might be what's easier for you.

You're right, it's not the most universally intuitive solution, but it works. In my case, my entire library is tagged correctly, such that the album artist tag exists only when multiple artists are present. If JRiver didn't implement the [Album Artist (auto)] field in the way where it falls back to the Artist when an Album Artist isn't present, Brian's solution simply wouldn't work for my library.

Thanks for the help guys!

[shdmn]

Okay, so I've come across one small snag. Before, I was using Group By > Album (by date) which displayed albums ordered chronologically. The [Album] by [Album Artist] solution defaults to an alphabetical ordering.

So what I would like to be able to do is retain the [Album] by [Album Artist] ordering, but sort chronologically, without displaying the date in the header.

I guess this leads to the question: Is there a way to specify sorting when creating a calculated custom field?

[Arindelle]

Okay, so I've come across one small snag. Before, I was using Group By > Album (by date) which displayed albums ordered chronologically. The [Album] by [Album Artist] solution defaults to an alphabetical ordering.

So what I would like to be able to do is retain the [Album] by [Album Artist] ordering, but sort chronologically, without displaying the date in the header.

I guess this leads to the question: Is there a way to specify sorting when creating a calculated custom field?

IMO, generally speaking, you should make sort orders part of the view (there is a secondary benefit to this as I mentioned - you can export standard views to Remote and Theater Mode views - saving a bunch of time once you evolve, rather than be dependant on drop down menus.)

Sort Orders and even disaply "categories" can be set in the View itself

Here's an example of the sort order by date. You can choose what you display in the header (columns) as this will override it.



 ... and you can even combine fields (or use expressions or playlists even) in the category box.  In this way you can often avoid creating custom fields



You have a lot of options using MC on how to do it. If using the menu method, as I mentioned you are limited to Standard Mode again. There are ways to include sort expressions inside of a custom field I suppose, but arguably, this gets over-complicated.

Edit: you mention something about the Album Artist (Auto) field ... I tend to avoid using that field (not that you can't of course ) Should you need to populate the more universal Album Artist field you can simply select and type =[Album Artist (Auto)] or if you meant the opposite, that you prefer using just the [Album Artist] field, you can substitute that in Brian's expression. They are the same (or should be) both will be written to the file ( in a tag dump you will see the field Album Artist twice in the metadata

[blgentry]

IMO, generally speaking, you should make sort orders part of the view[...]

Unfortunately, this sorting does not apply to the details pane below like we are discussing.  The sort order only applies to the categories.  Once you get into the details pane, at the last stage of a categories view, the Group By determines the entire sort order.  This is kind of a weird part of MC that honestly doesn't make a ton of sense.

Edit: you mention something about the Album Artist (Auto) field ... I tend to avoid using that field (not that you can't of course ) Should you need to populate the more universal Album Artist field you can simply select and type[...]

I've seen you and others say things like this before.  In a respectful way I'm going to say that I think this is bad advice.  [Album Artist (auto)] is super powerful and should be used just about everywhere that you want to see the primary artist on an album.  It is "automatic" in that it takes either the value from Album Artist, OR from Artist, in that order.   I see no down sides to using it.  Note that you should never *type* values into [Album Artist (auto)].  You should only type values into [Artist] or [Album Artist] and let [Album Artist (auto)] populate itself automatically.

Brian.

[blgentry]

Okay, so I've come across one small snag. Before, I was using Group By > Album (by date) which displayed albums ordered chronologically. The [Album] by [Album Artist] solution defaults to an alphabetical ordering.
[...]
I guess this leads to the question: Is there a way to specify sorting when creating a calculated custom field?

As far as I know, the answer is No.  The best you can do is to try to hide the Year or Date field in your calculated field, by using a font color (or something) that makes it not show up.  Edit:  I found the thread I was thinking of.  An expression like this will work:

Code: [Select]

<font size="10" alpha="0" color="ffffff">[Year]<//font>[Album] by [Album Artist (auto)]
Here's a link to the whole thread:

http://yabb.jriver.com/interact/index.php?topic=85859.0

The above expression should sort by [Year] first, and then by Album name, and display what you want while invisibly hiding the [Year] so you don't see it.

Brian.

[Arindelle]

Unfortunately, this sorting does not apply to the details pane below like we are discussing.  The sort order only applies to the categories.  Once you get into the details pane, at the last stage of a categories view, the Group By determines the entire sort order.  This is kind of a weird part of MC that honestly doesn't make a ton of sense.

Yes I was talking generally and not about a detail pane from a category view. However, it still seems to work like the OP wants. see attached screenshot - sorting albums by dates in the detail pane. I can remove any column I want and no specific fields. In saying that, I'm using [Album Artist] not [Album Artist (Auto)] for whatever that's worth in the sort rule (like in my screenshot above).

So this seems to work for details under Categories, but also in a Panes type view too, at least in Windows. Not sure why it doesn't for you,  Brian?  Also this works if you have multiple levels to drill down from – I can go from the top level or drill down to the last category.

I've seen you and others say things like this before.  In a respectful way I'm going to say that I think this is bad advice.  [Album Artist (auto)] is super powerful and should be used just about everywhere that you want to see the primary artist on an album.  It is "automatic" in that it takes either the value from Album Artist, OR from Artist, in that order.   I see no down sides to using it.  Note that you should never *type* values into [Album Artist (auto)].  You should only type values into [Artist] or [Album Artist] and let [Album Artist (auto)] populate itself automatically.

Brian.

There are no downsides to using the (auto) field necessarily. As I said I prefer to use the non-auto field. If you don't mind that your [Album Artist] might be empty; if you never use external taggers and rippers; if you never need to export to other players; and if you never have multiple Album Artists per Album. It doesn't matter.

If you occasionally do any of the above, I want to make sure that this key field is filled in. I also prefer it be left blank and obvious, than fill in an album as a compilation, based on bad track names (or featured etc. ), but that’s completely personal. Now that doesn't mean that I think using the auto field is bad advice either, Im' not arguing the point.   I do however want to make sure that the [Album Artist] is never empty, though. The (auto) field insures that it, itself,  will not be empty, but it will not fill in the Vorbis field.

Using only JRiver though, there can be some inconsistencies when using the auto field. Example: with multiple Album Artist (separated by semi-colons), this can cause some glitches, if you are using sort fields and different display orders (now we have the swap and unswap functions so its easier). I want to make sure these are split correctly. This is more obvious  as the handling is different in displaying icons in Theater View and Remote Views. This might make not make any difference to most people of course.  So it doesn't matter, but its not necessarily bad advice either. Regardless, if a user finds they really need to use just [Album Artist],  and not use the auto field, it is very easy to populate the other with one simple tag entry.

[blgentry]

However, it still seems to work like the OP wants. see attached screenshot - sorting albums by dates in the detail pane.

Your screen shot only sorts by Date because you're using Group By > Album .  This auto sorts by Date.  It's a built in "magic" behavior.  If you set Group By to Album (by Date) it sorts by inverse Date.  Again a magic behavior that is not changeable.

Now, try setting Group By to something else.  Now it will sort based on the Group By field.  Try [Artist - Album (Year)] .  This is an included Library field.  It will now sort alphabetically by that field.  Group By controls the sorting in the details area.  You can't change it anywhere else.  If you could, you could sort by album title.  But you can't.  Because group by > album has magic logic built in to sort by date.

I hope that makes sense.

Brian.

[Arindelle]

Your screen shot only sorts by Date because you're using Group By > Album .  This auto sorts by Date.  It's a built in "magic" behavior.  If you set Group By to Album (by Date) it sorts by inverse Date.  Again a magic behavior that is not changeable.

Now, try setting Group By to something else.  Now it will sort based on the Group By field.  Try [Artist - Album (Year)] .  This is an included Library field.  It will now sort alphabetically by that field.  Group By controls the sorting in the details area.  You can't change it anywhere else.  If you could, you could sort by album title.  But you can't.  Because group by > album has magic logic built in to sort by date.

I hope that makes sense.

Brian.

ah ok. But if that is the case, and this is what the OP wants, why not leave it on Album, why change and add a custom field?

[blgentry]

ah ok. But if that is the case, and this is what the OP wants, why not leave it on Album, why change and add a custom field?

Read the very first post.

On Group by > Album it displays multiple artist albums as "by Various Artists".  Again, more magic of that particular setting that does it's own formatting and sorting.  He wants to show "[Album] by [Album Artist]" instead.  Thus the need for a custom Group By field.

Brian.

[connersw]

Yep.  I use custom Group By fields for all my views.  If anyone is interested, here they are:

Group By Album

Code: [Select]

[Album] [[Year]]Delimit([Description,0],/],/ /[) - [Album Artist (Auto)]
Group By Artist

Code: [Select]

[Album Artist (Auto)] - [Album] [[Year]]Delimit([Description,0],/],/ /[)
Group By Date

Code: [Select]

[[Year]] [Album]Delimit([Description,0],/],/ /[) - [Album Artist (Auto)]
Note: I use the Description field to distinguish between different versions of the same Album (ie SACD, Vinyl rip, etc).  If the field is populated, it shows up, otherwise nothing is displayed.

Group By DateImported

Code: [Select]

<font color="000000" size="3" alpha="100">RemoveRight(FormatDate([Date Imported,0],  filename), 2)<//font> [Album] [[Year]]Delimit([Description,0],/],/ /[) - [Album Artist (Auto)]
This one has a little of MrC's old trickery.  Since I use a black background skin, the imported date is tiny and disappears into the background.  If you use a white background, you can change the font color to FFFFFF. 
Edit: Just read through the whole thread and realized blgentry already linked one of the threads that uses this trick.  That thread is a good one to learn about the intricacies of sort by vs group by etc.  It is one of the things that makes MC very customizable and powerful, but it is also very unintuitive.  If you are not careful, you can easily make a mess of your views.