Non alphanumeric character handling

[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 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.

[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.

[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

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.

[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]

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 -