Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: %CONTENT GROUP% mapping error (Read 10121 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: %CONTENT GROUP% mapping error

Reply #25
If you will kindly follow the link I provided, hydrogenaud.io's Tag Mapping Page you would learn I'm not trying to change the standard; I am trying to bring foobar2000 up to standard.
These changes are not persional, or based on a singular opinion; I'm simply pointing out erroneous field mappings in foobar2000 based on  hydrogenaud.io's Tag Mapping Page.

@Temerald:
You are wrong assuming, that the list on wiki you linked is a "standard" of mapping. There is no standard of correct mapping of the tags of different file formats.
In fact, every music software does its own mapping. That is: WinMediaPlayer maps in a different way than iTunes does. iTunes maps differently compared to WinAmp. WinAmp maps in a different way than MediaMonkey. And MediaMonkey maps differently than your Android phone...
This is a big problem for interoperability of tagged music. It's a mess and it happened, because there is NO standard.
The widely used tagging software MP3tag was initially designed for iTunes users, and it mainly uses the iTunes mapping scheme. And your linked mapping scheme on wiki is based on this software. But again, this mapping scheme produces errors when used with other software.
The only way to achieve "correct" tagging is:
1. decide the software you want to use
2. decide the file format to use
3. read the documentation of your software's mapping scheme for your file format or check it out by yourself
4. put your information in the appropriate tags, so that it will be read correctly by the software you want to use
This means unfortunately: If you want to read your tagged music files with another software, you first need to "translate" your tags.

Mediamonkey found a solution for this. They do double and triple tagging for "ambiguos" tag names: for example, an album artist like "Pink Floyd" is written into a flac file using three Vorbis comments simultaneously: "ALBUMARTIST=Pink Floyd", "ALBUM ARTIST=Pink Floyd" and "BAND=Pink Floyd". As a result, the album artist will be read correctly by a broad variety of software. But that's off topic.

Re: %CONTENT GROUP% mapping error

Reply #26
CONTENT GROUP is much more logical, than GROUPING. ...
I respect only logics. For me logical thinking is the only "authoritative".

@infinci
I try to give you a logical explanation, for you to understand, how this grouping field is meant, and why it might be indeed more correct to name it GROUPING than CONTENT GROUP:

The term "content group" was invented by the id3tag consortium for the documentation of id3tags (http://id3.org/id3v2.4.0-frames).
It is the first of three tags holding "TITLE information" for the content of a track:
TIT1 = 'Content group description'
TIT2 = 'Title/Songname/Content description'
TIT3 = 'Subtitle/Description refinement'
Unfortunately the term "content group" is a bit misleading and the description in the documentation is not very well comprehensible, too... The TIT1 tag should be used, if the track belongs to a group of consecutive tracks, that form together a section of music. The TIT1 tag holds the title of this group of tracks. With other words: TIT1 groups tracks.

In classical music, a composer's "work" in most cases consists of more than one "movements". Normaly each movement is recorded to a separate track. For example, Chopin's piano concerto splits into three tracks:

Chopin: Piano Concerto No. 1, op. 11
  1. Allegro maestoso                   (=title/TIT2 of first track)
  2. Romance: Larghetto                 (=title/TIT2 of second track)
  3. Rondo: Vivace                      (=title/TIT2 of third track)

Then, the group of these three tracks is named "Piano Concerto No. 1, op. 11" (=content group/TIT1)

As this field is mostly used for the "works" of classical music, it would have been easier and much more comprehensive to call this field "work" instead of "content group" or "grouping". But the term "work" is constrained to classical music, and in some cases you might also want to group some tracks of non-classical music, for example the "first part" and "second part" of a rock concert. Therefore the id3tag consortium did not want to restrict this field to classical music, and they looked for a more universal term and chose "content group description".

As you can see, the grouping field really groups consecutive tracks to a group: Each grouped track has a different "track title", and all grouped tracks share a common "grouping title". (This is a bit similar to the ALBUM ARTIST field that groups different ARTISTS under one common ALBUM.)
This field has nothing to do with genre, style, music category, or content type... it really is meant to tie tracks together.

And logically now: CONTENT GROUP is much more misleading than GROUPING. The term "content group" even misled you, to assume that it describes some form of "content type", but it instead groups tracks together.

Vorbis comments should be named with a term as clear as possible. This is why most software developers mapped the id3tag TIT1 to the Vorbis comment GROUPING and not to CONTENT GROUP. And this is why the mapping proposal of wiki.hydrogenaudio.io recommends GROUPING for Vorbis comments and for APE files. It does not recommend "content group".

Also, iTunes developers chose "@grp" for the tagging of m4a files and not "@cnt" or "@cgr", because "grouping" is much more clear than "content group".

AFAIK there is no software in this world that writes a tag named CONTENT GROUP into files. In the linked tag-mapping-proposal of hydrogenaudio, only WMA files should be tagged with "WM/ContentGroupDescription". But the Windows MediaPlayer does not even support this field. It is likely that this tag name has not been designed by Microsoft. Presumably it has been designed by other developers with the need to map TIT1 to an apropriate field in WMA files. And the term WM/ContentGroupDescription seems to be simply copied from the id3tag documentation.

Ergo, to my opinion and (hopefully) fully logical: GROUPING is the better term than CONTENT GROUP.

Re: %CONTENT GROUP% mapping error

Reply #27
This tag mapping is confusing now in Beta 17.
Yes, that's true.

The field was not mapped erroneously. I repeat: Vorbis comments has no standards. ONLY recommendations.

Yes, that's true. And it's even worse: Vorbis comments are not designed to be renamed or remapped at all. Vorbis comments are designed to show up in the application in the same way, as they are written to the file. If you want to have another name for this tag, just give it another name. This is different to other tag types, for example id3, where TIT1 has to be translated/mapped by the software to an understandable description. Vorbis comments have not to be mapped, they describe themselves.
The new mapping of foobar breaks the rules for Vorbis comments. It is a non-standard implementation. It's simply a mistake.
AFAIK there is no other Vorbis comment that is remapped to a different name in foobar.

Now there are four reasons, why this new mapping is a mistake:
1. foobars behaviour of tag writing and reading is confusing
2. CONTENT GROUP is a misleading term, in comparison to GROUPING
3. mapping of Vorbis Comments breaks the rules, as they should be displayed "as they are written"
   GROUPING should show up as <GROUPING> and not as <CONTENT GROUP>
4. In foobar no other Vorbis Comments are translated/remapped to a different field name

To solve these problems, I recommend to use the field %grouping% instead, and map all other tags to this field:
Vorbis: GROUPING
APE: Grouping
ID3tag: TIT1
iTunes MP4: ©grp
WMA: WM/ContentGroupDescription

Peter, would you please implement this in the next update.
Thanks

Re: %CONTENT GROUP% mapping error

Reply #28
@Temerald:
Thank you for bringing this topic into life. It makes handling of the grouping field with different files a lot easier!! Thank you very much! And thank you Peter for this gem of software.

Re: %CONTENT GROUP% mapping error

Reply #29
@infinci
I try to give you a logical explanation...
Thank you for your really interesting and valuable explanation. It seems to be right story. Unfortunately, 1. not fully right; 2. it only affects the surface, not the deep waves. As a result, what appears to be true, in the end became false. Half-truths are dangerous things, they deceive people.

Explanation little later, I am busy now.

 

Re: %CONTENT GROUP% mapping error

Reply #30
Quote
4. In foobar no other Vorbis Comments are translated/remapped to a different field name
You are not entirely right.
Code: [Select]
static const struct {
const char * m_fb2k;
const char * m_vorbis;
} g_remap_table[] = {
{"PUBLISHER","ORGANIZATION"},
{"ALBUM ARTIST", "ALBUMARTIST"},
{"TOTALTRACKS", "TRACKTOTAL"},
{"TOTALDISCS", "DISCTOTAL"},
{"CONTENT GROUP", "GROUPING"},
};
These are the fields currently remapped between fb2k (former) and Vorbis Comments (latter). At some point of time foobar2000 did pass unchanged metadata to Vorbis Comments, but that was a long, long time ago. The CONTENT GROUP part is the only recent addition here.
I suppose the remapping for Vorbis Comments (also affects FLAC/Opus/etc) can cause more annoyance than benefit for some, However, there is a switch in advanced preferences (under Tagging) to suppress the remappings beyond the PUBLISHER/ORGANIZATION line, then you get (nearly) untouched passthrough. Only the switch needs renaming to mention CONTENT GROUP / GROUPING, which I am going to fix now.
Microsoft Windows: We can't script here, this is bat country.

Re: %CONTENT GROUP% mapping error

Reply #31
However, there is a switch in advanced preferences (under Tagging) to suppress the remappings beyond the PUBLISHER/ORGANIZATION line, then you get (nearly) untouched passthrough.

With both settings in this switch ("more compatible with various software" / "compatible with old fb2k versions") new metadata filled in the "GROUPING" field are still written to the "CONTENT GROUP" field only. No chance to add metadata to GROUPING.

Re: %CONTENT GROUP% mapping error

Reply #32
If you write a tag field called GROUPING with foobar's properties dialog that will get written to the file regardless of the Content Group tag mapping setting. But when it's read back foobar2000 will use its internal mapping to show it as "Content Group". This is done for all standard fields so their values can be displayed with a single titleformat field. Instead of $if2(%content group%, %grouping%) you can use just %content group%.

Re: %CONTENT GROUP% mapping error

Reply #33
My problem is, however, that all existing metadata entries under "GROUPING" are still displayed under the standard field "GROUPING", whereas new entries which I submit under my standard field "GROUPING" are only rewritten to "CONTENT GROUP". The "GROUPING" field remains empty for these new entries. Also, any changes in the "GROUPING" metadata are only saved under "CONTENT GROUP", clearing the "GROUPING" field. This would lead to quite a mess, so I think about transferring all "GROUPING" metdata to "CONTENT GROUP" via masstagger. But I would do this only if the remapping decision is final, and there is no other way to keep the GROUPING field as it is.

Re: %CONTENT GROUP% mapping error

Reply #34
This is done for all standard fields so their values can be displayed with a single titleformat field. Instead of $if2(%content group%, %grouping%) you can use just %content group%.
This is done for select few fields, not all standard fields. With the new mapping you now must use $if(), where you didn't before, because a mixture of Grouping and Content Group now exist. Select a set of FLAC/WavPack files, add Grouping, two fields appear instead of one. This obscure field is promoted to a standard, but only half-way because Apev2 isn't affected. This new mapping is in no way "compatible with old foobar2000 versions", because the mapping didn't exist until the current version.

I shall avoid using this field entirely. It seems to serve two incompatible purposes: grouping a set of tracks under a common title, and specifying a genre of the "content". In the wild I have only observed the genre usage. For track grouping I will use "Set Subtitle", and continue writing genre/style into multi-value "Genre". Maybe classical listeners can use "Work", but I don't know. Most imporantly Work stays Work when converting between FLAC/WavPack/TAK formats.

Re: %CONTENT GROUP% mapping error

Reply #35
In fact, I labelled my "GROUPING" field "Work", but thougt that "GROUPING" was the correct metadata name... - just decided to move all GROUPING entries to new field "WORK" - hoping no one will ever have the idea of remapping this field, too. So I'm off the GROUPING/CONTENT GROUP topic. Thanks for discussing things!

Re: %CONTENT GROUP% mapping error

Reply #36
Quote
These are the fields currently remapped between fb2k (former) and Vorbis Comments (latter). At some point of time foobar2000 did pass unchanged metadata to Vorbis Comments, but that was a long, long time ago. The CONTENT GROUP part is the only recent addition here.

Ah, thanks for clarifying. I didn't know that. Sorry for misinformation. It's been a while since I checked that. Actually, the support for "unchanged vorbis comments" was one of the reasons, why I once decided to use foobar, a long, long time ago...  ;)

Anyway, that doesn't change my issue, that a mapping of the different tags to %grouping% seems to be a better solution.
I've been into this tagging business for decades now, evaluating and checking behaviour of dozens of different software. And believe me, nearly all software translates TIT1 to grouping and not to content group.

Here just some examples: iTunes shows this field as grouping. Mediamonkey calls it Grouping. MusicBee calls it grouping. JRiver calls this field Grouping. And also Tag & Rename shows this field as Grouping... I deleted WinAmp from my system, so I couldn't check that, but I remember it mapping to grouping, too...

Solely MP3tag maps the tags of MP3/MP4/WMA to CONTENTGROUP, whereas APE and Vorbis are not mapped by this software and appear "unchanged" as GROUPING, or whatever you'll call them.

The term Content group description is a very abstract term that stems from the ID3tag documentation for the description of the TIT1 field. It is the first and highest level of title information that names a group of more than one files. The abbreviation Content group misses the information that it's about title naming (i.e. description), and therefore leads to misinterpretations. By the way, in this document also the TIT2 field is abstractly called Content description, but most software translates to Title. And the TIT3 field is named Decription Refinement, that most software maps to Subtitle. This ID3tag documentation is full of highly-abstract and horrible wording.

Moreover %grouping% is shorter, which I'd prefer to use in titleformatting scripts. And %grouping% would match directly with the spelling of the corresponding Vorbis comments and APE tags.

Maybe, I am biased in my thinking, but I can't think of any argument, why this variable should be called %content group%.

To my eyes and my personal taste, %grouping% is much more clear, comprehensive, practicable, standard, elegant and beautiful than %content group%. It matches the naming in other software and the spelling of Vorbis and APE tags, and therefore is the way to go.

I appreciate the mapping of this field in foobar. This field has been disregarded by most of the music software for a long time. Classical music lovers are able to tell a thing or two about this issue. And I can also live with the %content group% solution. But if I were asked to carefully select a variable name for this field, I would choose %grouping%.

Re: %CONTENT GROUP% mapping error

Reply #37
With the new mapping you now must use $if(), where you didn't before, because a mixture of Grouping and Content Group now exist. Select a set of FLAC/WavPack files, add Grouping, two fields appear instead of one. This obscure field is promoted to a standard, but only half-way because Apev2 isn't affected. This new mapping is in no way "compatible with old foobar2000 versions", because the mapping didn't exist until the current version.

This problem would be solved, if all tags are mapped to %grouping% instead of %content group%.
Mapping to %grouping% may even reduce coding effort, because remapping of Vorbis, APE, WavPack etc. would be unnecessary. The tags of MP3, M4A and WMA have to be mapped anyway.

Re: %CONTENT GROUP% mapping error

Reply #38
@infinci
I try to give you a logical explanation...
Thank you for your really interesting and valuable explanation. It seems to be right story. Unfortunately, 1. not fully right; 2. it only affects the surface, not the deep waves. As a result, what appears to be true, in the end became false. Half-truths are dangerous things, they deceive people.

Explanation little later, I am busy now.

So, let us go.

thomian wrote: "Unfortunately the term "content group" is a bit misleading and the description in the documentation is not very well comprehensible, too..." Exactly. On such an important question, I am sure, the fog is not a coincidence. It absolutly would not be difficult to write it simply, clearly: TIT1 is symphony, TIT2 is part 1, part 2, part 3, part 4. As thomian wrote. Instead, they continue to increase the fog. On the http://id3.org/id3v2.4.0-frames website they are talking about a category, not about a work (opus), as a part holder. The two are: heaven and earth, quite different. Category: similar things based on a criterion. Apple in Europe and banana in Africa, 2000 kilometers: one category - fruit. BUT THEY ARE NOT PARTS OF ONE, OF THE SAME WORK, SAME PART HOLDER. It would be: two apples on the same tree, stacked next to each other. The tree is the the WORK, the PART HOLDER.
Indeed! I shall go further. For about 20 years, I began to organize and listen to my music with billgates' windows media player. I am sure, this was the case for, at least, 50% of people. Rather, probably 80-90%. So, this is exactly authoritative. Now I do not want to have this program even for a minute on my PC, but I have been running a .xls file for a long time, for important music data, including, of course, tags. I have been writing in the past: "WMP, TIT1: Music category description". "CATEGORY" IS NOT "PART HOLDER"! Previous WMP (8?), comments in native for me hungarian: "WMP fejléc: Alműfaj. WMP címkeszerkesztő: Alműfaj." In english, about: "WMP header: Subtype. WMP label editor: Subtype".
I am going further. We must not forget: when someone starts to organize and listen his music on a computer, he will not look at id3.org's homepage. May be, he did not even hear about it in all his life. He will look at descriptions, names, and help of his player application -- WMP in our case.


Summarizing: perfectly clear, billgates told us, that the TIT1 = Music CATEGORY. AND I USED IT THIS WAY IN LAST ~20 YEARS. Please, do not tell me: billgates and id3.org did not heard about each other. Do not tell me: billgates has nothing to do with these tags. Do not tell me, that I made a mistake, and 20 years ago I should not have read the description of the WMP, but I should have telephoned all kinds of offices for different standards, and read tons of technical papers about the tags and other technical things of musical ART.

Well, that is all about TIT1 (CONTENT GROUP).

Following. Today, xiph.org says something else about this, it recommends something else. What is xiph.org? Did they make FLAC? No -- Josh Coalson did it. But today somehow the xiph.org guys have it. Did they write the best music player? No - Peter Pawlowski wrote it. Did they make the Vorbis Comments tag standard? I do not know - it does not matter. 8 year old girl can do it. "Flora, dear, come to the board! How do you describe the second white bread on the shelf? Uncle teacher, like: <TITLE> = bread, <TRACKNUMBER> = 2, <COLOR> = white." Add this simple TXT- or CSV-like info to the beginning of the music file - even I do it. This is not the discovery of DNA. This is just a standard - for which xiph.org has placed its hand now. If I do not dance, as they whistle, then it is "abuse", and it "will be discouraged". (Yet without guns, I hope...) Tomorrow they might even want to say, how to put my back side on the toilet seat.

Next. I want to listen to music. What am I beginning to wonder about? What is its barcode? Who released the disc? Who mixed it? The publisher's website? Who was the first performer? NO. I am going to think about: viennese classic, or romantic? Symphony, or piano concerto? Or swing, reggae, Elvis? BUT THE ABOVE ONES HAVE THEIR TAGS - THESE ONES HAVE NOT. Symphony, concerto, chamber music or solo: NO TAG for these, FIRST LEVEL IMPORTANT categories. Beethoven, Mozart, Tchaikovsky, Grieg, Schumann: genre is "classical". Or "oldies". Indeed, "others". As a shit in the corner. But if two guys drop the drum in the neighboring garage, there are 170 genres: Acid breaks, Bakersfield sound, Cakewalk, and so on, and so on, and so on. (Id3, and the follower Vorbis Comment guys opinion...)

IS THIS CATEGORIZATION MUSIC FRIENDLY, WORTHY OF HUMAN BEING? MUST WE FOLLOW THESE GUYS? The answer is clear.

Well, that is all about xiph.org's recommendations.

Next. Of course, there is a need for a tag, that combines the 4 parts of a symphony. Billgates, see above, has said it consistently: TIT1 is not for this purposes. Good. Now, what is it: CD? What is it: album? Constraints - technical parameters. 40-60 minutes rooms on a vinyl LP. On a shellac: less. On a CD: 80 minutes. On the internet: 20 billion or more. At the age of Beethoven, the technical parameter was: how long can a listener sit in the same place without bothering him. That is, why a symphony is 40-50 minutes. That is, why 1.5-2 hours are operas - but with breaks.

So I decided, perfectly reasonably, that I adapt my decisions in music art not to technical characteristics of shellac, viny, CD, but rather to art itself. That is why I am not interested in, or more precisely, not just, what the publisher packed on a disc. For me: a symphony is an album. A piano concert: an album. Vivaldi, 4 seasons: 4 albums (because opus 8 contains 12 works). And I have been using such tag system for 20 years without any big problems.

But today some guys want to say me, that I am stupid, and I must to use TIT1 in absolutely other way...
And I must to rewrite all of my ~300 foobar autoplaylist, because nearly all of them use the first level important tag CONTENT GROUP. But these guys do not plan to pay for my ~1 day work...

By the way, dear Peter -- again, a hundred time written suggestion :D : human readable and editable autoplaylistes in separate files will be sooo nice...

Re: %CONTENT GROUP% mapping error

Reply #39
But today some guys want to say me, that I am stupid, and I must to use TIT1 in absolutely other way...
Nem hiszem, hogy hülye vagy. Thanks for your detailed explanation. I can follow your thoughts. Sorry, I did not want to offend you.
To my knowledge, both, the Windows Media Player and Microsoft Groove, never supported the grouping tag. I don't think, that these players could be authoritative for this issue. Not only at Microsoft, but most software developers never realized, that some music needs a more differentiated description, than just "Artist - Song". For classical music you have to distinguish between performers and composers, between ensembles, conductors, singers and soloists. And Title description includes work and movement and for large-scale works like an opera even subsections like acts. Furthermore the opus number, and other stuff. At least four tags are essential for classical music: artist, composer, grouping & title. You have different but comparable problems with jazz music etc... The ID3tag consortium adressed all these issues by providing at least three tags for Title naming TIT1, TIT2, TIT3 and three tags for Artist names TPE1, TPE2, TPE3, which was a usable solution for nearly all cases. Unfortunately software developers never gave full support for these fields and focused on "artist" and "song". Instead they even misused some of these fields for other purposes. For example, the ID3tag consortium did not provide a field for the "album artist", so people startet to put this information into the TPE2 field, which originally was meant to hold the name of the band, orchestra or ensemble involved. foobar denied to participate in this "misuse" for a long time and mapped this field to %band% instead of %album artist%. But that's another story... For genre information the ID3tag documentation provided the TCON field, that was named "content type". No mention about genre. This about foggy descriptions of ID3tags... It's a string variable and may hold any user-defined genre, subgenre or music type of this planet.

But again... I don't want to argue, how to use the grouping field "correctly". People are free to fill it with the information they need. No need to change anything.

I just argue that %grouping% would be a better field name than %content group%, as it is more standard and practicable as explained in my previous posts. Hope that this will be fixed.

Re: %CONTENT GROUP% mapping error

Reply #40
Nem hiszem...
Misunderstanding -- it was addressed not to you. Sorry.

I understood you. But today millions of foobar users, because of Id3 fog, use TIT1 for very, much more important purpose: really, as written, as musical category -- symphonic, concerto, chamber or solo. You argue with some technical needs, and force to remove this chance from us. Do you plan to give us some as strong, as TIT1, in exchange? Not some TXXX one and its Vorbis Comments pair, but some exactly so strong and populated one. NO. You only remove, once forever, from us and all future users.

You forget: tags and programs and standards must serve music. Not inversely.

Re: %CONTENT GROUP% mapping error

Reply #41
No, you misunderstood my request. I don't want to convince you, how to use the TIT1 field. You might use it in the same way as you used it before and fill it with musical categories. You'll keep the TIT1 field for your purpose. Nothing will be removed. Mapping this field to %grouping% wouldn't force you to anything. Just the internal name in foobar changes, not the function. And with the "properties dialogue settings" you could even rename it to "musical category" or whatever you like.

The following Tags are already mapped to each other:
Vorbis: GROUPING
APE: Grouping
ID3tag: TIT1
iTunes MP4: ©grp
WMA: WM/ContentGroupDescription

I just argue, to map these tags to foobars %grouping% variable instead of %content group%. The only thing that would change is, that the mapped tags by default would be displayed as GROUPING instead of CONTENT GROUP. This is how it shows up in all other music players (see my post above). It thus will meet standards, it will be shorter to type in title formatting scripts, it will match the names of the corresponding Vorbis and APE fields, it will reduce coding for implementation, it will prevent confusing Vorbis and APE users... And this is why it seems a more elegant solution to me.

Re: %CONTENT GROUP% mapping error

Reply #42
I understood you exactly in this way. You argue for conformity and (from this aspect seems) logical solution.

And yes, this is exactly, what I am against. Because words have power. I know, I can use any system, any tags. I speak for values of human culture. This is more important, than technical conformity. By using the name CONTENT GROUP as more time, as we can, X time 10% of people will remember about TIT1 Id3's fog, about this tag: "Oh, yes, this is about... how is... oh, yes! remember! symphonic, concerto and so on". AND THEY WILL USE IT IN THIS WAY. Who does not use a tag about these important categories, he earlier or later, but simply forget about it. In 21st century, tag system has BIG influence to people musical intelligence. knowledge. If they have not explicit word CONTENT GROUP*, so they forget EARLIER, EASIER about this important category type. The way, how you think, depends on your instrument for thinking: your language. There are people in Amazonia, native tribes, who can not calculate more than 1, 2 and 3. They even can not say, what of my hands, left or right has more stones, if stones are more than ~5-6! After antropologistes gave them the worlds (numbers), they COULD learn to calculate. Without words they even could not imagine, what number, more than 3, are.

(* Yes, will be much better any more exact, WORK CATEGORY or so. But we have content group now -- anyway better from this point of wiev, then simply grouping.)

I myself is a very precious man. I like all to be in logical order, mostly in my PC. All the while, until it will not against human culture, as in this particular case. Starting from this point, for me is absolutely indifferent the technically logical order. Culture is much more important. And this is not meaning, I am against logics. How could I? I only much mor, in our case, for CONTENT, MUSICAL LOGICS, than technical. Because much more important.

This was the meaning of my words: you forget: tags and programs and standards must serve music. Not inversely.

Humanity is going exactly on the way of degradation. Every new generation is more stupid than earlier. Most of destruction of human values were "unfolded" with some technical type "needs". I do not want to live in the world, were some idiotically stupid so called music has 1.5 billion wievers on youtube -- and half or more of them never in the life heard Appassionata. EVERY step to this hell is important, will it executed or not.

Re: %CONTENT GROUP% mapping error

Reply #43
Ah no... sorry... To interpret this as an affront to "human culture" is ridiculous. Why should "musical category" be more important to human culture, than the correct naming of "classical works" of world cultural heritage? I didn't catch that. In fact, there are a lot of people, who are not aware, that the Apassionata has three movements, and that Beethoven does not play the piano on the recording. This (!) is a matter of importance for human culture and for musical education, but not the categorization of music files on your hard disc. The correct tagging of works, movements, composers and performers might be more important to human culture than the tagging of musical categories.

The whole world calls this field "grouping", except foobar. It seems to me, that you try to convince the rest of world, that the grouping field better should be named "content group", because it should be used as "musical category" to serve the music and save human culture. Just give me logical arguments, besides your personal feelings.

Yes it's true. This field is in use for different purpose. There are a lot of people that use the grouping field for "works" (besides the fact that their software calls it "grouping"). And there are a lot of people using it for "musical categories" (besides the fact that their software calls it "grouping"). And there is no problem. Forcing people to use the album tag for "work" and to use the grouping tag for "musical category" is not a solution.

Re: %CONTENT GROUP% mapping error

Reply #44
Ah so...

I understood, why do you ignore consistently the elementary rules of discussions.
So that is all from me. I am on the human side.

Re: %CONTENT GROUP% mapping error

Reply #45
Sorry, if I hurt your feelings. I didn't want that. I will calm down and share you on the human side...
I will now listen to Beethoven's Appassionata instead. Thank you for bringing this to my mind. Maybe you want to share me with this idea.

Re: %CONTENT GROUP% mapping error

Reply #46
Not sure this was posted anywhere but checking foobar2000 change log mentions -

Quote
1.3.20
This is a maintenance update, contains only bug fixes backported from 1.4 series.

  • Reverted the much criticized CONTENT GROUP vs GROUPING remapping for FLAC/Vorbis.
  • GROUPING field name is now used for ID3v2 TIT1, M4A ©grp, etc.

Cheers 8)

(I had already planned to continue using GROUPING although I use external tags which bypasses tag mapping anyway but there you go)