The Case for a Dedicated LABEL Tag

The usual advice is to store CD label data in the PUBLISHER tag (or the ORGANIZATION tag for FLAC). More than 20 years ago the ID3 tag TPUB was defined as "the name of the label or publisher". In my opinion that "or" has caused confusion and sloppy data entry ever since. A publisher is a business organization but its CD or record labels are product brand names. Those names may or may not be the same and confusing them is common.

The confusion is magnified by the fact that one publisher may own many CD labels. Perhaps that is why iTunes wisely provides separate label (©lab) and publisher (©pub) tags. I very much prefer this approach.

This spring I began using dBpoweramp 17.6 to rip and tag my CD collection to FLAC and/or M4A. After ripping I edit the tags in Mp3tag. However, in the Publisher tag I found grossly inconsistent values from the Internet databases. Sometimes the tag showed the name of the parent company, sometimes the CD label, sometimes both, and sometimes both plus the catalog number or other data, all in one tag! I have even seen Publisher used to store the name of the song publisher on each track. In short, Publisher content from the Internet is often a mess, even when it conforms to that ancient ID3 spec.

None of this is the fault of dBpoweramp, which is a remarkable application, by the way. It simply passes on content from the Internet.

To get a grip on this problem I created a custom tag LABEL in Mp3tag. This tag holds the CD label name and only that name. Then I added the following mapping line in Options for my M4A files:

MP4 > ©lab > LABEL

My FLAC files do not need mapping because Mp3tag already recognizes LABEL tags in FLAC files.

Before ripping a CD in dBpoweramp, I select all tracks and type in the label data and the catalog number (except when the latter has been pulled from the Internet automatically).

For my existing files I simply select all tracks for the album in Mp3tag and type or paste the label name and the catalog number into the tag panel boxes. Often I then delete the Publisher tags.

These extra steps add a little time but in the end I find it worthwhile to have consistent data. For example, it is sometimes enlightening to sort my CD rips by Label in Mp3tag. A meaningful sort on a raw Publisher column is often impossible because of the mix of data there. With a dedicated Label column the sort is easy and accurate.

Given how well my custom Label tag works, I don't know that adding internal Mp3tag support for it would offer me much. But I am open to the opinions of others on that. I'm also curious about how others deal with the mix of content that so often appears in Publisher tags.

1 Like

I would not expect it to be otherwise

One tag field for the all companies involved; listed in alphabetical order, separated with ; as , would not be sufficient as some companies might have it in their names. i use PUBLISHER for that

Second tag field for all IDs; listed in ascending / alphabetical order. I use DISCNUMBER for that. [Info about disc number I store in TRACK, preceding number of track with . in-between]

If I do not have proper data- I leave those fields alone. Publisher in my system can have bootleg, while no id in that other means was no known ID or number of a release. And I always wipe out all tag fields and write or paste in data manually; and come back to it the next day to see if I did not make some mistake, double checking everything

I would be careful with this option. Most audio file metadata formats for track and discnumber only formally allow an integer. The m4a format won’t even permit padding with a zero. The only exception I am aware of is the id3 spec that does allow a forward slash, intended to separate the current disc/track from the total.
This proposed structure may work for some, but may cause issues with other editors and/or players.


Thanks for the warning, but I already know this from experience

And the more audio formats you use, the harder it gets to maintain a coherent system that works with your players [so far I use just one]. I had quite a problem with coming up with my system [, APE files problem] and had to do some thinking outside the box [like using COMMENT for some additional year data so, long story short, that I could see it in Winamp]

Understood, this works for your workflow and player. My warning was for other users that are looking for input here where this may cause them to have the issues I described above.

Thank you, Zerow, for your interesting comments!

I started out using DISCNUMBER that way, until I realized that CATALOGNUMBER was supposedly intended for that. The change also freed up DISCNUMBER to hold the CD volume number.

Unfortunately combining disc volume number with track number would not work for me since so many of my files are in M4A format. That format, to MotleyG's very good point, supports only integers as track numbers. But I see how your scheme makes track sorting by CD volume easier.

Absolutely, no guess work allowed. But when ripping CDs, I can almost always find what I need from the booklet. And I can use the booklet to verify artist and title data from the Internet.

The tedious part is manually adding the recording year and vocalist for each track. I have to transcribe these from the usually microscopic type in the booklets. I do that because most of my CDs are compilations of historical recordings going back almost a century. The year of recording is critical information. I use the YEAR tag to hold it and I include it in the file name, like this:

Jack Payne & His BBC Dance Orch (1931) Ten Cents a Dance (Elsie Carlisle).m4a

The release year for the CD goes into my COMMENT tags.

So we are both using standard tags in our own special ways, thinking "outside of the box" as they say. The extreme flexibility of Mp3tag makes this easy....

You can use a tracknumber plus a preceding discnumber to get 3-digit-numbers in track like
101 for the first track from disc 1, 111 for the eleventh, 206 for the sixth from disc 2 and so on.

I would like to draw your attention to the field ORIGYEAR which may hold the year of the recording while YEAR holds the year of the media release ...
and then, for even more specific dates, there is RELEASETIME.

Thank you for your suggestion. I started using YEAR this way many years ago, long before I knew about ORIGYEAR. I considered changing over, but with so many actions and formulas to change, it was going to be a lot of work. So mostly out of laziness, I have not made the changeover. But you are correct, for someone new to tagging , ORIGYEAR makes more sense.

Whether it makes more sense ... doesn't this depend a lot on how many details you want to see in a certain environment.
AFAIK ORIGYEAR is hardly displayed by any player, so YEAR would probably be better to filter for tracks from 1931 (as an example). But for purists the ORIGYEAR would represent the better place for the data.

Yet, as you wanted to split between publisher and label, I thought the ORIGYEAR might add that extra gist to your data.

1 Like

I use

  • YEAR for first known release of version of album

  • COMMENT for the actual year of recording [as an album might hold some older tracks]

  • ALBUM for the name of album - which can have an additional info in-between < > like e.g. 2010 50th Anniversary Edition or 2020 Remaster

That last one might look weird and even have some un-grammatical data - but it sure does allow me to sort it 100% clearly in Mp3tag [Brackets display order - [ ] ( ) { } - #48 by Zerow]

As for method of putting the year info in TITLE and / or FILENAME. Ask yourself a question when is it that you really need this year info. You might be able to get rid of it from them [thus freeing precious space for very long titles] by putting it in separate tag field - and yet [depending on what file formats you use] still see it in Winamp by using

Options > Preferences > Playlist > Titles > Advanced Title Formatting

or some other player with a similar feature

I do not put Year values into Title tags, only into file names.

Most of the time, really. For example in Windows Explorer. Even though that has the capability to show the year column in a view, it doesn't save that selection and I have to add it again the next time. Since I often have many Explorer windows open at once, I don't want to be forever fiddling with the columns. Explorer has templates that supposedly can preserve column settings but in Windows 7 they are so unreliable as to be useless.

Also, popular music styles began to evolve rapidly in the 1920s and there were dramatic variations from year to year. For dance and jazz bands of that time, the recording year is almost as significant as the artist name. And the year also reflects the technology. Recordings prior to 1925 were acoustic, but after 1925 they were mostly electrical.

I settled on my file name format after many years of experimentation. I cling to it like a dying man.... If a file name is too long, I may abbreviate parts of it.

As for Winamp, I'm a big fan and have used it for many years. My titles formatting does indeed use the Year tag: %track%: %artist% '('%year%')' %title%
which of course is almost the same as my favorite file name format....

The talk is that Winamp 5.9 is finally coming:

For the longest time I was using Windows Commander - but no as a file-manager and a go-to file-handling method, but only for few tasks. And that was plain stupid

8 years ago I stopped using Widows Explorer all together and have been using only FreeCommander ever since, as it allows to have for pinned tabs and sorting by data in columns and many other helpful adjustments of modus operandi. And every time some program opens for whatever reason Widows Explorer I get a mad I have to experience it once more. Yes- its much better now than it was in Window XP, but nevertheless there is no point in comparing it to even
Windows Commander

I would suggest you to try it out or look for a similar filemanager that will have extensive support for displaying data from tags. I myself only use Mp3tag for this [and Winamp] so ask around on this forum for a proper software. If you have order in your FILENAMEs then it will be easy to remove those years in an automatic way and then just manually check for errors


Most interesting

I used to use a program called Powerdesk which worked very well until it was sold and resold and eventually turned into a bug-filled piece of crap.

The reason I don't use Mp3Tag for this is that it lacks a "folder view only" option and insists on loading files when I want to work only with folders. Whereas in Explorer I can drag and drop folders and create or rename them quickly and easily. Everything else I do in Mp3tag.

With all due respect I think I already have order in my file names, at least by my terms. :smile: So I think we will have to agree to disagree on that. I also use a lot of folders to organize my files, which helps keep my file names relatively simple. But I appreciate your suggestion.

FYI, this doesn't write a ©lab MP4 atom but a user-defined field named ©lab.

From the documentation:

Please note that you can’t change the mapping of ID3v2 frame identifiers or MP4 atom names to Mp3tag’s internal field names.

Thanks for the info but I'm a little confused. It appears that my line above

and so on is not accurate. If so I will be happy to change or delete it. I did not understand that it was necessary (or even possible) to create a custom source field when mapping to standard MP4 tags not supported internally by Mp3tag. Please forgive my ignorance but I am out of my depth here and I want to get this right....

EDIT: Never mind. I went ahead and removed the questionable text.

If you want to store the label in the metadata and distinguish it from PUBLISHER, I'd just use LABEL for that. It's a user-defined field, but with clear semantics that can be copied over to any other field if it ever becomes necessary.