Non alphanumeric character handling

[barkeyo]

Experiencing interesting handling of non-alphanumeric characters in album names with R7.4 on Synology.

For example, Ed Sheeran's daftly named mathematical symbol albums -

+ displays fine
÷ displays fine
x displays fine (it's alpha x, so it should)

= doesn't display, just shows "Unknown Album"

See below screenshot -

[vilsen]

Re: Non alphanumeric character handling

I think that Asset doesn't accept "=" as the very first character in a tag and will consequently delete it. So if "=" is the only character, the tag will be treated as absent. At least this is how it seems to work in windows - don't know if it's intentional or a bug.

A workaround could be to populate the tag with "==" cause the second one stays.

[barkeyo]

Re: Non alphanumeric character handling

Thanks for the info on Asset's handling of the "=".

Personally, it looks like a bug, as Windows (Win10 anyway) seems to display the original album tag just fine when both playing the album's music files natively and viewing the files' properties. The 3rd party media manager (MusicBee) on my PC also has no problem with it, as does using the Synology DSM interface for the NAS. So, it just appears to be when Asset is doing the metadata provision.

[Dat Ei]

Re: Non alphanumeric character handling

Depending on the programming language, DMBS or SQL engine it can be necessary to mask special characters like '=' in strings. So '=' can be a different story than '+', '÷' and 'x'.

Dat Ei

[barkeyo]

Re: Non alphanumeric character handling

@Dat Ei, I'm not sure the programming language is relevant here.

Having done a bit more digging before vilsen's previous comment, I thought initially that Asset might actually be applying the Vorbis Comment tag FieldName rule of Vorbis comments to the data entry itself.

"A Vorbis tag is a list of fields in the format FieldName=Data. The field name can be composed of printable ASCII characters, 0x20 (space) through 0x7D (&*8216;}&*8217, with 0x3D (&*8216;=&*8217 and 0x7E (&*8216;~&*8217 excluded"

However the for data field itself -

"The data is encoded in UTF-8, and so any conforming Unicode string may be used as a value"

Therefore following on from vilsen's comment, if Asset can read and display the 2nd '=' in an entry, then Asset by failing to read and display the 1st, clearly isn't enforcing consistency in it's handling of what is a technically correct UTF-8 encoded string.

[barkeyo]

Re: Non alphanumeric character handling

Hi Dat Ei, I'm not sure that the programming language is relevant here.

After some further digging prior to vilsen's comment, I initially wondered whether Asset was applying the Vorbis Comment tag FieldName rule to the data string itself -

A case-insensitive field name that may consist of ASCII 0x20 through 0x7D, 0x3D ('=') excluded.

and

The field name is immediately followed by ASCII 0x3D ('='); this equals sign is used to terminate the field name.

However -

0x3D is followed by the 8 bit clean UTF-8 encoded value of the field contents to the end of the field.

i.e. the data, or field value, is encoded in UTF-8, so any UTF-8 encoded value after the FieldName terminating "=" is valid, including the following actual FieldName + UTF-8 encoded value string [41 4C 42 55 4D 3D 3D] "ALBUM=="

vilsen's comment regarding the fact that Asset will display a 2nd "=" in the string if it's entered twice, i.e. [41 4C 42 55 4D 3D 3D 3D] "ALBUM===", would indicate that Asset is simply handling the 1st "=" in the field value incorrectly.

[simbun]

Re: Non alphanumeric character handling

Asset UPnP r7.4 on Windows 10 displays Ed Sheeran's album = in mp3 fine, but not in flac so it's got to be a bug.

Until it's fixed you could always use a unicode equivalent. I replace the illegal filename characters with unicode equivalents for file and folder names so I get a more consistent view when browsing the filesystem.

[Spoon]

Re: Non alphanumeric character handling

It looks like dbpoweramp is not even writing = to the tags of vorbis comments, will add to bug report.

[barkeyo]

Re: Non alphanumeric character handling

Hi simbun,

Thanks, so that would seem to confirm that Asset's ID3 tag handling for mp3 files is fine, but it's handling of Vorbis Comment tags for flac files isn't, at least in this specific scenario.

In which case, is there a specific way of raising this as a bug to the development team, or is simply posting in the forum sufficient?

[barkeyo]

Re: Non alphanumeric character handling

Hi Spoon,

Thanks, you answered my question seconds before I asked it...

Much appreciated.

[vilsen]

Re: Non alphanumeric character handling

If this doesn't resolve for a while, you could try another workaround without touching the ALBUM tag.

In Asset's Rename List, add the line

album:=(Unknown Album):==

Then restart & refresh all.*

This will replace "(Unknown Album)" with "=". If you would have other unknown albums they will be renamed too of course, so be careful.

This works in Windows at least.


* Since the tags (and file dates) are untouched you need to use "refresh all". With a big library, you could instead edit a tag of the specific album (or just update the file dates) and then use "detecting changes".

[Spoon]

Re: Non alphanumeric character handling

If you tag the album as == then only 1 = will appear to Asset.

[vilsen]

Re: Non alphanumeric character handling

Yes, and it's been said above. But then you'd have to tag specifically for Asset which wouldn't conform with your other applications.

My point was a workaround that leaves the ALBUM tag intact.

[vilsen]

Re: Non alphanumeric character handling

It looks like dbpoweramp is not even writing = to the tags of vorbis comments

It does, I just did a hex check of a flac file tagged by music converter.

[barkeyo]

Re: Non alphanumeric character handling

If this doesn't resolve for a while, you could try another workaround without touching the ALBUM tag.

In Asset's Rename List, add the line

album:=(Unknown Album):==

Then restart & refresh all.

Hi vilsen, thanks for that suggestion, which I can confirm works a treat. I was reticent to start editing the actual ALBUM tag of the files themselves, since as you highlighted to Spoon, that would have had a knock on effect on the other apps that access the music files.