INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: Matt on January 25, 2012, 09:56:19 am
-
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.
-
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.
-
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)?
-
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.
-
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).
-
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?
-
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.
-
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?
-
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 (http://allmusic.com/artist/florence--the-machine-p1062562)
-
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...
-
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.
-
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
;D
-
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)
-
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.
-
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.
-
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.
-
Good point. I had not even thought about the artist images yet.
-
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.
-
@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.
-
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.
-
@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.
-
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.
-
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).
-
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.
-
Too bad, but... It doesn't bother me.
Besides, despite much evidence to the contrary, beggars can't be choosers. ;)
-
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.
-
Why not go all the way and make also the Composer field list style once you are at it.
Indeed :o
17.0.76 (1/25/2012)
1. NEW: Artist, Genre, Composer, and Conductor are list-type fields.
-
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.
-
Indeed :o
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...
-
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 :)
-
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.)
-
Are vorbis comments (FLAC or OGG) supposed to be in any particular order?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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]
-
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
-
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).
-
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.
-
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.
-
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?
-
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.
-
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)
-
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.
-
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.
-
Off topic: Is it possible to have two different builds of v. 17 installed on the same PC and how is this done? I am concerned about these changes and would like to test more (how relational fields act etc), but I have several new albums that I want to import and tag with build .75 during the weekend.
-
You could probably pull it off with 0.75 as a portable install.
-
A portable install should be fine for testing this. I don't think the few known problems or differences in the portable install can affect the tagging and view behavior.
After creating a portable install you could start by restoring my test library and importing (or relinking) the small test samples:
https://skydrive.live.com/?cid=138CA589C542AEEE&id=138CA589C542AEEE%21219#
-
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.
I was wrong. I tested the build 75. It can read a YEAR tag to a Year library field, but when it writes tags a YEAR tag is removed (at least a date change, which I tested, causes this to happen.)
So my suggestion would be:
YEAR > no special treatment - use it as any custom field if defined by the user.
DATE > four digit year
JR_DATE > if more than year (so day / time), store, otherwise remove (i.e. use the internal precise date code in this field)
-
Thanks guys!
I can see now that it seems to be the ISO-8859-1 char encoding in mp3 files that is having an issue with converting / to ; in the genre field (Pop/Rock => Pop; Rock and AC/DC => AC; DC). (Being able to see the char encoding in MC would help.)
PS. I made a .77 portable install, but I could not figure out how to restore my .75 library in the .77 portable install. When the restore in .77 was completed and MC needed to restart, the .75 build would start.
-
I made a .77 portable install, but I could not figure out how to restore my .75 library in the .77 portable install. When the restore in .77 was completed and MC needed to restart, the .75 build would start.
This is one of the (more or less) known issues with the portable install. The settings restore part does not work. The restored settings go to Windows registry and will be used by the regular install. The library is restored correctly and a restart is not needed when just the library is restored.
Currently the only way to back up and restore only the settings of a portable install is to copy the two ini files from [portable install location]\Application Data\J River\Media Center 17\Settings\. This is probably a good thing because at least various file paths in a backup file from a regular install would be incorrect for a portable install.
An easy way to back up a portable install is to simply copy the complete "portable install location" folder structure.
This would be less confusing if the "restore settings" checkbox would be unchecked and greyed out when the install is portable.
-
Thanks, Alex, for the explanation! I just noticed what a restart of the primary .75 build did to my library. I will use the portable .77 install with your test library settings and just manually copy the views, expressions, smartlists and custom fields I need for testing to the .77 portable install.
-
This change excites me greatly - thank you JRiver!!
I'm not sure I can help much with the tag side of things, as I don't use any other programs for audio and have little knowledge of the internal tag structure. I'm happy with any system which works transparently within MC and that seems to be the case at the moment.
- Artist images is working perfectly for me as far as I can tell.
- Relations are only for the first Artist listed, but I think this is probably the best way to handle it.
Again, thanks for the change. I'm now going to go ahead and delete some of my custom list fields :)
-
... I'm now going to go ahead and delete some of my custom list fields :)
You might want to wait a few builds until things settle down. The fields could turn out to be good backups of your data.
-
I'm starting to dabble here, changing artists to lists.
If I select "Brian Eno & J. Peter Schwalm" in a panes view, and then change artist to "Brian Eno; J. Peter Schwalm", the focus is lost in the pane. Would it be possible to set the focus to/select the first item from the just updated artist list (i.e. Brian Eno) whenever the previously entry (i.e. Brian Eno & J. Peter Schwalm) disappears? I can see that this might be too esoteric.
... the previous item in the pane? I can see the above won't work much of the time.
-
You might want to wait a few builds until things settle down. The fields could turn out to be good backups of your data.
True, however a lot of them are calculated fields based on the existing fields anyway.
I will hold off. But am liking how it's all working so far (and how quickly Matt seems to have pulled it off)
-
I tried the .78 build out (as a portable install). As a side note: The portable install of .77 did not find the .78 build. It reported that the .77 build was the latest. - I noticed that the thumbnail text for the stock Artists view was set to [Date (year)][New Line][Name]. The year bit did not look nice.
1. The flac YEAR issue is fixed.
2. With mp3 files with ID3v2.3 and ISO-8859-1 char encoding MC still replaces / with ;, Pop/Rock => Pop; Rock.
3. Search is not working well at the moment.
a) Clicking on the small arrow next to a list finds nothing. Ideally all files that contain all the items, irrespective of the order of items, should be found. Maybe it is just a matter of stripping the ;s from the search box.
b) It is no longer possible to search for ; in list fields ([Genre]=";"). It should be possible to search for files with more than one item in a list field.
4. I found a workaround for creating a custom calculated data list type field with list edit type. Create the custom field first as a user data field and close the Manage Library Fields window and reopen it. Then make the field a calculated data field.
5. Relational fields seems to work fine. Well done!
a) The only issue I found was this strange one: Set a relational value for a primary artist. Add another artist with / in his name, like AC/DC, that has no relational value and reorder so that artist becomes the primary artist and he inherits the relational value from the former primary artist.
b) I would prefer an option to not set a value in a relational field if the target field contains a list. The reason for this is that Logitech Media Server is not respecting the order of items in a tag, or the order of multiple tags. The relational field could then be misleading in LMS if there is more than one item.
6. With the .78 build the Country field is written to ID3v2.3 mp3 files as a ;, not NULL, delimited list.
7. The [Album Artist (auto)] logic seems to need some fine tuning.
a) Even though the primary artist is the same for all tracks in an album there are multiple [Album Artist (auto)] entries, one for each different secondary artist, i.e. they are treated as separate albums.
b) Reversing the order of artist items for just one track makes the album a multiple artists album.
Perhaps Mood and Style also should be made into list type fields, and why not support Theme as well.
-
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.
Slightly off topic - I would love to see this added in some way to all list-type fields. Before MC shipped with a 'Country' field, I made one myself. Now I have no control over what type of field it is, but I do *not* want it to be a list-type field - but only for tagging reasons. I never had to de-tag one country in order to change a photograph's country before and I don't like having to do it now.
Would it be possible to add a check-box within the field-setup dialogue box that would turn on or off this type of tagging behaviour for list-type fields?
-
These issues are still there in the .82 build.
2. With mp3 files with ID3v2.3 and ISO-8859-1 char encoding MC still replaces / with ;, Pop/Rock => Pop; Rock.
3. Search is not working well at the moment.
a) Clicking on the small arrow next to a list finds nothing. Ideally all files that contain all the items, irrespective of the order of items, should be found. Maybe it is just a matter of stripping the ;s from the search box.
b) It is no longer possible to search for ; in list fields ([Genre]=";"). It should be possible to search for files with more than one item in a list field.
6. With the .78 build the Country field is written to ID3v2.3 mp3 files as a ;, not NULL, delimited list.
Issue no. 2 for the Genre field prevents me from letting this build loose on my regular library. MC displays upon import "Pop; Rock" instead of "Pop/Rock" and if the tags are written back from MC to the file, the "/" in the file tag is replaced by NULL.
I have not re-checked the [Album Artist (auto)] logic.
-
In ID3v2.3, / is the delimiter.
So according to the spec, Pop/Rock is two genres in a list.
You could use Pop\Rock or Pop Rock instead.
-
In ID3v2.3, / is the delimiter.
So according to the spec, Pop/Rock is two genres in a list.
You could use Pop\Rock or Pop Rock instead.
Hmm. As far as I can tell "/" in the mp3 file tag is treated by MC as a delimiter only when importing into the Genre tag/field, not in the new stock list fields or in a custom list field. I am not advocating that "/" in those tags/fields should be treated as a delimiter, but rather that the Genre field should work as the other fields. Or could " / ", not "/", be used as a delimiter?
-
Hmm. As far as I can tell "/" in the mp3 file tag is treated by MC as a delimiter only when importing into the Genre tag/field, not in the new stock list fields or in a custom list field. I am not advocating that "/" in those tags/fields should be treated as a delimiter, but rather that the Genre field should work as the other fields. Or could " / ", not "/", be used as a delimiter?
Currently in ID3v2.3, we import / as a delimiter, except for artist.
I'm fine switching this so that only NULL is imported as the delimiter, for ID3v2.3 or ID3v2.4. That's how we're writing it, so I guess it makes sense.
-
I'm fine switching this so that only NULL is imported as the delimiter, for ID3v2.3 or ID3v2.4. That's how we're writing it, so I guess it makes sense.
Yes, please! Provided that ; in the file tag is also interpreted as a delimiter, just as before.
-
As perspective on this topic, I had the same need years ago in my MC music library, so I created an workaround using Keywords for multiple Genres, and using custom field Artists to list all the notable performers on a recording. Comparing this "perfect" (for me) solution to the new changes...
Allowing a list for Genre is nice, lots of music fits into multiple genres. I'll likely adopt it for the main genres, but still use Keywords for many other ways I categorize tracks.
But using a list for Artist seems like a can of worms, for several reasons, starting with the potential for semi-colons. (I'll search for semi-colons in this field, just in case...)
I don't think the use of a list of artists is as "special case" as it might seem. In my library of 80K tracks spanning every type of music, more than half are appropriately tagged with multiple artists.
My solution, devised years ago, is to use a custom Artists field to list all performers. I get the same result but with complete control and precision. And, I still have an important use for the default Artist field, which I hope the new change won't mess up.
I use Artist as the field that contains the exact artist name as stated on the original recording. This is then displayed when the track is playing. I don't use it to group, sort, select or whatever, just to show the listener the correct and complete name of the performer/group. For instance, across a few years of recording the same singer and band might be listed on record labels in multiple ways; my use of Artist lets me show the correct name for each recording. (Example: Benny Goodman & His Orchestra, Peggy Lee Vocal; Benny Goodman and Peggy Lee; Peggy Lee with Benny Goodman & His Orchestra.)
I then use custom field Artists to list all the performer names in a standard format (the same for every track the artist is on, regardless of the artist/group as originally written), so I can directly select all the recordings by this artist. (For example, tracks with any of the different Artist names above would all be tagged as "Goodman, Benny; Lee, Peggy". Another example: Paul McCartney, Wings, and The Beatles when Paul is lead singer are all Artists tagged with his name, "McCartney, Paul", but also tagged "Wings" or "Beatles" as appropriate.)
My Artists field has all names as Last, First (group names are also standardized to always be the same, and omit articles), mainly accessed in a custom Artists view that top-level groups by first letter. As a list-type field it's easy to tag, selecting multiple artists as desired. For example, The Sound Of Silence is tagged as "Garfunkle, Art;Simon, Paul;Simon & Garfunkle" -- so the same song appears in my Artists view under all three names. This is enormously useful in every music genre, because artists often performed in a variety of groups and even with a variety of names.
Please note that I am reliant on custom list-type fields (I use several) and efficient keyboard tagging (my library will be growing by many thousands of tracks, ripped from vinyl, all added and tagged manually). Manual adding and tagging of this magnitude requires very efficient keyboard work, so I do all my music tagging with MC 15.0.122, in my opinion the last keyboard-efficient tagging version of MC. (The next version added forced-search to tagging, which drives me crazy; I can't find any way to be fast and efficient with it. My tags don't have anything I need to search for; I just want to directly jump through the complete list by typing, then select. Pane-tagging is not practical for me with more than 30 fields per track, and also not keyboard friendly.) I use MC17 for music playback, for photos (but would prefer MC 15.0.122 tagging behavior), and for video.
-
This change is great.
I, and many others, have been waiting for this since the artist images feature was added.
Until now i have been using an Artists list field but it doesn't work with artist images.
I just switched my views to use artist and everything works perfect.
I don't think using a list for artist is a can of worms, because its a default setting in most audio software.
It will make the move from other software much easier for the average user.
I imagine default views will be more compatible with peoples music libraries now too.
It would be interesting to know how many people actually use expressions and custom fields.
No one i know does, so this makes things a lot easier for them.
Thanks JRiver
-
Sorry, I don't get it... ?
Where can I switch between List-Typ edit and normal edit for Artist/Genre field? And what will be the visible change using list type?! I don't see any difference for me?!
-
I think this is a positive step forward, especially from the Genre side of things.
One question: My understanding is that when last.fm tracks that are included in Play Doctor, Genre tag info is used in the selection process. Will this now include all Genre tag info, or just the primary entry?
-
I just tried it:
Last.fm uses the new artist-field tagged as "Joshua Redman Quartet; Brad Mehldau" as one artist which is rather senseless for me.
I would like to scrobble only the primary artist i.e. "Joshua Redman Quartet".
My file-rename-rule for the directories with [album artist (auto)]\[album]\ also doesn't work as expected.
So for me this is no step forward, I will use my user library field "Artists" as List and use the new artist-field tagged as before.
-
My file-rename-rule for the directories with [album artist (auto)]\[album]\ also doesn't work as expected.
I think it's reasonable to store stuff under the primary's artist folder. So next build:
Changed: When building a filename from file information, only the primary / first artist or genre will be used from a list.
-
Yes, please! Provided that ; in the file tag is also interpreted as a delimiter, just as before.
Next build:
Changed: ID3v2 tag reading doesn't treat / as a delimiter in ID3v2.3, but instead uses NULL as the delimiter for reading and writing in ID3v2.3 and ID3v2.4.
-
Next build:
Changed: ID3v2 tag reading doesn't treat / as a delimiter in ID3v2.3, but instead uses NULL as the delimiter for reading and writing in ID3v2.3 and ID3v2.4.
Thanks! And I do hope that ; in the file tag is still read as a delimiter (how else would I get my existing lists in the file tags into the new stock list fields).
Are you considering introducing a way to search for list fields with more than one item, i.e. search for ; as displayed by MC?
For the stock fields that are now list fields and can have relationships I think we could use new stock fields like [Artist (Primary Artist)].
-
Are you considering introducing a way to search for list fields with more than one item, i.e. search for ; as displayed by MC?
You could create a column or calculated field like:
ListCount([Artist])
-
You could create a column or calculated field like:
ListCount([Artist])
Thanks for the reply and listening/reading!
Yes, I know but you told me in another thread, as I interpreted it, not to create too many calculated fields as this could decrease performance... ;)
And I thought you had to fix the "little arrow search" with the new list stock fields any way... (An underline marked hyperlink appearing when hoovering over each individual item in the grid would be cool/useful.)
-
I think it's reasonable to store stuff under the primary's artist folder. So next build:
Changed: When building a filename from file information, only the primary / first artist or genre will be used from a list.
Great - thanks. Now, can we please please get similar feature for syncing to handheld? I would like the primary artist to be listed in the artist field when exporting to Handheld.
Thanks,
Osho
-
A couple of reflections after having used the new version for a bit on my "production" library.
The ability to use the constellation of multiple items is lost. Prior to the change I could just write "lenn mcc" in the composer field in the tag action window to quickly tag a Beatles song. Could there be a way to reintroduce this handy functionality?
I used the little arrow artist search function a lot before when I wanted to search for precisely the current constellation of artists; if I wanted to search for just one artist the panes worked well. The ability to easily search for the constellation of items as well as each item would be useful, but if I have to choose the ability to quickly search for the constellation is more useful than the ability to search for just the primary artist: It is harder to manually search for the constellation, and I think it is a bit unintuitive to have a search arrow in a field that is not searching for the contents of that filed but just a part of the contents.
Since the TYER ID3v2.3 tag is not supported by MC I must use MP3Tag in addition to MC (support that tag and introduce stock fields for charset and ID3 version, and I think I can skip MP3Tag altogether). The new NULL list delimiter in MP3 ID3v2.3 tags means that I cannot use the grid in MP3Tag to see all items and edit them. Fine (well actually it is not, but I can live with that). I am used to that since this is how flac files with multiple tags always have worked in MP3Tag. What is worse is that if I by accident happen to just enter a tag in the grid that has multiple items, only the first item will be written back to the file tag, i.e. I have lost the other items without having a chance to notice what has happened. With flac files nothing is lost in this situation, since flac files have no delimiter but multiple tags. Consider this my last plea for ; (or something else visible in MP3Tag) as a delimiter in MP3 file tags.
If I in a categories artist view use a field relational to artist, I get strange results in the thumbnail text/details list style since the artist is not always the primary artist. Could fields relational to artist show values in thumbnail text/details list style only when the artist (the "[name]") is the primary artist?
On the positive side: Artist images work better. Having fields relational to only the primary artist is useful. The ability to read and write multiple flac Vorbis comments is also welcome since it adheres to standard (I had to combine my flac tags to use them when switching to MC and now I have to separate them again...).
-
Consider this my last plea for ; (or something else visible in MP3Tag) as a delimiter in MP3 file tags.
I just noticed this: I use the Lyrics Grabber Foobar2000 plugin to add lyrics. It seems that Foobar2000 is converting MC's NULL delimiter to " / " when saving lyrics to a file tag, so now I have to clean up the tags in MC after adding lyrics.
; as a delimiter worked better with all supplementary software I have to use. Has anyone noticed any benefit with the new NULL file tag item delimiter?
-
Has this been implemented already?
I'm on newest version of 17, and when i click on genre/artistS it only allows me to chose one genre.
-
Yes. It's implemented. Problem is that you have to write it. Not selecting. Selecting values from the drop down list will overwrite the previous tag. I would say that it would be highly logical with some check boxes next to each item in this drop down list, to allow multiple selections. First item selected to be given the first position for weighting?