Print

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

[chrisjj]

Anyone else finding the Artist tree node and pane fail to show more than the first of multiple artist fields in FLAC? E.g.

[JimH]

Did you customize the view?

Right click on the view and set it up again.

[chrisjj]

Did you customize the view?

Thanks, but No. And a new view "Artists (small with files)" shows the same tree node fail.

Right click on the view and set it up again.

I don't know what's meant by "set it up again". I never set it up initially. The program did that AFAICT.

[MrC]

You're probably using [Album Artist (auto)] which for backwards compatibility reasons evaluates to only the first entry of the [Artist] list type.  Use an expression field instead:

   [Artist]&datatype=[list]

The view you show is not a stock view, so you've customized it.  The stock Artist view is a Categories view.

[chrisjj]

You're probably using [Album Artist (auto)]

Certainly MC is doing so in that uncustomised view I just added.

which for backwards compatibility reasons evaluates to only the first entry of the [Artist] list type.

Interesting. What's the advantage of the output not handling multiple fields, may I ask? Esp. since the input does - and makes the user suffer the effect on literal ";".

Use an expression field instead:

   [Artist]&datatype=[list]

Thanks for that workaround. I'll keep fingers crossed for a fix.

[MrC]

The compatibility issue cropped up when Artist became a list type.  Certain program behaviors are required to operate under the original semantics.

Tools like Rename, Move & Copy use it, and expanding to a list could result in split albums across various directories.  Consider an album with some tracks with artist X and others with artist X; Y.  When you rename today, when Album Artist (auto) is used, only X is returned.  This is what users want.  If Album Artist (auto) expanded to all items, the change in behavior would cause either the album artist to be set to "(Multiple Artists)", or two folders would be created: one "X" and one "X; Y".

[chrisjj]

Consider an album with some tracks with artist X and others with artist X; Y.  When you rename today, when Album Artist (auto) is used, only X is returned.  This is what users want.

I don't pretend [Album Artist (auto)] makes any sense to me, but I find that effect occurs also on [Artist] ... where I'm baffled at the suggestion this is what users want. It is not what this user would want or expect.

  If Album Artist (auto) expanded to all items, the change in behavior would cause either the album artist to be set to "(Multiple Artists)", or two folders would be created: one "X" and one "X; Y".

For [Artist] that's what I would want and expect. I.e. if I moved tracks to destinations based on different artist lists, I'd expect one different directory per artist list. And if I wanted one directory for all, I'd expect to make the choice myself - rather than the program arbitrarily pick the first. Especially given the program omits to normalise the order of multiple artists AFAICT, leaving X; Y distinct from Y; X.

However since MC seems to have a workaround for just about every issue I will ask: how would I get [Artist] to deliver its full list value to Rename?

[MrC]

This was a debated topic when Artist went from single-value to a list type.  No matter how it was implemented, there were consequences one way or the other.  The discussions were all in the Beta forum if I recall correctly, so aren't available to everyone to learn about the history and reasons why decisions were made.  I'm pretty confident this won't change.

Just use [Artist,0] if you want the full artist value.  You can review the Fields section of the expression page - that might help give better insight as to how Raw vs. Display mode works for fields.

[chrisjj]

This was a debated topic when Artist went from single-value to a list type.  No matter how it was implemented, there were consequences one way or the other.  The discussions were all in the Beta forum if I recall correctly, so aren't available to everyone to learn about the history and reasons why decisions were made.  I'm pretty confident this won't change.

OK, thanks.

Just use [Artist,0] if you want the full artist value.

Thanks. I'm glad you said that...

You can review the Fields section of the expression page - that might help give better insight as to how Raw vs. Display mode works for fields.

... because reading all the 28 references there to ,0], nowhere do I see any mention of its application to override the truncation to first value. I hope this is something JR will officially document, one day.

[Hendrik]

... because reading all the 28 references there to ,0], nowhere do I see any mention of its application to override the truncation to first value. I hope this is something JR will officially document, one day.

It kinda says here:
http://wiki.jriver.com/index.php/Expression_Language#Field

Its not explicit, but it says the 0 will give you raw data, which has different meaning for various field types.
One could interpret into this, that no truncation is performed, and all untouched data is provided.

[MrC]

... because reading all the 28 references there to ,0], nowhere do I see any mention of its application to override the truncation to first value. I hope this is something JR will officially document, one day.

The Display value may be presented differently depending on context.  I thought about documenting it, but that's a lot of fields, under many circumstances, that I didn't think was worth my time to comprehensively cover.  The Raw value is the data as it is stored (at least, the best you're able to get).

It would probably be worth a mention in the Artist section of the Fields wiki page.  I'll add it to my list.

[chrisjj]

Hendrik, one can interpret such stuff many ways. The more ways on offer, the less likely it is that one picked correct.

The Display value may be presented differently depending on context.  I thought about documenting it, but that's a lot of fields, under many circumstances, that I didn't think was worth my time to comprehensively cover.

It would be great to find a way to make this kind of work worth time time to experts such as yourself MrC. I'd gladly pay the purchase price again to get MC to deliver the power which lead me to buy it and which I still firmly believe can be prized out of it with the appropriate config skills.

It would probably be worth a mention in the Artist section of the Fields wiki page.  I'll add it to my list.

Great. Thanks. I hope the same formula will handle other multiples, e.g. Genre.

[MrC]

If you've ever "shipped" computer products, hardware or software, you will know the axiom that nothing is ever perfect, or even close to it, and the best you can do is approximate meeting your prioritized goals.  In the end, you must ship with flaws... or the product will die the death of perfection.

It is a fool's errand to seek absolute perfection or clarity in any such endeavor, unless the end product is mission critical or risks loss of life.

Likewise, the same holds true with documentation, especially with a quickly moving target.

I've read pretty much every one of your posts over the years (at least since I've been part of Interact).  You are very detail oriented, and that's great.  Yet it feels like you are missing the bigger picture - the sheer quantity of all these minute details is fantastically enormous, and seeking to address all of them is not possible and reaches the point of diminishing returns very quickly.

[chrisjj]

It is a fool's errand to seek absolute perfection ...

Glad I'm not doing that here, then

I've read pretty much every one of your posts over the years (at least since I've been part of Interact).

For which I am grateful!

You are very detail oriented, and that's great.  Yet it feels like you are missing the bigger picture - the sheer quantity of all these minute details is fantastically enormous, and seeking to address all of them is not possible and reaches the point of diminishing returns very quickly.

Glad I'm not expecting anyone to address them all, then

Seriously, when I first considered MC, I did have deep misgivings about that big picture, that massive quantity of details. MC does try to be so many things to so many men, when all I want is an audio librarian. That's why I started with MJ instead, but that's now impractical. It is because I can't even strip away the MC details that get in the way of my work, that I'm still using the far less powerful but actually more productive [name of competing product deleted by author] in preference. But still I have a feeling that the designers of MC would not have put so much effort into its flexibility had they not intended it meet the requirement of folk such as I. So I persevere!

Thanks for your sympathy. And especially for your support so far!

[JimH]

... I did have deep misgivings about that big picture, that massive quantity of details. MC does try to be so many things to so many men, when all I want is an audio librarian.

Have you been here?
http://wiki.jriver.com/index.php/Simplified_Interface

[MrC]

So I persevere!

Yes, exactly.  We all just keep plugin' away, learning a little bit each day, and sharing the knowledge base.  That's the value proposition.

[chrisjj]

Have you been here?
http://wiki.jriver.com/index.php/Simplified_Interface

Thanks Jim. I have, and I have used "Tools/Options/General/Features" to turn off everything but audio.