[NOT Solved] How to make the NULL (backslashes) in Picard on Save with ID3 2.3?

The problem:
So after spending 100 hours testing some 10 different programs, editors, players, etc. finally figuring out that the “Semi-Colon” was the best separator to where I can view and edit, and I have no problems at all in ANY of them, MusicBee decides they want to be special and on SAVE with their editor they FORCE the NULL backslashes on us (multi-same-tags), replacing what we were using as separators and thus creating multi-Genre, Artist, etc. tags, instead of the One Genre tag that’s actually supported by the 2.3 standard.

Neither Picard nor Mp3tag and others will FORCE the NULL backslashes on save when using ID3 2.3, because it’s simply not supported. So, after everything was perfect finally, I discover MusicBee was doing this. And the reason this is a problem is that NOBODY ELSE does it. Mp3tag will “save what you have”, either a single Genre tag with as many entries as you want, or if you’re using NULL separators already and thus have multiple Genre Tags already, they will save it that way, but they won’t “change/replace” what we are using already. THIS is the proper methodology.

And Picard, it uses or replaces our separators with what we’ve entered to use in settings. However, if we’ve been using the NULL separator, having multiple Genre tags for instance, it deletes those and creates a single Tag, putting all entries into the single tag. This is ALSO proper methodology, because after all, ID3 2.3 doesn’t support multi-tags, so Picard combines those entries into ONE tag.

Anyway, MusicBee has decided to be the odd one out, and this has caused me MASSIVE problems… and no amount of trying to explain the problems to them that what they are doing is causing issues with both viewing and editing with EVERYTHING else out there, has been able to change their minds to change how they save separators with those who use 2.3. They think it’s the “ID3 standard” to save/replace separators with the NULL backslashes, when it’s NOT actually the standard for 2.3. It’s only supported in 2.4.

What’s Needed:
So, I’m here asking if there is a way to make Picard use the NULL separator on Save when using 2.3. Or, is this only done with 2.4 (and it is right? Picard uses the NULL separator on save when we are using 2.4)…?

If this can’t be done, then I’m completely prevented from using MusicBee’s tag, artwork, lyrics etc. editor. Thus, if I EVER want to Edit anything in MusicBee and my tags be edited and displayed properly and consistently across programs (I hope anyway) I will have to switch all my music to the 2.4 standard. Which will likely present a whole NEW host of problems between players, editors, etc. that I’ll have to figure out, which I was trying to prevent by using 2.3 in the first place, why I wasn’t using 2.4.

I was finally successful after much testing and discussion with those here and elsewhere (thanks all for the help), figuring out the semi-colon is nice, easy, and works on essentially everything, but then MusicBee decides to screw me, and unfortunately, they don’t care they are doing something that’s NOT Standard, and is screwing those like me who like to edit their tags manually and for them to be consistent.

So, what can I do here…? Am I to be forced over to the 2.4 standard?
Or is there a way to have Picard make the separators be saved as NULL, Artist and Genre separators anyway? MusicBee hasn’t applied this wrong process to other Tags that might have multiple entries, at least the Tags I use.

p.s. I can of course save with backslashes as separators in Picard, but it’s just Text only, entered into one Genre/etc. tag, it’s not actually the NULL separator that creates mutli-Genre or otherwise Tags.

Thanks all…

UPDATE…

Warning, Picard will NOT allow the creation of NULL duplicate Tags (aka Multi-tags) on ID3 2.3…
I had assumed it would with at least scripting, but it doesn’t.

You can’t use Scripts, and you can’t even EDIT the Tag manually for it to work, it forces the tags into one tag even when you try to create multi-tags.
This is actually HOW it should work, because multi-tags aren’t supported in 2.3.

However, because of MusicBee creating NULL values on Save even for 2.3, and they refuse to change the function, claiming it’s the ID3 standards when it’s NOT the standard for 2.3, I’ve been as mentioned trying to find a workaround.

So, bottom line, I’m forced to use ID3 2.4 if I want “consistency” of Tag creation between programs, or I can’t use MusicBee’s Tag Editor in ANY way if I choose to stay with 2.3, or if Picard chooses to allow multi-tag NULL creation on 2.3, which they shouldn’t have to adapt to MusicBee, MusicBee should be following the proper ID3 standards, not force saving NULL when 2.3 is being used.

So, that was a fruitless endeavor… I guess I’ll just use 2.4 for now, and if I have problems with players that I’m using, which I was trying to prevent in the first place by using 2.3, I’ll have to change something again.

Lord, I don’t understand some people… It’s NOT the standard, so WHY are people being so stubborn, unwilling to fix a problem me and some others are having, and they instead degrade us, call us names, saying “we” don’t understand, that “they” are following the standard (when they actually aren’t), etc.? :frowning:


NOT a SOLUTION for 2.3, only works in 2.4…

  1. Either use EDIT on a Tag to manually create the multi-tags by putting each value on separate lines (you can’t just edit the field itself, it won’t be automatic. ONLY the Genre tag automatically adds the mutli-values/tags null on save.)

  2. Or use these scripts for example for multi-tag generation to be automatic.

$setmulti(artist,%artist%)
$setmulti(albumartistsort,%albumartistsort%)
$setmulti(artistsort,%artistsort%)

Thanks all… :slight_smile:

If you replace the slash separator in ID3v2.3 text tags with a null byte, you effectively are already using ID3v2.4. The only additional technical difference (beyond some frame ID changes/deprecations) is that ID3v2.4 introduced UTF-8 encoding, whereas ID3v2.3 was limited to the limited character sets of ISO8859 or the older Unicode encoding UTF-16.

1 Like

How many of your players would this be a problem for? I was a hold out from v2.4 and then eventually caved in to it. True, some old Win7 PCs now can’t display the tags, but then I ain’t using them any more.

If you go over to 2.4 you can just forget about the separator puzzle completely.

How much of your kit would this actually be an issue for?

2 Likes

Ya, Elo you’re essentially correct…

So Ivan, I know some car players have issues, Windows Media Player has issues, etc. (though can’t use WMP since it actually destroys tags in the background even when you’re not using it, learned that the hard way, had to uninstall it completely to stop it.)

The real issue is I’ve just been trying to set up my files so I don’t actually have to “worry” about anything being a potential problem, I’ve seen an encountered things here and there, so I’ve just been trying to make things so I don’t have to deal with them again. Then, after a few years when more things are modernized, I can switch to 2.4.

Maybe I’m just going to have to switch ultimately… :frowning:
My only issue, is that really true that I can “forget about it”? I guess I’m just going to have to waste a bunch more time testing it out to see “how” I need to do the separators. Like, do I need to use “double slashes” from now on, etc.?

Anyway, thought I would try, guess there is no solution really, depressing that everything was finally great and working, was consistent, and now I’ve got to deal with this again. So, here we go…

Thanks for the input guys… I guess I give up. I’m honestly tired of this nightmare, from MediaMonkey actually destroying my tags, replacing them with what’s in their database without my permission, even trying to prevent it, the settings don’t actually stop it, from trying to figure out the separators, the switching between 2.4 to 2.3 and back with different programs messing things up, and now this etc., I’m just tired…

1 Like

Windows Media Player needs to be taken out back and put out of its misery. It is so old it still refers to 28.8K modem options!!

With the car players the trick I do is to use something like MP3TAG on the SD Card before I move it to the car. That can do a quick flip of the tags in bulk if needed on the copies on the SD Card. For one of my player I often need to fix anything with multiple CDs (like Audiobooks). Too many of my players don’t read the discnumber, so I have to hack the track numbers instead.

I gave up finding a “one solution fits all” option and keep my main collection in a Best State. Making sure my main media players are happy.

I understand that pain when something like MediaMonkey or MusicBee starts messing things up. It is why most of my house based media players get Read Only access to the music files on a server. That way I can restrict changes to my manual edits via Picard and MP3TAG only.

1 Like

So, I’m doing some testing with 2.4 and I can’t figure out how to add the NULL backslashes on Save for the “Artist” Tag…

So, normally I replace Wonder Woman feat. Batman with (Wonder Woman; Batman) using a Script,

$set(artist,$rreplace(%artist%, with ,; ))
$set(artist,$rreplace(%artist%, feat. ,; ))
$set(artist,$rreplace(%artist%, and ,; ))
$set(artist,$rreplace(%artist%, & ,; ))

…but it appears adding the backslashes instead won’t work in a script.
Also, when I “manual” edit the Tag adding the backslashes it doesn’t save as NULL creating multi-entries.

MusicBee also does the NULL Save on the Artist Tag, how do I get Picard to do the same?

And see, this is exactly what I knew would happen, extra complexity cause of MusicBee screwing everything up.

I’m not spending much time in contributing on fora, but this thread caught my eye, and I feel pressed to respond.

As a MusicBee user myself, I don’t think leeuniverse’s qualifications of MusicBee, and his testimony on his exchanges on their forum on this matter are fair. I also believe they are incorrect.

ID3v2.3 is not some ISO standard written in stone. It is not created by any company that dictates, protects and preserves it’s use and implementation.
And it is 23 years old.

ID3 should be seen as proposals, guidelines.
There are many implementations by many hard- and software companies that not always follow the original proposals to the letter.

MusicBee has a history of 10+ years were it’s users have continuously delivered an enormous amount of input, requests for features, and suggestions for improvements.
I know of no other software where the developer takes all suggestions into serious consideration, and when he agrees, and/or they get a lot of support from users he will implement it. Often in a few days and sometimes on the same day!

The way MusicBee handles multiple tag separators for id3v2.3 is a result of experiences and request from these dedicated and experienced users over many years.
It improves compatibility with e.g. portable music players and third party audio rendering software such as network players that uses MusicBee’s library as a source.

So indeed, MusicBee is not rigidly clinging on to a 23 year old proposal, but it has decided on a practical implementation that works well for the vast majority of users that still cling on to v2.3. (out of habit or out of ignorance)

This all has been explained to leeuniverse on the MusicBee forum.
But instead of understanding and accepting it, he keeps ranting against MusicBee, and I noticed he is now doing it on this forum.

“MusicBee decides they want to be special”
“they don’t care they are doing something that’s NOT Standard”
“MusicBee screwing everything up.”

I feel that MusicBee, Stephen (its sole developer), and its dedicated community of contributing members deserve more respect and appreciation that leeuniverse is voicing here.

3 Likes

Please get the backslashes out of your head :smiley: The backslashes are a way how MP3Tag and maybe some other tools indicate that there are multiple values for a tag (technically separated by NULL bytes in ID3).

Picard doesn’t use backslashes. The way this works in Picard is that Picard internally allows for multiple values for a tag. If you right click on a tag and select “Edit…” Picard will open the tag editor, where you can see and edit all individual values:

grafik

For display the default separator is "; ", so the above will be shown as “Wonder Woman; Batman” in the tag list.

If you want to use multi-value tags in scripting there are specific multi-value tagger script functions. The most important is probably $setmulti and maybe $getmulti. E.g. to actually set multiple values for a tag yu can use a script like this:

$setmulti(artist,Wonder Woman; Batman)

Now specifically about the artist tag: Support for actual multi value artist tag is not very great. Hence Picard by default stores the artists as a single value as credited. Picard also stores a separate tag artists (note the plural), which is a true multi-value list of all artists. Software that supports this, such as e.g. Kodi, usually use artist for display, but artists to handle showing the songs for each separate artist in the library.

If you want you can of course make the artist tag also a multi-value tag, e.g. with this script:

$setmulti(artist,%artists%)

Just be aware of the advantages and downsides. The advantage clearly is that you get separate values, and software supporting this can properly display each artist individually and show the files if you filter for that artist.

The downsides are:

  • A lot of software does not support this
  • You loose the ability to display the artist as credited (“Wonder Woman and Superman (feat. Batman)”).

IMHO having the artist as credited in the artist tag and have a separate artists multi-value variable is the more flexible approach, if supported by the software. But that’s just my opinion.

My general recommendation to everyone is, use ID3v2.4 unless some very specific issue forces you to use v2.3. If you try to prevent some yet unknown issue in the future which you might have with a software you don’t even know about it yet that’s basically an impossible endeavor.

It has been debated a lot whether we should finally switch Picard over to use v2.4 by default. The biggest argument against it was Windows not supporting this. But since Windows 10 actually does I think it’s time and we will switch defaults in one of the next releases (not 2.7, but maybe then 2.8).

As has been stated above the differences are not huge. And the ID3 implementations differ in details, because the specification is not always clear and major software sometimes just misused things for their own purpose.

5 Likes

Could you please add some links to such debates or JIRA tickets?
(I just want to be sure that all known caveats has been listed/discussed - or I can add it there).

There is this ticket:

I don’t think there is a single place that lists all known issues. The ID3 2.3 vs. 2.4 topic comes up from time to time on various places and forums. Some external discussions (although most really old):

https://getmusicbee.com/forum/index.php?topic=20536.0

The biggest argument always was “Windows / WMP does not support v2.4” (and I think also iTunes, in the past at least), and that basically ended most discussions about a sensible default. Since that argument is no longer true I think it’s time to re-evaluate this. If you have some details please add them to that ticket linked above.

4 Likes

It is unfortunate that Rai_ner would misrepresent me and what happened…

What happened is another user of MusicBee realized his separators were being changed, using the NULL value. Other users then correctly initially explained that this was a normal standard, however when that was finally understood, and I also realized that I had seen some of my files also changed, and I discovered that this was also happening to me using ID3 2.3. (I don’t remember what he was using, I think it was ID3 2.3 also.)

When we tried to explain that the NULL save value was NOT the 2.3 standard, in other words multi-values of the same Tag were NOT supported by 2.3 and for good reason, while they were claiming it was, and that this using the 2.4 Standard on 2.3 files was causing problems with consistency across programs, and that NO OTHER program does this, not Picard, not Mp3tag, etc. (i.e. forcing the NULL value on Save for 2.3) (both use what you enter as a separator, not changing your separator to NULL, the double backslash), the other longer users of MusicBee started to personally attack us, berating us claiming we “just didn’t understand the technology and standards” when in fact it was MusicBee that was using a non-supported standard for 2.3 that was designed for 2.4.

We simply reported a big problem, and we were personally attacked for it.
Note how Rai_ner has no comprehension of the issue at hand, he simply states how “wonderful” MusicBee is, which is something that NEVER was at question here. We stated a problem, they refused to fix it, so I’ve had to find other ways to fix the problem, which is why I came here to try and find an actual solution since MusicBee would not change their SAVE for 2.3 users, doing as everyone else does, saving what’s entered.

And since Picard also like everyone else (but MusicBee) doesn’t use the NULL value to save thus creating multi-values, I’m having to find a workaround, so I can actually edit in ALL of my programs, MusicBee, Mp3tag, and Picard so there aren’t issues in consistency etc.

This is nothing against MusicBee or the developer of it, unlike what Rai_ner has claimed, I love MusicBee, at least they didn’t actually delete/replace all my tags like MediaMonkey did without my permission. But, this IS a problem, and they chose not to fix it, chose to berate us for our concerns, and then chose to ignore our concerns. So I’m going elsewhere to try and get it fixed so I can edit my files between ALL 3 programs without issues.

Using the Semi-Colon separator was working perfectly, no problems editing or viewing in ALL programs, but then I find out MusicBee was changing my separator, so I voiced my concerns, and just like Rai_ner just did, instead of trying to help, just continues to berate me, being “protectionist” for MusicBee instead of addressing issues users are having.

Anyway, anyone can read for themselves what actually happened…
https://getmusicbee.com/forum/index.php?topic=35720.0
You all know me here after the last little while since I’ve been using Picard…
I have issues, ask how to fix them, you help me to fix them, I thank you, and I’ve even contributed to improving the UI of Picard as well as some bugs discovered… So, I’m NOT a problem here, I simply have a problem I’m trying to figure out as always.

So, Rai_ner is simply coming here trying to cause a “board war”, engaging in personal attacks, trying to drail my thread that’s trying to fix an ACTUAL PROBLEM I’m having… The mention of MusicBee was simply stating the context and history of my problem. Period.

Please don’t allow him to do so… Thanks.

The best way is to ignore them and not react to the post. That debate is for that other forum.

1 Like

Thanks outsidecontext… Appreciate you. :wink:

No, I understand. The reason I mention the backslashes is because when you edit in Mp3tag for example, you have to use the backslashes, or I mean at least when they been used by something, such as MusicBee, the backslashes are there so that’s how you HAVE to continue to edit them.

Ah, so I can’t Edit “within” the tag itself, I have to use the “Tag Editor”? That’s how I’ll create the NULL value for the tag?

I’ll look further over the rest of your info… I’m just trying to find “consistency” in editing and viewing, there’s no other issue here, so I appreciate your help trying to help me figure out how I can do this.

Thanks much, will let you know if I have further questions in relation to what else you’ve said… :slight_smile:

Appreciated, I won’t say anything else, I just had to clarify since he posted, and anyone else that wants to actually know can just read the thread, so I won’t respond to anyone else who’s trying to cause issues.

The fact is, MusicBee chose to use the NULL save value for 2.3, forcing the separators to be changed, when no other program does so (I know, been using all the major’s), even Mp3tag doesn’t do it, they save what you have entered as a separator. So, this presented a problem for those of us using 2.3 and the Semi-Colon separator or otherwise, they chose not to fix it.

So, I’m here to fix the problem, not to deal with peoples personal issues. I mean, I can’t use MusicBee’s Editor unless I find a solution to this. This is not complicated. So, since it seems my problem can’t be solved with 2.3, I’m now trying 2.4, trying to figure out how I can do everything needed.

I was trying to prevent all these problems with using 2.3, and I was eventually successful, but like I mentioned, MusicBee is choosing to go a different way then everyone else, so now I have to figure out how to fix this new problem/incompatability. That’s it.

Hmmm… Further looking over your code and explaination, I still need to evaluate/test the code, but the issue I was having is when you have the “feat.” for example, the Artists weren’t properly being displayed in the data.

So like Wonder Woman feat. Batman was considered an “Artist”, so to me them using the feat., and, & etc. is stupid unless they are specifically a Artist “group” like Hall & Oats. While technically 2 people, they are actually ONE. That’s their band, their group, the “Artist” of the music. So, I of course wouldn’t change those.

So, when I used the semi-colon separator ALL of the artists were seen, such as in MusicBee.
MusicBee apparently looks to the “Artist” tag to see who the artists are, not the “Artists” tag (WARNING, could be wrong in this, it’s possible the few files I tested when viewing with the Artist filter simply didn’t have multi-artists in the “Artists” tag, will have to further test. I was just trying to figure out how to properly display Artists since the “feat., & etc.” wasn’t displaying them properly.)

So, when I “display artists” instead of by Albums etc., if I wasn’t separating the Artists in the Artist Tag, whether by leaving the feat. words in, not putting the semi-colon, or just leaving the “main” Artist in the Tag, and leaving the others for the Artists tag, then only the Main Artist would show as an Artist for the song/album.

So, my separating the Artists within the Artist tag seemed like the best solution, and it worked great.
I had finally figured everything out, using 2.3, using the Semi-Colon separator, every tag, every program it all displayed properly and edited properly after 100’s of hours of downloading, editing tags, working with some 10 different editors, players, etc., but then come to find out MusicBee decides to use the NULL value on save even on 2.3, which it shouldn’t have (nobody else does), so hence my new additional problems. Was releaved to finally be done, now I almost have to start completely over.
I knew this was going to be a pain going to 2.4… ugh.

But thanks again… Will do further testing with the new info… :slight_smile:

Have you been using Picard to tag? If so you can just change the settings, reload the files, and save :+1:

2 Likes

Okay, I’ve solved the problem…

I only tested it with ID3 2.4, but the scripting should also work for 2.3.

I added these scripts into Picard and this allows “consistency” between MusicBee and Picard in the saving of Multi-value Tags, since Picard ONLY saves the GENRE Tag with the Null double slash multi-value on save. Any other tags in Picard you want to have multiples of the same tag with different values you have to use “Edit” to create the multi-value tags, by putting the values on separate lines, or use the script here for it to be automatic, because you can’t create the multi-value tags by editing in the “field” itself, like I mentioned you have to open “Edit” to do so.

$setmulti(artist,%artist%)
$setmulti(albumartistsort,%albumartistsort%)
$setmulti(artistsort,%artistsort%)

BTW, if using 2.3 you’ll want to ADD a “Genre” script similar to above since Picard of course doesn’t auto-save Genre with the Null value for 2.3, they ONLY do so for 2.4. That is if you need consistency with MusicBee since they force the NULL separator on save even when using 2.3, which they shouldn’t be and has been the entire problem.

So, this has made things work consistently between all of the primary programs I use, MusicBee, Picard, and Mp3tag, since MusicBee has chosen to save Multi-Tags NULL values for the ID3 2.3 standard also (not just 2.4) which isn’t supported by ANY player that actually requires 2.3 to display tags, so their refusal to adjust this behavior makes no sense whatsoever, and could have reduced my stress considerably.

Now I just hope players that require 2.3 will at least show the “first” Multi-value tag, and not “break” when it see’s MANY of them, or use the lesser wanted one, which is yet another reason MusicBee should have changed this behavior, since it’s NOT actually supported by the 2.3 standard, it can cause a multitude of issues, let alone the massive stress it’s caused me trying to figure a “workaround” for their stubbornness since literally NOBODY else does what they are doing, forcing NULL on save for 2.3 especially. Heck, Mp3tag doesn’t even do it on 2.4. If you have some other separator entered, they WILL NOT “override” what you have entered forcing the null multi-tag values.

Thanks all for the help, especially outsidecontext… You’ve been great.

UPDATE…

Warning, Picard will NOT allow the creation of NULL duplicate Tags (aka Multi-tags) on ID3 2.3…
I had assumed it would with at least scripting, but it doesn’t.

You can’t use Scripts, and you can’t even EDIT the Tag manually for it to work, it forces the tags into one tag even when you try to create multi-tags.
This is actually HOW it should work, because multi-tags aren’t supported in 2.3.

However, because of MusicBee creating NULL values on Save even for 2.3, and they refuse to change the function, claiming it’s the ID3 standards when it’s NOT the standard for 2.3, I’ve been as mentioned trying to find a workaround.

So, bottom line, I’m forced to use ID3 2.4 if I want “consistency” of Tag creation between programs, or I can’t use MusicBee’s Tag Editor in ANY way if I choose to stay with 2.3 (same for another user of MusicBee who initially caused me to notice this issue), or if Picard chooses to allow multi-tag NULL creation on 2.3, which they shouldn’t have to do so, to adapt to MusicBee, because MusicBee should be the ones following the proper ID3 standards, not force saving NULL (creating multi-tags) when 2.3 is being used and they aren’t supported on players that require 2.3.

So, that was a fruitless endeavor… I guess I’ll just use 2.4 for now, and if I have problems with players that I’m using, which I was trying to prevent in the first place by using 2.3, I’ll have to change something again.

Lord, I don’t understand some people… It’s NOT the standard, so WHY are people being so stubborn, unwilling to fix a problem me and some others are having, and they instead degrade us, call us names, saying “we” don’t understand, that “they” are following the standard, when they in fact aren’t, etc.? :frowning:

- Picard doesn’t Save with the NULL value creating multi-tags for 2.3, and Picard ONLY does so for the GENRE Tag in 2.4 automatically because of potential issues with players reading multi-tags for other Tags, so they don’t auto-save with the Null value for other tags.

- Mp3tag doesn’t Save with the NULL value on 2.3 OR even 2.4, unless the Null value is already being used with a tag or you “manually” within Mp3tag ADD the doubleslashes and then save, which WILL then create the NULL multi-tags.

(btw BOTH Picard and Mp3tag are CORRECT to be working this way, in order to not create issues for users, as well to follow the proper standards as close to as possible.)

So, like I’ve said at the start MusicBee is completely messing up mine and others Tag/Separators workflow, and forcing us into using 2.4 when it may not be good for us, or we are being forced to NOT USE MusicBee’s Editor if we want to stay with ID3 2.3. Further, as I’ve shown above, I have to still use SCRIPTS to make other Tags with the NULL value, since it’s what MusicBee does for some other tags such as the ARTIST Tag (but not all). So they are further engaging in non-standard behaviors which interrupts workflow and the user has to find workarounds for.

Ugh… :frowning: