Print

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

[Vocalpoint]

As part of my every growing audio collection - there are times that I would to search and especially group a custom view by specific label. It would be nice would like to group my audiophile label stuff like DCC or MFSL by populating a field. But no Record Label or Label field is supplied.

For those that track "label" as part of their library - is everyone doing their own thing and adding a custom field or is there one that I could use that's considered "standard" within the supplied MC library?

Thanks!

VP

[Alex B]

I'd recommend the Publisher library field.

For example, in MP3 files its value is stored in the TPUB ID3v2 frame. Here's a quote from http://www.id3.org/id3v2.3.0:

TPUB

   The 'Publisher' frame simply contains the name of the label or publisher.

[Vocalpoint]

I'd recommend the Publisher library field.

For example, in MP3 files its value is stored in the TPUB ID3v2 frame. Here's a quote from http://www.id3.org/id3v2.3.0:

EDIT: Is this frame/tag as standard in FLAC as in MP3?

Seems that MC does in fact pick up the "publisher" tag from an MP3 . I took a handful into the tag editor supplied with dbPowerAmp where this tag is actually called "Label". Pasted some info in and refreshed MC and the Publisher field picked up that data.

Alas - the same is not true for FLAC files- which is a deal breaker for me. If I take a FLAC file and open it via the dbPowerAmp editor - the same Label tag is available and can be filled. However when said FLAC file is reintroduced to MC - it does not pick up the value in the Label tag and map it to the Publisher field in the library...too bad - this could have been perfect.

Even more interesting is when I click the FLAC in MC under Detailed Format Information and examine the VorbisComment Block - I see an actual Label Field and a LabelNo field that have been populated (most likely from Tag N Rename in my case) with information - but these two fields also do not appear anywhere in the MC default tag window. (:

Note: I am trying this in 14.0.161 - maybe it's been fixed for V15?

Cheers,

VP

[Alex B]

The FLAC tag issue is not actually a bug. It is caused by the lack of any official standard.

An unofficial de facto standard seems to be "Organization". It is the actual header that is written by some applications to the FLAC files when a Label or Publisher field is tagged. E.g. MP3tag and Winamp  use this mapping. (I must check how dBpoweramp and T&R handle the "Label" fields in MP3, FLAC and other formats before I can say my opinion about them.)

Currently MC uses a WYSIWYG system when it writes a Publisher value to the file tag, i.e. "what you see is what you get". However, I think the Publisher tag mapping change is already on the JRiver's to do list and Bob from JRiver is going to implement this and a few other tagging tweaks soon.

For now, as a workaround, you can create an "Organization" custom field. After the new tag mapping is available you can update the file tags and/or library once to make the file tags consistent with the library data.

[Vocalpoint]

However, I think the Publisher tag mapping change is already on the JRiver's to do list and Bob from JRiver is going to implement this and a few other tagging tweaks soon.

For now, as a workaround, you can create an "Organization" custom field. After the new tag mapping is available you can update the file tags and/or library once to make the file tags consistent with the library data.

Awesome. Thanks for the update. I will play around a bit here and see what works best.

Cheers!

VP

[MusicHawk]

I've avoided the confusion by using an ID field. In it I put the label and number (Columbia 1-2345, etc). But I'd love to have "official" fields and separate these, so hope Bob's work on MC bears fruit.

But ID (or any such field) is difficult to use simply because music recording publishers have bizarre practices. So even with different, better fields, there also might be best practices for how to use them.

Therefore, I'm curious how to handle "the rest of the story", which is the different types of number, and even crazier, the sloppy way label names are used these days.

The main split is recordings on vinyl, which typically had one label name and one catalog number, (RCA LST-29292), and CDs, which early-on adopted bar-code based numbers AND "label name as marketing, not cataloging".

In the vinyl days, a label was a label. The publishing company might have a different name, but clearly there was a label name. Motown Record Company used label names Motown, Tamla, Gordy, Shout, VIP and a few others. Each label had its own numbering system. But it's straightforward to determine the label -- just look at the record.

The switch to CDs roughly coincided with lots of merging of record companies into larger entities (Universal, PolyGram, EMI, Bertelsmann, Time Warner, etc). In many cases, these super-sized companies reissued recordings on different labels from the original. But odder, they sometimes omitted the label name from the CD, OR really got weird by using two or more label names on the same recording -- usually because the label itself is famous so it is marketing/branding, not really the "label"/publisher.

Compounding this is that the bar code identifies the publisher (first part of the number) and in exploring my collection, the coded publisher name doesn't always match the label name declared on the CD. I have lots of CDs that sport both the "Capitol" and/or "EMI" and or "CEMA" logos -- which is the "label"? Most of them seem to have the EMI publisher number, but not all. Some use a different publisher number.

I have "Verve" label recordings with at least three different publisher IDs. Verve is used as a logo because it's a famous jazz label, but it's not really the publisher, which is Universal or UTV or PolyGram or other names depending on the vintage of the CD. But they all say "Verve".

EMI, Universal, Bertelsmann, Time Warner -- they are rather "flexible" about this. Lots of examples.

To deal with this, my use of the ID field is to put the numeric version of the bar code FIRST in the field, so sorting groups by publisher since it's the first part of the number. Then I follow this with the label name or sometimes the multiple label names declared on a single CD, just so I can see what they are, and search on them if desired. Messy.

Ideas?

[Vocalpoint]

Weird.

Now after an update to 15.0.80 - I suddenly see a new (and presumably included) audio field called Catalog#? Was this here in 15.0.73?

EDIT: I use Tag N Rename to handle my tag chores and it too features a field called Catalog # - but alas - placing a value in that field in either MP3 or FLAC files - does not map over to the Catalog # field in MC.

Maybe Bob's upcoming work will hopefully connect these fields correctly between MC and some of the more popular tagger apps out there....

Cheers!

VP

[MusicHawk]

Good discovery -- hadn't noticed field Catalog #. I don't know when it was introduced but (quickly checking a spare PC) it was there at least since 15.0.65.

I'd sure appreciate someone at JR (Bob?) explaining the purpose of the many (and growing) stock fields that have unclear purposes, especially when there are multiple stock fields that seem to have the same or overlapping purpose.

The ideal form of this would be an official page in the MC Wiki with a table that lists every field/tag, stating its purpose, and with columns for each tag standard, major media manager, tagging tool, etc. identifying where the tag is supported or not.

The complete table of fields/tags should also state any comments/limitations/anomalies of each field ("numeric only", "length-limited in some situations", etc). For instance, I posted several reports of a problem using Accepted Values with the stock Tempo field. It seemed like a bug, but Matt eventually responded that Tempo is one of a few fields with "special" behavior that can't use Accepted Values. If ALL fields were documented in the wiki my hours of frustration and re-dos and reports of a (non) bug could have been avoided. (Though I have to say, since MC allows this field to be given Accepted Values, and they work for hours or days before they vanish, I'm still not clear on what's going on or why it's "special".)

[Vocalpoint]

Good discovery -- I see it too. I don't know when it was introduced but (quickly checking a spare PC) it was there at least since 15.0.65.

I'd sure appreciate someone at JR (Bob?) to explain the purpose of the many (and growing) stock fields that have unclear purposes, especially when there are multiple stock fields that seem to have the same or overlapping purpose.

I would appreciate an explanation on why those fields that are part of the global ID3v2 tagging standard (at least for MP3 and FLAC) are not automatically mapped to the same in MC - in addition as to why there is such a huge stash of stock fields that seem to be unclear in purpose.

The ideal form of this would be an official page in the MC Wiki with a table that lists every field/tag, stating its purpose, and with columns for each major media manager/tagging tool identifying where the tag is supported or not.

+100. This would be ideal and would save folks a ton of time.

Cheers!

VP

[vagskal]

However, I think the Publisher tag mapping change is already on the JRiver's to do list and Bob from JRiver is going to implement this and a few other tagging tweaks soon.

Now that sounds promising!

(I must check how dBpoweramp and T&R handle the "Label" fields in MP3, FLAC and other formats before I can say my opinion about them.)

dBpoweramp writes Organization for flac and TPUB for ID3v2.3.

For now, as a workaround, you can create an "Organization" custom field.

If you do that and want just one field/column instead of two you can use this expression to merge the two fields

Code: [Select]

ListCombine([Publisher],[Organization])&datatype=[list]
Note that you still have to edit the Publisher or Organization field depending on the file type if you want the information written back to the file in the correct format.

The ideal form of this would be an official page in the MC Wiki with a table that lists every field/tag, stating its purpose, and with columns for each tag standard, major media manager, tagging tool, etc. identifying where the tag is supported or not.

The complete table of fields/tags should also state any comments/limitations/anomalies of each field ("numeric only", "length-limited in some situations", etc).

+1

At least the information regarding for each field limitations and the logic for reading/writing information from/to the actual file would obviously have to be managed by J River. I got very surprised when it turned out that MC for mp3 files actually writes back two tags (TPE2 and a TXXX Album Artist tag) to the file from the MC Album Artist field. If you do not know this and edit just the tag you normally use (TPE2) with an external editor you can get strange results (and MC is the only tag editor I know of that can in one go automatically write one field to two file tags; I guess that also says something about the usability of this "feature" which cannot be controlled by the user...). I do hope that J River at least provides us with a detailed change log entry when the field logic is changed.

The information on how other tag editors and rippers display and handle tags could be updated and supplemented by the community. I would be happy to contribute as regards the tools I am familiar with.

[Alex B]

At least the information regarding for each field limitations and the logic for reading/writing information from/to the actual file would obviously have to be managed by J River.

The tag mappings have changed from time to time. Usually a change has been triggered by popular demand. I don't think there is a master plan. Also there is no single correct way to write a certain library field to various file/tag formats. Obviously the first priority is to maintain compatibility inside MC (when possible). After that comes compatibility with the rest of the world. The developers have to decide which is the most compatible compromise when multiple possibilities exist (and usually things are not as simple as e.g. "write Name to Title or Name depending on the file/tag format").

I got very surprised when it turned out that MC for mp3 files actually writes back two tags (TPE2 and a TXXX Album Artist tag) to the file from the MC Album Artist field. If you do not know this and edit just the tag you normally use (TPE2) with an external editor you can get strange results (and MC is the only tag editor I know of that can in one go automatically write one field to two file tags; I guess that also says something about the usability of this "feature" which cannot be controlled by the user...).

You can blame Apple and Microsoft for the misuse of TPE2 (band/orchestra/accompanied). You can't really fight against those two, can you?

In the past MC wrote Band to TPE2 and Album Artist to a custom tag, which is a logically correct way to handle them because unfortunately Album Artist has never been one of the defined tags in the ID3v2 standards. (Edit: MJ/MC supported the Album Artist concept before it existed in WMP and before the Windows version of iTunes existed at all.)

However, in about 2006 a growing popular demand to map Album Artist to TPE2 appeared. The former WMP and iTunes users needed this mapping. After some debate it was agreed that the best compromise was to support both implementations (the old custom tag and TPE2). The change was finally implemented in MC13. (Edited also this paragraph a bit. It wasn't exactly correct.)

The only thing that practically got compromised is the actual Band field. It was not possible to start using TXXX Band because that caused problems with some programs when TPE2 and TXXX Band were displayed as the same tag and tagged with mixed results. The best comprimise was to map Band to a different TXXX tag (which can be read with the other advanced programs that can maintain any custom tags).


A separate issue was the chosen way to tag the ID3v2 custom tags. The standard allows two different approaches. One is to use Comment frames with descriptive headers (i.e. create ID3v2 tags that may contain multiple COMM frames with unique headers). The other is to use the TXXX frames (= user defined text frames). A TXXX frame must always have a unique header.

Musicmatch was probably the first program that started to use predefined (but not user defined) ID3v2 custom tags about ten years ago. The Musicmatch developers chose to use the COMM system. When MJ9 (released as MC9) was under development the JRiver developers wanted to add support for user defined tags in all supported file formats. For MP3 they adopted the COMM system because it was already used in Musicmatch and no program wrote or even understood TXXX frames at that time. (As far as I know, MJ/MC9 was the first player program that included support for any user defined custom tags. The next was foobar2000 a bit later.)

A few years later the situation was different. Musicmatch was dead and those programs and devices that supported custom tags usually supported TXXX frames instead of COMM frames. MC needed to change. TXXX support was introduced in MC13 and thus Album Artist changed from "COMM Media Jukebox: Album Artist" to "TXXX Album Artist". At the same time Album Artist was also mapped to TPE2 for the above mentioned reason.

I do hope that J River at least provides us with a detailed change log entry when the field logic is changed.

I think most, if not all that I wrote now is available in the forum history.

The information on how other tag editors and rippers display and handle tags could be updated and supplemented by the community. I would be happy to contribute as regards the tools I am familiar with.

I welcome you to start that. Perhaps the info could be presented in a table format and the changes could be added to JRiver Wiki after they have been "approved" in the related forum discussion.

A few years ago I created a list of the supported ID3v2 tags (it's not up-to-date):
http://yabb.jriver.com/interact/index.php?topic=35068.msg276801#msg276801
The whole thread contains discussion about the tagging changes that were implemented in MC12 and MC13.

[vagskal]

I think it is an elegant solution per se for most users to write the Album Artist MC field to two tags because this seems to ensure the best compatibility with other SW and HW players. My point was that it would be useful to have information about this clever but uncommon feature easily available in a list explaining all MC stock fields (although I would actually prefer a user option controlling the behaviour so I can switch it off). If I know about the double tags I can try to manually ensure coherence (because I cannot use MC to compare the content of those two tags; I know I can do an update of the tags from library for all files). I searched your webpage and found info on this in a change log from 2008, long before I started using MC:

13.0.46 (9/24/2008)

[Snip]
2. Changed: "Album Artist" is saved as both TPE2 and TXXX(Album Artist) in MP3 ID3v2 tags. (Band is now stored as TXXX(Band))

Now that I am a (happy) MC user I read the current change log and hope to be alerted that way of any changed behaviour. For everybody using MC, including new users and users who are not reading changelogs old or current, it would be easier to have a list in the wiki.

What about the following as a start for a new wiki page?

Using Both Flac and MP3 (ID3v2.3) Files With MC

MC is automatically reading and, if you set that option for the MC field in question (Tools>Options>Library & Folders>Manage Library Fields>Store in file tags (when possible)), writing file tags to/from certain stock fields in MC. Since flac and mp3 files have different types of tags there are some information and tricks that can be useful when having both file types in your MC library.

MC Field Album Artist

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	Both TPE2 and TXXX Album Artist (I do not know which takes precedence if different)	Both TPE2 and TXXX Album Artist
Flac Vorbis comments	Album Artist	Album Artist

Note that you cannot use MC to compare the information in the two mp3 ID3v2.3 tags TPE2 and TXXX Album Artist. If you want to ensure that those two tags have the exact same information (after you have used an external tag editor, for instance), you can in MC select all audio files in your library and select Tools>Library Tools>Update Tags (from library). The option Tools>Options>Library & Folders>Manage Library Fields>Store in file tags (when possible) must be checked for the library field Album Artist. Note that this operation can overwrite existing information in also other file tags.

dBpoweramp used to write as default an Album Artist Vorbis comment in flac files when ripping, but that behaviour changed so the current version of dBpoweramp as default writes an Albumartist (just one word instead of two) Vorbis comment in flac files when ripping. MC is not automatically reading the Albumartist Vorbis comment, but you can in MC create a custom field named exactly Albumartist to import that tag. After you have done that you can in MC select all your audio files and select Tools>Library Tools>Update Library (from tags) to actually import the tag information. Now you have two different MC fields containing the same type of information. If you want just one field/column instead of two you can use this expression for a column or a custom field named Albumartists, for instance, to merge the two fields:

Code: [Select]

ListCombine([Album Artist],[Albumartist])&datatype=[list]
Note that you still have to edit the Album Artist or Albumartist MC field depending on the file type if you want the information written back to the file.

Squeezbox Server supports in mp3 ID3v2.3 TPE2, TXXX Album Artist and TXXX Albumartist and in flac Album Artist and Albumartist Vorbis comments (see http://wiki.slimdevices.com/index.php/SlimServerSupportedTags for more information). It is unclear which tag takes precedence if they are different.


MC Field Publisher

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	TPUB	TPUB
Flac Vorbis comments	None	None

It is common to use in flac files an Organization Vorbis comment for the publisher/label information. dBpoweramp for instance as default writes an Organization Vorbis comment in flac files when ripping. MC is not automatically reading the Organization Vorbis comment, but you can in MC create a custom field named exactly Organization to import that tag. After you have done that you can in MC select all your audio files and select Tools>Library Tools>Update Library (from tags) to actually import the tag information. Now you have two different MC fields containing the same type of information. If you want just one field/column instead of two you can use this expression for a column or a custom field named Label, for instance, to merge the two fields:

Code: [Select]

ListCombine([Publisher],[Organization])&datatype=[list]
Note that you still have to edit the Publisher or Organization MC field depending on the file type if you want the information written back to the file.

Squeezbox Server has no native support for the ID3v2.3 TPUB tag or the Organization Vorbis comment, but you can use the CustomScan and CustomBrowse plugins to display those tags (see http://wiki.slimdevices.com/index.php/Custom_Scan_plugin and http://wiki.slimdevices.com/index.php/Custom_Browse).

MC Field Disc #

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	TPOS (if in the format 1/2, / and the number(s) thereafter are skipped)	TPOS (if the file tag has information in the format 1/2, the part from and including the / will be lost)
Flac Vorbis comments	None	None

It is not uncommon to use in flac files a Discnumber Vorbis comment for the disc number information. dBpoweramp for instance as default writes a Discnumber Vorbis comment in flac files when ripping. MC is not automatically reading the Discnumber Vorbis comment, but you can in MC create a custom field named exactly Discnumber to import that tag. After you have done that you can in MC select all your audio files and select Tools>Library Tools>Update Library (from tags) to actually import the tag information. Now you have two different MC fields containing the same type of information. If you want just one field/column instead of two you can use this expression for a column or a custom field named Disc, for instance, to merge the two fields:

Code: [Select]

If(IsEmpty([Disc #]), [Discnumber], [Disc #]
Note that you still have to edit the Disc # or Discnumber MC field depending on the file type if you want the information written back to the file.

If in list views grouped by album you would like to have the files of an album sorted in disc number and track number order, you can select Sort Inside Groups By>Custom and add first Disc (a-z) and then Track# (a-z). You can save this sort order as a preset.

Squeezbox Server supports in mp3 ID3v2.3 TPOS and in flac Discnumber, Disc # and Disc Vorbis comments (see http://wiki.slimdevices.com/index.php/SlimServerSupportedTags for more information).

[Alex B]

I searched your webpage and found info on this in a change log from 2008, long before I started using MC:

13.0.46 (9/24/2008)
2. Changed: "Album Artist" is saved as both TPE2 and TXXX(Album Artist) in MP3 ID3v2 tags. (Band is now stored as TXXX(Band))

A small additon. The Band field was fine-tuned three times after 13.0.46 Beta:

13.0.49 (9/29/2008)
7. Changed: MP3 tag "Band" is stored as TXXX(Band/Orchestra) instead of TXXX(Band).

13.0.52 (10/2/2008)
7. Changed: MP3 tagger saves Band to TXXX(Band) and Orchestra to TXXX(Orchestra). (done since there are both band and orchestra library fields)

13.0.129 (02/25/2009)
5. Changed: The "Band" field is saved as TXXX(JR/Band) in an MP3 ID3v2 tag instead of TXXX(Band) to avoid conflicts with some software that considers TXXX(Band) the album artist

MC Field Album Artist

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	Both TPE2 and TXXX Album Artist (I do not know which takes precedence if different)	Both TPE2 and TXXX Album Artist
Flac Vorbis comments	Album Artist	Album Artist

The precedence order is:  1) TPE2 ,  2) TXXX Album Artist  and  3) COMM Media Jukebox: Album Artist

(i.e. MC13 and newer can read the old Album Artist tag)

Note that you cannot use MC to compare the information in the two mp3 ID3v2.3 tags TPE2 and TXXX Album Artist. If you want to ensure that those two tags have the exact same information (after you have used an external tag editor, for instance),

The format info window in Action Window > Tag can show the three different versions. It shows a direct tag dump from the file. Though it can show only one file at a time. (Click the first line in AW > Tag or the actual "Format" line to open the window.)


Two other corrections:

MC Field Publisher

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	TPUB	TPUB
Flac Vorbis comments	None	None

Flac: Publisher, not None

MC Field Disc #

MC behaviour:

File tag	Reading	Writing (if that option is set)
MP3 ID3v2.3 tags	TPOS (if in the format 1/2, / and the number(s) thereafter are skipped)	TPOS (if the file tag has information in the format 1/2, the part from and including the / will be lost)
Flac Vorbis comments	None	None

Flac: Disc #, not None


In general, I agree with everything you said. Personally, I don't know if I have time and energy left for a new documentation project, but at least I can promise to post my comments and give advice (if I can).


EDIT: naturally also the Monkey's Audio, Musepack, WavPack, Ogg Vorbis and Windows Media tags should be included. (Currently the three APE v.2 taggers differ from each other and the Ogg Vorbis tagger differs from the FLAC tagger, but I hope Bob will fix the unnecessary discrepancies.)

[vagskal]

Thanks. I have taken into account your corrections and comments and put up a wiki page here: http://wiki.jrmediacenter.com/index.php/Different_Audio_Formats_In_MC

I also added some information on MC custom fields (and when it is not at all possible to import file tags) and multiple Vorbis comments. Furthermore, I made clear that the case where a flac file actually has ID3v2.3 tags is not dealt with. Please feel free to edit, correct and supplement the information.

I am not familiar with editing wiki pages so the page might not look so good, especially the tables, and I do not know how to link it to the main wiki index, but I hope it will show up if you search the wiki.