getmusicbee.com
Support => Bug Reports => Topic started by: Boll Weevil on November 01, 2021, 06:49:57 PM
-
Hi!
While editing tags I noticed a very strange behavior. When I save edited tags, it also writes an unwanted tag ENCODER (TSSE). See screenshots. Maybe it's not a problem but as for me it is absolutely unnecessary and I spent a lot of time to clean my library from all garbage tags. Maybe it can be turned off somewhere, but I can't find where and how. And by the way, the encoder is wrong, actually it is LAME 3.100
And the second. When the tags are saved, by some reason multi-value fields are split in the way as you can see on screenshots. Again, for MB it is not a problem ad it still handles them correctly, but other software (MediaInfo, AIMP) only recognizes the first value (Rockabilly). TagScanner still recognizes both values and resaving tags with it can fix it and all values reappear in other software.
I don't use MB tag editor often, but from time to time I do, and now I don't have an idea how many files are affected and how to locate and fix them
(https://i116.fastpic.org/big/2021/1101/99/82d1760c2200655d6e739b1f95355699.png)(https://i116.fastpic.org/big/2021/1101/6e/da9780c2d86526c576b580e5ff7ae36e.png)
-
The encoder tag is written by the encoder.
The multi value tags are actually multiple tags (multiple genre tags in your example) within the file, and are being displayed correctly here. They are shown concatenated in the simple display.
-
If I am not mistaken, most mp3 encoders will write the encoder info in the header of the file itself.
You could use a hex editor to open the mp3 files and check what is in the header of these files.
MusicBee probably reads that info from the file and writes it to a tag so to make it a manageable tag field.
Which makes sense to me.
If I understand you correctly, you believe it should say 3.100 instead of 3.10 ?
If that's the case, you could post a wish for MB not to truncate such values to two digits behind the comma.
About the genre tag:
How were these genres added to these files in the first place?
It seems like it could be a matter of the separator being a semicolon only, while they should be a semicolon+space.
( '; ' instead of ';' )
edit, pressing 'post' alerts me that somebody answered already.
I'm in a lazy kind of mood and will press 'post' anyway ;-)
-
The encoder tag is written by the encoder.
The LAME tag has nothing with metadata, it is just a technical info and shouldn't be treated as a tag. At least until a user intentionally saves it as a ENCODER to metadata. Here it is written by MB tag editor, I'm 100% sure about it, because it wasn't there before I saved tags.
The multi value tags are actually multiple tags (multiple genre tags in your example) within the file, and are being displayed correctly here.
I believe it is only true to MB, because they don't display correctly in other players after the file have been edited by MB.
If I am not mistaken, most mp3 encoders will write the encoder info in the header of the file itself.
Yes, you're right, it is written in header and it is not editable and it should not be editable, since it is technical data. It should not be treated as an editable tag by tag editor unless user willingly fills ENCODER tag according to the data taken from header. I consider it useless, so I don't use ENCODER tag in my files.
If I understand you correctly, you believe it should say 3.100 instead of 3.10 ?
If that's the case, you could post a wish for MB not to truncate such values to two digits behind the comma.
In fact I don't want to see it at all among the tags in my files, but since it is displayed as a tag, well, let it be displayed correctly))
About the genre tag:
How were these genres added to these files in the first place?
It seems like it could be a matter of the separator being a semicolon only, while they should be a semicolon+space.
( '; ' instead of ';' )
It doesn't matter, semicolon only, or semicolon+space - the result is the same, only the first value appears in mentioned external apps. I just checked
-
If I am not mistaken, most mp3 encoders will write the encoder info in the header of the file itself.
Yes, you're right, it is written in header and it is not editable and it should not be editable, since it is technical data. It should not be treated as an editable tag by tag editor unless user willingly fills ENCODER tag according to the data taken from header. I consider it useless, so I don't use ENCODER tag in my files.
For many users (such as me) it is convenient that MusicBee distills this info from files and makes it available as a tag field.
Since you are bringing this up in 'bugs', what do you believe to be the bug exactly?
-
How were these genres added to these files in the first place?
It seems like it could be a matter of the separator being a semicolon only, while they should be a semicolon+space.
( '; ' instead of ';' )
It doesn't matter, semicolon only, or semicolon+space - the result is the same, only the first value appears in mentioned external apps. I just checked
I see I am not the first one that observed this separator issue with your files:
https://getmusicbee.com/forum/index.php?topic=4451.msg185972#msg185972
Since you didn't answer the question how you are populating these tags in the first place, and this specific problem hasn't been raised before by anybody before, I can only estimate that the issue is on your side, and not related to something MB is doing wrong.
So unless you can provide detailed specifics, there is not much you are providing here that warrants this to be investigated as being a bug.
-
I see I am not the first one that observed this separator issue with your files
It is not an issue. The case that you mentioned was actually a bug and was fixed in the then next update. I never had any problems with tags separated with ";" only and they were handled correctly. Separator is ";" and using it with or without space is just a personal preference and it won't affect anything.
As for how I populate my tags, I think it doesn't matter as I use standard tag fields for all values, including genre(s). In the last couple of years I do it mostly with TagScanner, before my main tagging tool was Tag&Rename, and the most part of my library is tagged with it mostly manually, some part using Discogs and then fixed manually to meet my tagging preferences. That example file above also was tagged manually in TagScanner, then I just found and fixed a typo in MB and mentioned strange intervention into tags that I didn't edit.
Honestly I don't think that it matters how I populate my tags, I just don't want my tagger to add or remove particular tags without my permission. Neither I want my tagger to change some tags in the way that may seem useful for somebody.
For many users (such as me) it is convenient that MusicBee distills this info from files and makes it available as a tag field.
I don't have anything against making it available, I'm against making it obligatory.
-
I agree that the repopulation of the encoder tag is an annoyance, if probably not really a bug.
The multi value issue sounds like the difference between treating the tag as a single string vs actual multiple values separated by a null character. MusicBee displays the semicolon but once it has processed a multi value tag, the semicolon doesn't exist in the tag anymore, it's just a human-readable stand-in for display purposes. Not all software correctly reads multi value tags and will just stop at the first null separator.
-
The multi value issue sounds like the difference between treating the tag as a single string vs actual multiple values separated by a null character. MusicBee displays the semicolon but once it has processed a multi value tag, the semicolon doesn't exist in the tag anymore, it's just a human-readable stand-in for display purposes. Not all software correctly reads multi value tags and will just stop at the first null separator.
Thank you for that explanation, I supposed that, but why MB doesn't leave multi valued tags as they are, I mean as a simple string where semicolon is semicolon and not just a viewable stand-in for something that just MB can understand. When I was just starting to use MB I just imported all my library, where all tags were populated in various tag editors. All semicolon-separated tags were imported unchanged and handled correctly, and I could still operate with them in other software.
By the way, I noticed that PUBLISHER tag with multiple values still stored as a simple string after saving it by MB
-
MusicBee is following the ID3 standard for tagging.
PUBLISHER (TPUB) is only supposed to be a single tag with a list of publishers.
GENRE (TCON) is supposed to be a multiple-entry tag with each value separated by a null frame.
-
MusicBee is following the ID3 standard for tagging.
PUBLISHER (TPUB) is only supposed to be a single tag with a list of publishers.
GENRE (TCON) is supposed to be a multiple-entry tag with each value separated by a null frame.
Hello, I believe if we are using ID3 2.3 (which I am) MusicBee should NOT be saving with the NULL \\ backslashes.
In fact, this is also causing me a serious problem, because Mp3tag and MusicBrainz Picard DO NOT do what MusicBee is doing, and it's causing me all kinds of issues with displaying Genre tags in various places, in the programs themselves, etc. It's how I ended up confused as heck as to what Tag Separators I should be using, and after some 100 hours of testing with all the different programs and tag variations, and questions on the subject at different forums, everyone said the SEMI-COLON was the most consistent and compatible separator to use.
.... and they were correct, including display in MusicBee. More specifically, I do the Semi-Colon for all my general tags, and for Multi-Genres and Multi-Artists I do Semi-Colon and Space.
MusicBee interprets this well...
If I try to put \\ on my Genres in the different programs, NIGHTMARE's ensue in those not displaying well.
Mp3tag WILL create multi-Genre/Artist Tags if you within the program use \\'s.... and save, But you're doing a "manual" bypass then.
Using the Semi-Colon or a few other things Mp3tag WILL save using those Separators, it will NOT "override" what you've put in the Tag like MusicBee is doing, saving the backslashes instead as separators. Neither will Picard. Picard unlike Mp3tag won't even create multi-tags if you save with backslashes... It will all just be ONE Genre etc. tag text as entered.
Bottom line, this IS a BUG in MusicBee.... When ID3 2.3 editing is done, the program should ONLY be saving what we put in there and under ONE Tag.
I've noticed MusicBee doesn't do this for OTHER Tags also... such as Artist, the \\ backslashes are put in there on Save. This should not happen.
So, this needs to be fixed ASAP... 2.4 is what's properly compatible with Multi-Tags... not 2.3.
BTW, I've noticed that when saving "Artwork" in MusicBee the proper saving is done, blackslashes are not added to the other tags, that I've noticed anyway.
Crap, that's wrong.... Son of a ****... So THAT is how I've noticed some files still having \\'s when I removed them all.
So, I was wrong, even when saving Artwork backslashes ARE saved, replacing likely ALL other Tag Separators. :(
The test I just did at least did so on my Artist and Genre Tags....
BTW, anyone that wants to verify what I'm saying, see here: https://community.metabrainz.org/t/multiple-artists-and-genres-as-multiple-tags/412255/4?u=leeuniverse (https://community.metabrainz.org/t/multiple-artists-and-genres-as-multiple-tags/412255/4?u=leeuniverse)
This guy is long brilliant all things Tagging etc., plus, I've verified it from experience, Picard and Mp3tag don't save with backslashes when ID3 2.3 is used. They ONLY save what you've used as a separator.
-
Thank you for that explanation, I supposed that, but why MB doesn't leave multi valued tags as they are, I mean as a simple string where semicolon is semicolon and not just a viewable stand-in for something that just MB can understand.
Because this (i.e. the NUL character as separator [which admittedly is difficult to deal with in a non-programmatical context or as someone who does not deal with text formatting on a programming level regularly.... i.e. hardly any of us... and I had to spent dozens/hundreds of hours to understand this mess a bit better as well....]) is the official separator as per the id3 file specs!
everyone said the SEMI-COLON was the most consistent and compatible separator to use.
But then you would be NOT using the officiall sanctioned separator for id3 2.4... ? :P
So, this needs to be fixed ASAP... 2.4 is what's properly compatible with Multi-Tags... not 2.3.
No it doesn't [imo]!
id3 2.3 has had NO definition of an official multi-value tag separator [and for this you're expecting Stephen/Musicbee to expose yet another customizable separator...?]
For id3 2.4 it was decided that multi-value is now supported, and the official separator is a NUL.
But afaik (and I would love to know if this is not true, or what the details were) nothing changed in the encoding of the fields itself.
So the Picard way is the super-correct way to handle this. i.e. to not support multi-value metadata on id2.3. at all... [but to leave it up to the user to inject custom separators that aren't a NUL...1]
BUT - and this is a big but... then you have a mixture of 2.3 & 2.4 metadata separators on your files (and not everyone is super savy about the finer details, and who can blame anyone with the mess... ). So what the Picard way means is not having multi-value at all on 2.3 at all, or forcing a literal ; instead of a NUL into your files, ending up with a mix of separators across not only container formats, but also versions of the same container format.... which sounds much worse to me than having NULs consistently!
My interpretation is that Stephen decided to allow, the later officially declared, NUL character separator for all id3 versions, and I'd fully agree for convenience & consistency - and I have not found a technical issue with this even though I have a multitude of other programs consume the consistently NUL separated metadata on id3 2.3 headers (written in Musicbee & Foobar as well as Traktor, Serato as well as Rekordbox [not the later 3, as none have implemented any multi-value support yet...]).
c.
-
If I try to put \\ on my Genres in the different programs, NIGHTMARE's ensue in those not displaying well.
\\ is not a null character.
Some tagging programs do recognise it as such.
MB uses "; " for human-readable form.
-
So if there is no defined standard for separator in 2.3 then I guess there should be an option for a user to decide which one to use and it should not be replaced with null by default, but only by user's permission when they are confident of what they are doing. As far as I can see after a year of active use of MB, it perfectly handles multiple values written as a simple string with a popular ";" without replacing it with null
-
So if there is no defined standard for separator in 2.3 then I guess there should be an option for a user to decide which one to use and it should not be replaced with null by default, but only by user's permission when they are confident of what they are doing.
I think you have done just enough research on this subject to follow along the terminology of the topic, but to the point where the terms are still confusing you. The below quotes are very important, but maybe a little difficult to comprehend.
The multi value tags are actually multiple tags (multiple genre tags in your example) within the file, and are being displayed correctly here. They are shown concatenated in the simple display.
\\ is not a null character.
Some tagging programs do recognise it as such.
MB uses "; " for human-readable form.
As @alec.tron said, the concept of the null character can be difficult to grasp, at first. Over on the MP3TAG forum (https://community.mp3tag.de/t/multiple-artist-tags/6246), I found what I believe to be a good thread for explaining the multiple value process as it relates to music tagging software and hopefully it'll clear some things up regarding the topic.
In particular...
Representation of the separator and the actual character sequence used are two different things. If you want the sequence to be entered from the keyboard, then the separator needs to be some common character(s). There's no reason, I suppose, why it couldn't be represented in some special way - bold or bright red, say. But that would take some additional real-time parsing of the field while the user enters characters, whereas the current implementation only has to parse the field when it's saved.
You're right that it's possible to have literal content that is indistinguishable from the special character sequence, but the question remains whether the sequence chosen presents a problem. I don't see why it should.
Long story short...
As far as I can see after a year of active use of MB, it perfectly handles multiple values written as a simple string with a popular ";" without replacing it with null
...the semi-colon used in a multiple value-capable field in MusicBee is the "representation of the separator." It is not the "actual character sequence." Computers cannot read input as a human does. A computer does not know what an "A" is. A computer does know what ";" is. A computer does not know what "null" is. How does a computer read input then? Using numbers. (https://www.asciitable.com/) A computer reads ";" in this Simple Machines Forum comment as 59. But, in a multi-value field in MusicBee, the ";" is not read as 59. Instead, it is read as 0.
-
The Incredible Boom Boom said it perfectly. MusicBee does not handle this in a controversial or even disputed way.
-
I understood it already, but nevertheless thanks for efforts. You gave a good link to Mp3tag's forum thread very good and useful indeed, because it shows that if a user wants a null separator, they enters a null separator (\\). Wants semicolon - enters semicolon. But you didn't explain why Mp3tag do saves saves tags as they were typed by the user while MB replaces actual character with null without a permission.
Here's a Mp3tag's window with just tagged file. Note "Country; Rockabilly" in GENRE tag. This is exactly what I typed on keyboard. All values saved s a simple string and a semicolon is just a semicolon.
(https://i116.fastpic.org/big/2021/1104/5c/7abb925fccbe722e414f2f8b685c665c.png)
Here I open it in MusicBee, make sure the tags are exactly the same, and just save it without any edit
(https://i116.fastpic.org/big/2021/1104/8e/eed364ad7833cfba79f9a7a18089cf8e.png)
(https://i116.fastpic.org/big/2021/1104/b7/1f43492a42dc65b9b635b2f129e9c2b7.png)
Let's see what happened
(https://i116.fastpic.org/big/2021/1104/f0/7d416b21af4b1a2d510c9f28c29d8ef0.png)
Lame 3.97
Well, that's not the point, but nevertheless, it is annoying.
There is a more disturbing thing. Where is my semicolon? Maybe it will return in Mp3tag?
No, it didn't. \\ null placeholder instead
(https://i116.fastpic.org/big/2021/1104/e4/3274cc9d3d3b77c646546a9d6c4dabe4.png)
What about media info? And maybe tags in another player?
(https://i116.fastpic.org/big/2021/1104/09/39729583d1ad576c93631bac3ef30509.png)
(https://i116.fastpic.org/big/2021/1104/af/79b5d99e27238afaacf84770fa5b6daf.png)
Maybe it could be fixed?
Yes it could. Just manually replace \\ null placeholder by beloved semicolon and voila it is a simple string again that could be processed by ANY media software, not just MusicBee, Foobar2000 and some.
(https://i116.fastpic.org/big/2021/1104/c0/f54aa0289e4c3d5328f73478bbc4c8c0.png)
(https://i116.fastpic.org/big/2021/1104/fb/78579f40a7baaa64fc44cea0ba0612fb.png)
The only problem is you can't do that using MusicBee tag editor, it would replace any semicolon that it would be able to find in tags by null, and there is no option to turn it off. I don't know a tag editing software with such behavior. TagScanner, Mp3Tag, Tag&Rename, foobar2000, dBpoweramp, AIMP, MusicBee - none of these never unexpectedly modify tags in my files by replacing any characters. Only MB does.
In other hand, when adding new files to library MB correctly recognizes every semicolon in tags and treats it as a separator without modifying tag. It would be great if all the nulls remained virtual and stored just in MB database, not affecting real files on saving.
Also I should say that I don't have anything against null separator. I don't argue the fact that MB handles it in ultimate undisputed way. "a controversial or even disputed" is that fact that MB changes tags without permission.
Please let the tags stay as they were populated by user until the user willingly allow MB to modify them. It may be a checkbox "Replace separators by null" for example, or whatever, I don't know.
I hope I finally put it straight what I'm really talking about. thank you
-
It is not changing the tag. It is updating the tag according to the instructions you're giving it through your use of the semicolon to separate values.
In other words, you are entering a character (semicolon) that is telling MusicBee to split those values into multiple values. You don't want ";" to mean that, but that's what it means.
Knowing that you don't want to split the values, and knowing that MusicBee will split the values if you enter a semicolon, why do you keep entering a semicolon? By using the semicolon here, you're not only giving Musicbee "permission" to do this, you're specifically instructing Musicbee to do this when it updates your tags.
Why not use another character that isn't reserved for a specific purpose here instead?
-
Why not use another character that isn't reserved for a specific purpose here instead?
A comma ", " would seem reasonable to me. :-\
-
I understood it already...
As I said before, you can follow the terms, but you're misunderstanding the fundamentals.
Your explanations and suggestions continue to follow a human-like train of thought, rather than a programmatic one.
There is a language disconnect occurring.
...because it shows that if a user wants a null separator, they enters a null separator (\\).
Case in point.
\\ is not a null character.
But you didn't explain why Mp3tag do saves saves tags as they were typed by the user while MB replaces actual character with null without a permission.
In lieu of repeating myself...
A computer does not know what an "A" is. A computer does know what ";" is. A computer does not know what "null" is.
Here's a Mp3tag's window with just tagged file. Note "Country; Rockabilly" in GENRE tag. This is exactly what I typed on keyboard. All values saved s a simple string and a semicolon is just a semicolon.
Repeating.
A computer reads ";" in this Simple Machines Forum comment as 59. But, in a multi-value field in MusicBee, the ";" is not read as 59. Instead, it is read as 0.
Below is human-like thinking. Computers do not process input like humans process input.
Here I open it in MusicBee, make sure the tags are exactly the same, and just save it without any edit
Let's see what happened
This is what is actually happening.
The input "Rockabilly; Rock & Roll" into a multi-value field in MusicBee is not read by a computer as "R" "o" "c" ... ";" " " "R" "o" ... "l" "l"
It is...
\u0052\u006f\u0063\u006b\u0061\u0062\u0069\u006c\u006c\u0079\u0000\u0020\u0052\u006f\u0063\u006b \u0026 \u0052\u006f\u006c\u006c
The null character is \u0000.
The semi-colon character is \u003b.
You're not inputting a semi-colon. You're inputting a null byte.
There is a more disturbing thing. Where is my semicolon? Maybe it will return in Mp3tag?
No, it didn't. \\ null placeholder instead
There is no semi-colon. You did not input a semi-colon in MusicBee. You input a null byte.
When you load the file into MP3TAG, it does not understand "Rockabilly; Rock & Roll." That is not what it reads.
MP3TAG, instead, correctly reads...
\u0052\u006f\u0063\u006b\u0061\u0062\u0069\u006c\u006c\u0079\u0000\u0020\u0052\u006f\u0063\u006b \u0026 \u0052\u006f\u006c\u006c
...and displays the split values accordingly.
Not \u003b, but \u0000.
What about media info? And maybe tags in another player?
I am unfamiliar with either of these programs, but the inability for either to correctly interpret \u0000 is a problem on their end - not MusicBee's. foobar2000 (which is considered by many to be the post-Winamp standard in influencing the direction of desktop digital audio), MP3TAG (which is considered by many to be the standard by which other digital audio tagging software are compared to) and MusicBrainz's Picard tagging program all correctly interpret the \u0000 character input by MusicBee.
Maybe it could be fixed?
Yes it could. Just manually replace \\ null placeholder by beloved semicolon and voila it is a simple string again that could be processed by ANY media software, not just MusicBee, Foobar2000 and some.
What you're asking for multiple value capability to be removed from MusicBee, so that tags can are processed as one single character sequence.
This is not a "fix," firstly, because there is no problem that needs "fix"ing and secondly, because plenty of users, including myself, rely heavily upon the multiple value capability of the software for processing Virtual Tags and the experience would greatly diminish if your suggestion to remove it were implemented.
In other hand, when adding new files to library MB correctly recognizes every semicolon in tags and treats it as a separator without modifying tag. It would be great if all the nulls remained virtual and stored just in MB database, not affecting real files on saving.
This is more human-like thinking, rather than programmatic-thinking.
In my case, the clock cycles needed for MusicBee (via the CPU) to process such an implementation would heavily increase.
I also do a lot of editing in both MP3TAG and MusicBee and your suggestion would be a nightmare scenario for working between the two programs.
Finally, the null separator is a standard for the ID3v2.4 specification and has been adopted by many digital audio software programs for other tag specs. Altering it would degrade compatibility between MusicBee and other programs. If one individual is so married to having their genre tags display as a single character sequence, rather than split into multiple values, it should be that individual who compromises by using another character, rather than asking for others to sacrifice a useful capability.
-
The bottom line with this and null \\ separators is that for ID3 2.3 MusicBee should NOT be "saving" with that Separator...
It should accept what the user uses and has entered. The multi-tag is simply not properly supported, and my experience proves that.
2.4 do what you want...
But like I said, I've done literally 100's of variations and multiple different Tag Editors, players, etc. and the ONLY thing that's "consistent" is the Semi-Colon/Space separator (; ) for Genre and Artist etc. Tags.
So, I would ask strongly for this to be changed for those who set 2.3. If you don't, I literally can't use MusicBee to EDIT anything... Which is BAD.
Most people may not care that their tags are changed from the system they use and the proper system that's compatible consistently, and viewed consistently the same across programs and devices, but some of us do.
I've waisted too many hours on this.... This NEEDS to be fixed. Thank you.
-
Why not use another character that isn't reserved for a specific purpose here instead?
A comma ", " would seem reasonable to me. :-\
A "comma" isn't used by almost ANYTHING that's modern to interpret multi-artists and to simply display properly. The Semi-Colon is the standard method.
For example, if I don't use the Semi-Colon, MusicBee doesn't show me ALL of the Artists in the Artist display.
Like I've said above, I've done 100's of variations trying to figure out the consistent separator system among programs and players, and the semi-colon is it.
Again, I'm talking about 2.3... You guys do what you want for 2.4, I'm not dealing with that yet for compatibility reasons.
BTW, and just to be clear... Finding out that MusicBee had turned all my separators into back-slashes after spending many hours and 100's of files Editing/updating of my Images while using MusicBee, because it was easy that way, to see my images, and then to copy/edit/replace them, it really pissed me off that I then had to use Mp3tag to COMBINE all those multi-tags, and replace the slashes with the semi-colon for all my files. Thank heavens Mp3tag has Actions that I can do this sort of batch editing, but I shouldn't have had to in the first place... Those using ID3 2.3 shouldn't have their separators touched. Period.
You speak of "official" things, well again, nobody else does this, and the official standard is multi-tags aren't supported with 2.3. As well those who are following the standards even more strict, such as Mp3tag, they DON'T save (replacing) your separators with slashes. The ONLY time they do so is if you have slashes there already. They respect the user's 2.3 separator usage. MusicBee is not respecting this.
Anyway, those of us who use 2.3, we need this changed for 2.3. This isn't going to "hurt" anyone else, so honestly, I don't get the pushback. We've explained all the problems it causes. This is not a "preference" thing, it's an actual issue. Nobody else does this, period, and it's for the very reasons we've explained. It causes problems.
The semi-Colon is the common standard for especially 2.3, and near-total consistency among programs, viewers, and players (that I've found so far), and I literally can't edit my files with MusicBee when that standard is being broken. Picard, Mp3tag, and others respect my 2.3 separator wishes, MusicBee is not.
-
https://getmusicbee.com/forum/index.php?topic=35720.msg195482#msg195482
This discussion should be closed or moved, because it's not a bug.
-
This discussion should be closed or moved, because it's not a bug.
I agree.
It may be a candidate for a wish. But I have doubts if a change would be an actual improvement to most users.
MusicBee is now some 12 years old (young), with an enormous amount of dedicated users having contributed by testing and providing a lot of input and suggestions.
Most of these users will (still) be using id3v2.3, and the current behaviour is very likely a result of previous experiences and requests and reports over many years.
Changing it might raise issues for other users that may have requested it to work like this.
As a guess, it could e.g. be related to compatibility with portable players, which are often a mixed bag in how they handle id3 tags.
-
The ID3v2.3 tag specification hasn't been updated in like two decades.
If you wish to continue abiding by such an archaic system, Windows Media Player 11 (http://www.oldversion.com/windows/windows-media-player-11) is easy enough to come across.
As for those of us in 2021, the main influencers in digital audio software have - thankfully - taken it upon themselves to redirect and expand beyond Jurassic-era tag guidelines, so that twenty years later, we're not still stuck with a tag specification of its time.
Since you're so set upon using ID3v2.3 exactly how it was envisioned when all of us were teens or younger, your tags that represent distinct values should be single character sequences delimited with forward slashes and not semi-colons anyway.
Finding out that MusicBee had turned all my separators into back-slashes after spending many hours and 100's of files Editing/updating of my Images while using MusicBee, because it was easy that way, to see my images, and then to copy/edit/replace them, it really pissed me off that I then had to use Mp3tag to COMBINE all those multi-tags, and replace the slashes with the semi-colon for all my files.
@Boll Weevil at least has the difficulty of English as a second language when it comes to understanding these concepts when written in English, but there should be no excuse for a native speaker. I have twice stated (and quite clearly, I believe) why his and your visual interpretation is not correct. If you have further questions, that's one thing, but this discussion cannot continue any further, because you have a fundamental misunderstanding of what you're attempting to talk about.
The entirety of your posts demonstrate you do not understand what is happening underneath the hood.
That normally would be ok, because this is subject is a complex one to comprehend, but your posts are coming across like you glossed over my detailed explanations in favor of not accepting anything other than your interpretation. Which is not correct.
MusicBee is now some 12 years old (young), with an enormous amount of dedicated users having contributed by testing and providing a lot of input and suggestions.
Most of these users will (still) be using id3v2.3, and the current behaviour is very likely a result of previous experiences and requests and reports over many years.
Changing it might raise issues for other users that may have requested it to work like this.
As a guess, it could e.g. be related to compatibility with portable players, which are often a mixed bag in how they handle id3 tags.
Precisely as I stated above. The ID3v2.3 tag specification is a fossil and should be treated as such.
-
The Incredible Boom Boom said it perfectly. MusicBee does not handle this in a controversial or even disputed way.
Clearly, that's not true per what we've addressed above... Nobody else does it... Mp3tag doesn't do it, MusicBrainz Picard doesn't do it.
Nobody else that I know of does it. And if they do, it's simply wrong... 2.3 just shouldn't be doing it per the issues I've already addressed, as well is it's not officially supported by 2.3.
-
Precisely as I stated above. The ID3v2.3 tag specification is a fossil and should be treated as such.
Are Mp3tag and Picard "fossils"...
I think THEY understand the proper methodology and standards more.
They don't "save" with the \\ when using 2.3, "forcing" those separators on their users. Maybe you should listen to our complaints, they exist for a reason.
That's my last word... It needs to change, they and everyone else I know don't do it for good reason. Neither should MusicBee.
-
Clearly, that's not true per what we've addressed above... Nobody else does it... Mp3tag doesn't do it, MusicBrainz Picard doesn't do it.
Nobody else that I know of does it. And if they do, it's simply wrong... 2.3 just shouldn't be doing it per the issues I've already addressed, as well is it's not officially supported by 2.3.
So you keep ignoring all the explanations and arguments why MusicBee is probably doing things as it is doing.
I do respect and sympathise with your struggles and efforts to get a grasp on this (for you) new technology, but to be honest, you do seem to be a slow learner.
Pretty much all experienced members agree that there is no bug at play here.
'Why' has been explained a couple of times now. Yet you are continuing to voice your personal opinion in this bug thread.
If you really believe you have something to contribute that would be of benefit to significantly more users than you, you should already have learned there is a wishlist board for that.
It has worked rather well for the last 12 years.
Create a coherent and well explained topic there, and await what comes of it.
And, a suggestion: leaving out the attitude that you are the touchstone of what is 'correct' might help your cause.
-
Clearly, that's not true per what we've addressed above... Nobody else does it... Mp3tag doesn't do it, MusicBrainz Picard doesn't do it.
Nobody else that I know of does it. And if they do, it's simply wrong... 2.3 just shouldn't be doing it per the issues I've already addressed, as well is it's not officially supported by 2.3.
Here's a fun experiment.
For the sake of everyone who comes across this thread and - like @leeuniverse - does not understand at all what the heck all this back slash, forward slash, semi-colon, null character/byte/reference/separator stuff means, please @leeuniverse, explain to us in programmatic detail what exactly MP3TAG and Picard are doing. Walk us through the steps of how the programs read user input, pass it to the processor and then direct the results to standard output. Then, please explain how MusicBee "does it," what is different and why it's "wrong."
Afterwards, I will correct you and perhaps others who are having difficulty grasping this subject will have a better handle on it (though I'm not sure you can be helped.)
-
Also, this is turning inception-esque... where I am now quoted in the mp3edit thread to explain the core functionality/spec.... :D (https://community.mp3tag.de/t/can-anyone-help-me-with-best-practice-for-tag-separators/54882/8)...
Also, in here:
https://community.metabrainz.org/t/what-is-the-reason-picard-doesnt-have-genre-settings-enabled-by-default/555038/2
is a good part:
"outsidecontext
As mentioned in another thread, Mp3Tag does not actually store a double backslash in the file, the double backslash is only how Mp3Tag displays that a tag has multiple values.
If you can use ID3v2.4, then you get proper multi-value support for tags without having to specify any separator. If you stick with ID3v2.3 use the separator that is supported by your software, both semicolon and slash are common choices. If the software does actually support multiple values. A lot of software doesn’t and only displays the tag value as is, in this case the choice of character boils down to personal preference on how you want to have it displayed."
Read both bold bits above please.
It explains everything pretty well - the NUL separator is the "separator that is supported by your software" i.e./ Musicbee for id3 2.3.
This is not a bug.
This is by design, and a favourable / agreeable one for many.
If you are hoping for more options, you need to express it as a feature-request / wish, and hope that Steven sees value & an improvement in this to implement it.
As you can see - many here do not share your wish (for a multitude of reasons, seemingly).
Me 0.02 centimes.
c.
-
Ugh...
1. Nobody is questioning the "technology" so stop engaging in strawmen, please. We are questioning an "incorrect implementation" of the technology, that is NOT standard among those who are the experts in the standard. Thus, it needs to change.
Yes, initially the OP thought it was a bug, but we now know it's not, it's actually an incorrect implementation, applying the ID3 2.4 standard to 2.3, and it's NOT supposed to be.
2. Stop engaging in personal attacks (aka Hiccup).
3. Nobody else does this, "force" the saving of the NULL (\\) backslashes on Save with ID3 2.3... Period, including the actual EXPERTS on Tag manipulation.
Logic test for you... If the experts don't do it, such as Mp3tag and MusicBrainz Picard (and others, I've tested multiple tag editors and players), what makes you think MusicBee is following the "proper standards/methodology" as you keep falsely stating?
MusicBee is the ONLY ONE doing it...! That means proper standards are NOT being followed.
Why? Because it causes issues for those of us who use 2.3, as we've shown, because it's NOT the proper standard and methodology, is not supported in 2.3.
What is so difficult to understand here?
Thanks
-
I have locked this topic - there is well explained detail to understand the concerns and the reasoning for the current implementation.
I have no plans to change the current implementation