[X] Mapping failure on ALBUMARTIST

Bug Reports No Bugs
1

To solve the long-standing issue of the existing UI property BAND not showing FLAC ALBUMARTIST. http://img46.imageshack.us/img46/7374/picf.png ...

... I added a mapping rule "VorbisComment ALBUMARTIST BAND"), and it works as far as BAND display is concerned, but silently breaks the display of %albumartist%, causing it to falsely show null. http://img9.imageshack.us/img9/1950/picvh.png

This seems like a bug.

Attempting to workaround this by adding a mapping "VorbisComment ALBUMARTIST ALBUMARTIST" fails - regardless of the order of the two mapping rules. http://img641.imageshack.us/img641/5581/picj.png

In fact even having the workaround rule without the problem rule (BAND) blanks the display of %albumartist%. http://img246.imageshack.us/img246/5721/piciq.png. This too seems like a bug.

Request: remedy new mapping's breakage of scripts etc.
2

The content of albumartist is now grabbed by BAND so no display in albumartist. Otherwise you'd think you had two tag fields.

3

If I would think that, I'd still think that currently - just one shows blank.

But two columns does not mean two tag fields. I already have multiple columns for a single tag field e.g. Album and EAN (taken by regexp from album).

And actually in this case I do have two tag fields - BAND (TPE2) and ALBUMARTIST - and the current mapping behaviour prevents me from showing which is active.

4

dano is right, marked as "No Bug"

5

Even the failure of "VorbisComment ALBUMARTIST ALBUMARTIST" ??

6

Yes, adding multiple mappings for one field simply makes no sense.

7

It makes sense to me because it is the only way for me to see which file field a UI field value came from.

Not even Advanced Tags shows the file field.

Unless you know another way?

8

Yes, the format-specific field name is then not visible anymore (which is by intention, since you want to have one field name for a specific field regardless of the format-specific field names).

9

Actually I don't. I want to have one field name for all formats where required and still have format-specific names where required.

Florian, I have to ay I think this mapping implementation is misconceived. It would be better to map in the reverse direction - EDIT: each UI field name from a single file field name (for each format). Just like the current column label maps onto a single editable UI field. This would allow what is currently needlessly disallowed, and correctly disallow what is currently accepted but non-operative - multiple file field names (for the same format) onto the same UI field name. And thereby not break existing functionailty of the previous version. I hope you'll consider this change.

10

Yes, on this way I understand intelligent functional field mapping.
One UI field for all different tag formats, simple 1:n mapping.
All power emanates from the user, not from the tag format. :wink:

DD.20100304.0629.CET

11

Yes, on this way I understand intelligent functional field mapping.
One UI field for all different tag formats, simple 1:n mapping.

Sorry Detlev, I was unclear. I have edited my post to clarify.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.