Print

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

[Matt]

We're thinking of switching Artist and Genre to be list fields.

I'm looking for wisdom from the community about pitfalls or things we should consider.

Here's a few things from my list:

• I think they should be a new type of list field that uses a simple edit control instead of a list editor (like Keywords uses, etc.).
• Tagging should be updated when possible to store values as a list.
• Users that happened to use semi-colons in these fields for something other than a list will have to change.
• I think it's fine to just use the full list when doing something like building a cover art filename.  For example, 'Robert Plant; Tori Amos - Tribute To Led Zeppelin.jpg'.
• The first item in the list should be considered the primary item in cases where a list isn't supported.

.

Thanks.

[Alex B]

I too am afraid of the pitfalls. Here's my reply from another thread:

"Soloists" works correctly for me. I just tested it by pasting the Soloist One; Soloist Two; Soloist Three; Soloist Four string into the Soloists field. In a list view column and Action Window > Tag > Soloists the string was correctly interpreted as four list items.

"Artist" as a list field could cause problems with the internal automatic Album Artist logic, online databases and many other programs & player devices. In my opinion it is better to not change the behavior of the most common, traditional "CD database", fields. I have used a custom "Contibuting Artists" list field for this purpose.

• I think it's fine to just use the full list when doing something like building a cover art filename.  For example, 'Robert Plant; Tori Amos - Tribute To Led Zeppelin.jpg'.
• The first item in the list should be considered the primary item in cases where a list isn't supported.

How would "Album Artist (auto)" and the cover art database work?

For example:
David Byrne & Brian Eno – Everything That Happens Will Happen Today
http://www.discogs.com/David-Byrne-Brian-Eno-Everything-That-Happens-Will-Happen-Today/release/1549146

The users would tag it:
David Byrne; Brian Eno   or   Brian Eno; David Byrne

in addition to the existing variants: David Byrne & Brian Eno, David Byrne and Brian Eno, etc  (BTW, is the cover art database clever enough to see "&", "and", "+" "with", etc as synonyms?)


I wonder if you could simply allow the user to change the fields' data type, but have the default as it is now.

[Magic_Randy]

I can adapt to any new conventions, but I have one concern regarding: "Tagging should be updated when possible to store values as a list"

All of my music is mp3 320kbs. I do this for compatibility with other software and devices. Would this change have any impact on how the tags are treated by these other applications and devices (e.g. is this a transparent change)?

[Matt]

How would "Album Artist (auto)" and the cover art database work?

For example:
David Byrne & Brian Eno – Everything That Happens Will Happen Today
http://www.discogs.com/David-Byrne-Brian-Eno-Everything-That-Happens-Will-Happen-Today/release/1549146

The users would tag it:
David Byrne; Brian Eno   or   Brian Eno; David Byrne

in addition to the existing variants: David Byrne & Brian Eno, David Byrne and Brian Eno, etc  (BTW, is the cover art database clever enough to see "&", "and", "+" "with", etc as synonyms?

It seems like if all the tracks were 'David Byrne; Brian Eno', then that'd also be the Album Artist (auto).

If some were 'David Byrne & Brian Eno' and some were just 'David Byrne', then Album Artist (auto) would be (Multiple Artists).

I wonder if you could simply allow the user to change the fields' data type, but have the default as it is now.

The problem is that WMP (and maybe others) support artist lists.

And now people want genre lists for videos.

It would be opt-in from the point of view that if you didn't use semi-colons, you would only ever have one thing in the list and it would work like it has always worked.

[Alex B]

If this will be implemented then you will have no excuse to not implemented also the correct way to tag FLAC and OGG files:

From: http://www.xiph.org/vorbis/doc/v-comment.html

Field names are not required to be unique (occur once) within a comment header. As an example, assume a track was recorded by three well know artists; the following is permissible, and encouraged:
              ARTIST=Dizzy Gillespie
              ARTIST=Sonny Rollins
              ARTIST=Sonny Stitt

In ID3v2.3 tags the separator should be / . ID3v2.4 is different.

From http://en.wikipedia.org/wiki/ID3

ID3v2.3 expanded the frame identifier to four characters, and added a number of frames. A frame could contain multiple values, separated with a / character. This is the most widely used version of ID3v2 tags.

ID3v2.4 is the latest version published, dated November 1, 2000. Notably, it allows textual data to be encoded in UTF-8, which was a common practice in earlier tags (despite the standard, since it was not supported yet) because it has several noticeable advantages over UTF-16. It uses a null byte to separate multiple values, so the character "/" can appear in text data again. Another new feature allows the addition of a tag to the end of the file before other tags (like ID3v1).

This will of course expose the well-known AC/DC artist tag problem with ID3v2.3. So far it has not been a problem in MC.

I can check what the other formats should use (m4a, wma, wv, mpc, aiff & wav, ape), but be prepared that you will need to change each and every format.

In the meanwhile, you could start by removing the Media Jukebox strings from the APE tags. Currently if e.g. "Soloists" is tagged outside MC there is no way to make MC use the field. The same is true for WMA (expect for those original WMP tags that are already supported in MC).

[MrC]

I wonder if you could simply allow the user to change the fields' data type, but have the default as it is now.

I agree with this.  It should be off by default, at least for now, but fully supported to work when enabled.

1) multiple occurrences of the same tag is really important (as per Alex B's comments).  MC gets mocked for not supported this.
2) the current truncation of 60 chars per-field has to be ditched (for this, and other reasons).
3) the Artist "David Byrne; Brian Eno" and "Brian Eno; David Byrne" should be considered equivalent for Album Artist (auto) purposes.
4) perhaps there should be an auto-field, something like Artist (primary) that is calculated to be the first value of Artist.  Likewise Genre?

[glynor]

My only concern really, since you addressed this:

I think they should be a new type of list field that uses a simple edit control instead of a list editor (like Keywords uses, etc.)

Is ease-of-use when tagging in the Panes.

I use the Panes to tag my files heavily.  One thing I do a lot, is "fix" the [Artist] tag using the Panes.  Tori Amos is actually a perfect example.  All of my single-person Artists are in my database in the format Last Name, First Name.  When I import a new Tori track from Amazon or whatever, it is inevitably tagged "Tori Amos" and not the "reversed" way I prefer.

Having to (remember to) uncheck the previous tag could be troublesome, and would make any such operation twice as long.  Mostly, it wouldn't be a big deal if you can see both checkboxes in the Panes at the same time (changing "The Arcade Fire" to "Arcade Fire"), but often that isn't the case for me unless the person's names both start with the same letter.

I'll constantly forget to do it, and then Tori tracks will end up in there both ways.  Maybe that isn't bad, but then I don't want the Rename, Move, and Copy operation to name a folder "Tori Amos; Amos, Tori", and maybe a different one "Amos, Tori; Tori Amos" and so on and so forth.

So, I'm worried about the workflow of tagging.  The VAST MAJORITY of my tracks only have one artist, and I only want Movies (not Music, not TV Shows, not Photos... Only Movies) to be allowed to have more than one [Genre].  I worry about adding workflow complexity 100% of the time to solve something that only affects my library 5% of the time.

[JustinChase]

IFor example:
David Byrne & Brian Eno – Everything That Happens Will Happen Today
http://www.discogs.com/David-Byrne-Brian-Eno-Everything-That-Happens-Will-Happen-Today/release/1549146

The users would tag it:
David Byrne; Brian Eno   or   Brian Eno; David Byrne

in addition to the existing variants: David Byrne & Brian Eno, David Byrne and Brian Eno, etc  (BTW, is the cover art database clever enough to see "&", "and", "+" "with", etc as synonyms?)

3) the Artist "David Byrne; Brian Eno" and "Brian Eno; David Byrne" should be considered equivalent for Album Artist (auto) purposes.

Maybe the list should be alphebetized, so either way gets changed to the same result?  i.e. both end up as Brian Eno; David Byrne

Maybe also any "and", "&", "+" ect should all be removed/replaced with ";" for consistency sake?

[MrC]

Maybe the list should be alphebetized, so either way gets changed to the same result?  i.e. both end up as Brian Eno; David Byrne

Maybe also any "and", "&", "+" ect should all be removed/replaced with ";" for consistency sake?

They can be internally sorted for comparison; I don't think they should be re-ordered.

Re: replacement, Florence would not like this: http://allmusic.com/artist/florence--the-machine-p1062562

[glynor]

Maybe also any "and", "&", "+" ect should all be removed/replaced with ";" for consistency sake?

Yeah, definitely not this.

Florance + the Machine
Hall & Oates
Simon and Garfunkel
etc...

[Matt]

Is ease-of-use when tagging in the Panes.

I think for editing (in-place or panes), artist and genre should work like they've always worked.  The pane will be single-select, and you would use 'New value' and type with semicolons to enter a list.

[Alex B]

IMO, "David Byrne & Brian Eno" is a more like the name of the band (and artist in this case).

This is not going to be easy.

Another example:

http://en.wikipedia.org/wiki/Crosby,_Stills,_Nash_%26_Young_discography

Crosby, Stills & Nash   is a band

Crosby, Stills, Nash & Young   is not quite the same band (the name in the liner notes is different when Neil Young is present)

- Crosby; Stills; Nash; Young
- David Crosby; Stephen Stills; Graham Nash; Neil Young
- Crosby, David; Stills, Stephen; Nash, Graham; Young, Neil

 

[JimH]

Maybe parsing could ignore anything within quotes.  For example

"Crosby, Stills & Nash";"Crosby, Stills, Nash & Young";Crosby;Stills;Nash;Young  (6 artists)

or

"Semi;Colon";Semi;Colon  (3 artists)

[Matt]

I don't see any reason to switch all your artist names with '&' or 'and' in them to a list.  "Simon & Garfunkel" is fine as-is.

I would only expect users to use or need the artist list feature for a small percentage of their tracks.

[Matt]

In ID3v2.3 tags the separator should be / . ID3v2.4 is different.

From http://en.wikipedia.org/wiki/ID3
This will of course expose the well-known AC/DC artist tag problem with ID3v2.3. So far it has not been a problem in MC.

I think it might be better to only read or write NULL as the delimiter, regardless of the ID3 version.

It seems like that's what Mp3tag is doing, for example.

[vagskal]

I think it's fine to just use the full list when doing something like building a cover art filename.  For example, 'Robert Plant; Tori Amos - Tribute To Led Zeppelin.jpg'. The first item in the list should be considered the primary item in cases where a list isn't supported.

I hope an artist image view is supposed to be based on each individual artist in a list.

[Alex B]

Good point. I had not even thought about the artist images yet.

[vagskal]

I think it might be better to only read or write NULL as the delimiter, regardless of the ID3 version.

It seems like that's what Mp3tag is doing, for example.

Please keep ; as the delimiter. Logitech Media Server also uses a delimiter and ; is the default, but it is configurable although I do not know how to enter a NULL value in the options. ; seems pretty standard and is not so often used in tags for other purposes than as a delimiter.

[Matt]

@Artist images
Good point.  I think I've got that sorted.

@Delimiter
Inside Media Center the delimiter will be semi-colon.  The delimiter I'm describing above is specific to tagging ID3v2.  It's a detail hidden from users.

[glynor]

I think for editing (in-place or panes), artist and genre should work like they've always worked.  The pane will be single-select, and you would use 'New value' and type with semicolons to enter a list.

Perfect.

[vagskal]

@Delimiter
Inside Media Center the delimiter will be semi-colon.  The delimiter I'm describing above is specific to tagging ID3v2.  It's a detail hidden from users.

I may have misunderstood, but I need/prefer that MC reads from and writes to the mp3 file tags ; as delimiter for use with Logitech Media Server. If ; or something else is used for display purposes within MC is not of particular importance to me (as long as I can change the display by using replace()). Multiple Vorbis comments tags in flac files are OK, according to specs and read by Logitech Media Server.

Another thing: I think the tag action window always should display value1; value2 in one single row and not
value1
value2
in order to be able to show as many different tags in that window as possible.

[glynor]

I don't see any reason to switch all your artist names with '&' or 'and' in them to a list.  "Simon & Garfunkel" is fine as-is.

Completely agreed.

Where I see this being most useful is for tracks "featuring" someone else (every hip hop and R&B track seemingly), remixes (Aphex Twin remixes Phillip Glass), and cover songs (Pickin' on Pink Floyd type stuff, where you probably don't know the "real artist's" name, but you know whom they're covering).

I'm sure there are other examples, but I don't think most people would bother to do things like: Simon & Garfunkel; Paul Simon; Art Garfunkel

Some crazy people will, but it shouldn't be optimized for that.  Your suggestions here seem completely right-on to me, Matt.

[glynor]

Some crazy people will, but it shouldn't be optimized for that.  Your suggestions here seem completely right-on to me, Matt.

That said...

It might be nice to have access to the List Style tagging thingamajig somehow.  Perhaps via a (...) button that "overlays" inside the tag's field in the Action Window (with a keyboard shortcut too, of course)?

If that's too much of a nightmare, I think we can live without it, but... That could be handy to have there for those crazy people (and for us less crazy folks who still want to just check boxes and not type here and there).

[Matt]

Relational fields keyed on artist were a little tricky.

The relationship will be relative to the primary / first artist.

There will not be a way to store relational data for non-primary artists.

[glynor]

Too bad, but... It doesn't bother me.

Besides, despite much evidence to the contrary, beggars can't be choosers. 

[vagskal]

bother to do things like: Simon & Garfunkel; Paul Simon; Art Garfunkel

Some crazy people will

You can call me crazy, if you like. But now I am not going to tell you how I have tagged my various John Mellencamp albums.

I would prefer to have the quick search arrow work on the entire artist list, if it is not possible to quick search for either the entire list or any individual artist. If at all possible a quick search for an entire list should ignore the order of items, I.e. finding artist A; artist B as well as artist B; artist A. Having the quick search arrow searching for only the primary artist would be confusing.

A minor thing: Please clean up the field contents when making them list style or reading from file tags, I.e. remove leading and trailing ; and surrounding white space as well as empty items within a list.

Why not go all the way and make also the Composer field list style once you are at it.

[JustinChase]

Why not go all the way and make also the Composer field list style once you are at it.

Indeed 

17.0.76 (1/25/2012)

1. NEW: Artist, Genre, Composer, and Conductor are list-type fields.

[vagskal]

Relational fields keyed on artist were a little tricky.

The relationship will be relative to the primary / first artist.

There will not be a way to store relational data for non-primary artists.

Could you please elaborate a bit how this will work when converting the artist field to list style for the first time. I am afraid to let the new version loose on my library.

At least consider an option No relation if Artist (target) field contains a list. Otherwise rearranging the items can lead to unwanted and destructive behaviour. like deleting the birth date for all Alson Krauss tracks and substituting it with the birth date of Robert Plant. With the option, a value could be deleted if a single artist made a duet, but only for that duet track and not for all entries by that artist.

[vagskal]

Indeed 
17.0.76 (1/25/2012)

1. NEW: Artist, Genre, Composer, and Conductor are list-type fields.

Wow, that was fast. Now I guess going all the way would mean supporting the IPLS tag which would require two or three delimiters...

[MrHaugen]

I don't see any reason to switch all your artist names with '&' or 'and' in them to a list.  "Simon & Garfunkel" is fine as-is.

I would only expect users to use or need the artist list feature for a small percentage of their tracks.

Yes! Changing all current artists with "&", "and" and "+" to several artists would screw up my collection VERY much! Please do not do this. If you change Artist and Genre to list types, you'll have to leave the tags as they are today. One line. One entry. And users have to change them self later on if need be. So, a huge NO to automatic parsing and splitting of current names!


Only thing I'm concerned about is filtering based on this fields. We would be able to use this fields to filter based on one and one of this values in Theater view or standard view right? Like Genre. I want a view with all genres, and when I select one genre I want to see all movies with this genre tagged.

*EDIT*
Oh. It's already been done. I hope nothing will be done with existing Artists. The change log does not mention it, so let's hope not

[Alex B]

Matt,

I created a bunch of small test files in about all possible audio formats and tagged the files with Mp3tag (some are tagged also with foobar2000, dbpoweramp and WMP).

The intended multi-value fields are Artist, Genre and Soloists. The intended values for all fields are: Value 1, Value 2 and AC/DC (for testing the slash behavior)

Here is a package that contains the sample files, 3 artist images with matching names, and a library backup file (it is a v.17.0.76 test library that contains only these multi-value samples): https://skydrive.live.com/?cid=138CA589C542AEEE&id=138CA589C542AEEE%21219#

It would be easier to discuss about the possible issues if you have the same files and library available.

(Of course everyone from the beta team is welcome to try the test files.)

[Matt]

Are vorbis comments (FLAC or OGG) supposed to be in any particular order?

[Alex B]

I don't know. Probably they can be in any order.

Mp3tag and foobar2000 seem to always keep the multi-value tags together (and of course in the correct order) and place cover art last.

Since MC doesn't automatically import all possible tags to the database you must also put the foreign tag fields somewhere when the tags are reordered.

[Matt]

Thanks for the test files Alex.

Tonight's build should make quite a bit of progress for OGG, FLAC, APE, and MPC.

The WMP12 tagged MP3 files seem like they have corrupt tags.  For example, 'OLOISTS' is in the soloists field and 'eplaygai' is the replay gain.

[Alex B]

What do you think about the attached screenshots?

My first thought was that "Artists" should behave like "Genres", but then I noticed that "Artists" uses [Album Artist (auto)] internally. When I changed it to use [Artist] it started to behave like "Genres" and displayed the three correct artist images.

I wonder if you should now label the current "Artists" view as "Album Artists" and add a new "Artists" default view that would show all individual track artists and make the multi-value tags useful in this view.

[glynor]

The WMP12 tagged MP3 files seem like they have corrupt tags.  For example, 'OLOISTS' is in the soloists field and 'eplaygai' is the replay gain.

They're just bad at pig latin.  They forgot the -ay.

[Matt]

What do you think about the attached screenshots?

My first thought was that "Artists" should behave like "Genres", but then I noticed that "Artists" uses [Album Artist (auto)] internally. When I changed it to use [Artist] it started to behave like "Genres" and displayed the three correct artist images.

I see two ways to handle this:

1) Make [Album Artist (auto)] handle list data since [Artist] can be a list
or
2) Make [Album Artist (auto)] use the primary artist only, so it works more like [Album Artist] which is not a list.

I'm leaning towards #2.

[Alex B]

The WMP12 tagged MP3 files seem like they have corrupt tags.  For example, 'OLOISTS' is in the soloists field and 'eplaygai' is the replay gain.

WMP12 and Windows 7 Explorer ruin all TXXX tags:

http://www.hydrogenaudio.org/forums/index.php?showtopic=76998
http://www.hydrogenaudio.org/forums/index.php?showtopic=92813

I also read some reports that the multi-value artist tags (= contributing artists in WMP) do not work correctly in WMP12 or at least not in the same way as in WMP11.

In general WMP12 is like a bad joke. It is even worse than WMP11.

[Matt]

WMP12 and Windows 7 Explorer ruin all TXXX tags:

http://www.hydrogenaudio.org/forums/index.php?showtopic=76998
http://www.hydrogenaudio.org/forums/index.php?showtopic=92813

I also read some reports that the multi-value artist tags (= contributing artists in WMP) do not work correctly in WMP12 or at least not in the same way as in WMP11.

In general WMP12 is like a bad joke. It is even worse than WMP11.

Wow.  That is really sad.

I guess with WMA taking off like it has, who really cares about MP3?

[vagskal]

I took the plunge and installed the .77 build. I noticed several issues.

1. My genre "Pop/Rock" got imported as "Pop; Rock" for ID3v2.3 mp3 files (but flac files are OK).
2. A list field is written to ID3v2.3 mp3 files as multiple tags (which is not according to specs).
3. Writing to a flac file (Vorbis comments) writes a YEAR tag with the (year) content of the date field. Previously only a DATE tag was written which is according to specs.
4. Now MC writes the Country field as multiple tags. Previously a ; delimited list was written.
5. A custom field set to list type and edit type list was still writing a ; delimited list to flac files instead of multiple tags.
6. Tagging needs work. Previously I could have a [Artists] field - [artist]&datatype=[list] - and show that field in the grid and have a list with check boxes for each artist and I could reorder the items. That seems no longer possible, or is a &edittype=[list] switch planned? For me the stock fields of list type had the standard edit type chosen and I saw no way of changing that to list edit type.
7. The artist images seems to be working. If I did Get artist images on an artist (in a categories view) images for all artists that had collaborated with him were also fetched. I would have expected that only the artist in question would get updated (and the custom images for the other artists to be left untouched).

Multiple tags should never be written to mp3 files; write a ; delimited list instead.

Make it an option to write multiple tags for flac files. When switching to MC I had to convert my flac multiple tags to ; delimited lists and now I just want to keep things consistent, i.e. either delimited lists or multiple tags but not both in the same library.

I will revert to .75. This is yet too shaky for me.

[Matt]

2. A list field is written to ID3v2.3 mp3 files as multiple tags (which is not according to specs).

We use NULL delimiting in a single tag for ID3v2.3 and ID3v2.4.

It's a gray area whether NULL or / should be used as a delimiter for ID3v2.3, but I think NULL is safer.

4. Now MC writes the Country field as multiple tags. Previously a ; delimited list was written.

Country is a list field, and lists should be stored as multiple tags.

5. A custom field set to list type and edit type list was still writing a ; delimited list to flac files instead of multiple tags.

Only the stock list fields will be saved using the new list tagging methods.  This is because the tagging plugins only know that the stock fields are a list.  This might change someday, but not until other tagging changes are finished.

6. Tagging needs work. Previously I could have a [Artists] field - [artist]&datatype=

- and show that filed in the grid and have a list with check boxes for each artist and I could reorder the items. That seems no longer possible, or is a &edittype=
switch planned? For me the stock fields of list type had the standard edit type chosen and I saw no way of changing that to list edit type.

This is discussed above.  While the fields are lists, they will use the standard edit style for simplicity.[/list][/list]

[Matt]

3. Writing to a flac file (Vorbis comments) writes a YEAR tag with the (year) content of the date field. Previously only a DATE tag was written which is according to specs.

To make sure I understand, when setting the date is this correct:

YEAR > remove
DATE > four digit year
JR_DATE > if more than year (so day / time), store, otherwise remove

[vagskal]

We use NULL delimiting in a single tag for ID3v2.3 and ID3v2.4.

It's a gray area whether NULL or / should be used as a delimiter for ID3v2.3, but I think NULL is safer.

Please reconsider. I am pretty sure Logitech Media Server does not automatically recognize NULL as a delimiter, and I do not think I can enter NULL in the delimiter option in Logitech Media Server (how would I write NULL?). Please continue with ; as delimiter, something I have seen no complaints about. If Logitech Media Server cannot read the tags MC writes, I can no longer use MC for tagging.

In the file tag inspection action window (in build .75) only the first item is shown. With dBpoweramp Windows explorer inspector only the first item is shown. In the grid in MP3Tag only the first item is shown and in other places the list content shows up just like multiple Vorbis comments.

Only the stock list fields will be saved using the new list tagging methods.  This is because the tagging plugins only know that the stock fields are a list.  This might change someday, but not until other tagging changes are finished.

This will mean that my file tags will contain lists using different delimiters, which is inconsistent. In Logitech Media Server options it is possible to set more than one delimiter (but not NULL as far as I know).

[vagskal]

To make sure I understand, when setting the date is this correct:

YEAR > remove
DATE > four digit year
JR_DATE > if more than year (so day / time), store, otherwise remove

That is correct and like it is in builds prior to .76. YEAR is not a "standard" Vorbis comment, but DATE is. I think you had a discussion with Alex B about whether the full date should be written to DATE (which I think is also possible according to specs) and settled on the solution you propose (which I like).

EDIT: I am not so sure about the YEAR > remove bit. If the file already has a YEAR tag that MC has read, perhaps both a YEAR and DATE tag should be written (since other software not adhering to specs might need the YEAR tag). Perhaps this was the behaviour prior to the change.

[vagskal]

While the fields are lists, they will use the standard edit style for simplicity.

This is a step back. Previously I could have a custom list type field =[Artist] and get the list edit style and have the changes written to the [Artist] field and the corresponding file tag.

[glynor]

This is a step back. Previously I could have a custom list type field =[Artist] and get the list edit style and have the changes written to the [Artist] field and the corresponding file tag.

But making [Artist] and [Genre] a standard List-type field would annoy everyone else for the 95% of their files that DON'T need multiple values in those fields (see above discussion).  I think it is a pretty good compromise.  I absolutely would not want the normal list-style tagging mechanism to be the default for these fields (and I think most users would agree).  However...

That said...

It might be nice to have access to the List Style tagging thingamajig somehow.  Perhaps via a (...) button that "overlays" inside the tag's field in the Action Window (with a keyboard shortcut too, of course)?

If that's too much of a nightmare, I think we can live without it, but... That could be handy to have there for those crazy people (and for us less crazy folks who still want to just check boxes and not type here and there).

For now, you can tag these files by typing the list into the [Artist] or [Genre] fields as a semicolon delimited string.  Why can't you still use your custom field if you don't like that?

[vagskal]

But making [Artist] and [Genre] a standard List-type field would annoy everyone else for the 95% of their files that DON'T need multiple values in those fields (see above discussion).  I think it is a pretty good compromise.  I absolutely would not want the normal list-style tagging mechanism to be the default for these fields (and I think most users would agree).

I understand this. But previously I could have a custom [Artists] calculated data field with [Artist]&datatype=[list], that wrote data to the [Artist] field and its corresponding file tag. The [Artists] field showed in the grid a list with a check box for each artist and gave me the opportunity to reorder the items. In the tag action window the [Artists] field was shown as a standard field (artist1; artist2). That seemed no longer possible with build .77, and that is a step back in my opinion (removed functionality, i.e. no longer possible to have list type editing in a custom calculated data field of list type). Another switch &edittype=[list] would let me choose.

[Alex B]

To make sure I understand, when setting the date is this correct:

YEAR > remove
DATE > four digit year
JR_DATE > if more than year (so day / time), store, otherwise remove

That is correct and like it is in builds prior to .76. YEAR is not a "standard" Vorbis comment, but DATE is. I think you had a discussion with Alex B about whether the full date should be written to DATE (which I think is also possible according to specs) and settled on the solution you propose (which I like).

From Xiph's "Proposed field names" document ( http://wiki.xiph.org/VorbisComment#Date_and_time )

Date and time

The goal is to specify one standard format for describing date and/or time.
 ISO proposal

The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field except track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
YYYY-MM-DDTHH:MM:SS+TS
THH:MM+TZ

For compatibility reasons it was decided to write only the four digit year number to DATE and use JR_DATE for the precise value when needed.

So the following is correct:

YEAR > remove
DATE > four digit year
JR_DATE > if more than year (so day / time), store, otherwise remove  (i.e. use the internal precise date code)

[vagskal]

I am pretty sure Logitech Media Server does not automatically recognize NULL as a delimiter [...]

In the file tag inspection action window (in build .75) only the first item is shown. With dBpoweramp Windows explorer inspector only the first item is shown. In the grid in MP3Tag only the first item is shown and in other places the list content shows up just like multiple Vorbis comments.

This will mean that my file tags will contain lists using different delimiters, which is inconsistent.

I just tested with Logitech Media Server (LMS) and it turns out that LMS actually seems to automatically recognize NULL as a delimiter in ID3v2.3 files. Puh.

The arguments concerning display and inconsistency still remain valid.

[Alex B]

EDIT: I am not so sure about the YEAR > remove bit. If the file already has a YEAR tag that MC has read, perhaps both a YEAR and DATE tag should be written (since other software not adhering to specs might need the YEAR tag). Perhaps this was the behaviour prior to the change.

I considered this, but if I recall correctly, some other programs show a double year value when both tags exist.

Perhaps MC should ignore & preserve a "YEAR" file tag by default and write it only if a user defined custom YEAR library field exists and contains a value (actually this seems to be how it has worked until now). I.e. MC should handle it like any foreign tag.

When a user YEAR field is added, it is better to change the displayed name to e.g. "Year (custom)" to avoid confusion with the "Date (Year)" field and its displayed name which is Year by default.