[SOLVED] Norwegian charaters

[Bjørn Roar]

First of all I will say that I am very happy with the Moode Audio player. It works great and i was a breeze to get up and running. I switched the audio output to headphone and it works great. I am now waiting for a Audio HAT (IQaudIO DAC Pro) and a box that will contain both the HAT and the Raspberry Pi 3 B. 

I have stumbled on a little snag and haven't found anything on it on the Forum.

In the Browse by Artist view, I get a list of artists which contains Norwegian characters like "ø", "å" and "æ" shows up as a question mark "?" in the place of the character. Also Swedish characters like "ä" are shown this way. This is regardless if the character is in the filename, song, album or artist name. This also results that these records are listed at the top of the list. 


Is there something I haven't configured  correctly? 

Nearly all my records are tagged with the Tag & Rename program which uses the UTF-8 charset and all have the Album Artist tagg in use. In my now defunct Sonos ZP80, I have used the Album Artist tag as my primary sorting tag.
I have read the Quick Guide on Artist and Album Artist but I wonder if there are som more information on this subject.

/b

[Tim Curtis]

Zip up some tracks containing these characters in the tags and PM a download link to myself, @TheOldPresbyope and @Nutul. One of us will analyze the files and see of your issue can be reproduced.

[Tim Curtis]

Looks like it's the wav parser used by MPD thats not able to handle the Norwegian characters.

I converted to FLAC using XLD and the metadata looks ok.

       

[Bjørn Roar]

I have been looking a little closer to this, and albums that have the same info in both Artist and Album Artist does not seem to have this problem. Can this have some thing to do with the creation of the virtual Artist or the virtual Album Artist?
I have most of my files in .wav.

/b

[Tim Curtis]

It's hard to say what might be going on.

Go ahead and zip up a couple wav tracks that don't have the issue and PM a download link to same 3 devs.

-Tim

[Bjørn Roar]

Looks like it's the wav parser used by MPD thats not able to handle the Norwegian characters.

I converted to FLAC using XLD and the metadata looks ok.

Yes, this looks correct. 

/b

[TheOldPresbyope]

@Bjørn Roar 

I didn't have time tonight to dig deep into the metadata encoding in your files, but it looks like the files which misbehave for you all have metadata, apparently encoded differently, in both an ID3 tag and in a RIFF INFO chunk. The files which behave have metadata in only an ID3 tag. FYI, INFO chunks are optional in RIFF. To borrow from the Wikipedia article about WAV

As a derivative of RIFF, WAV files can be tagged with metadata in the INFO chunk. In addition, WAV files can embed any kind of metadata, including but not limited to Extensible Metadata Platform (XMP) data[24] or ID3 tags[25] in extra chunks. The RIFF specification requires that applications ignore chunks they do not recognize and applications may not necessarily use this extra information.

At a minimum, the encoding should be the same in the two metadata containers. I'm not sure how MPD's decoders deal with WAV containing metadata in both RIFF INFO and ID3.

Regards,
Kent

[Tim Curtis]

@Bjørn Roar 

I didn't have time tonight to dig deep into the metadata encoding in your files, but it looks like the files which misbehave for you all have metadata, apparently encoded differently, in both an ID3 tag and in a RIFF INFO chunk. The files which behave have metadata in only an ID3 tag. FYI, INFO chunks are optional in RIFF. To borrow from the Wikipedia article about WAV

As a derivative of RIFF, WAV files can be tagged with metadata in the INFO chunk. In addition, WAV files can embed any kind of metadata, including but not limited to Extensible Metadata Platform (XMP) data[24] or ID3 tags[25] in extra chunks. The RIFF specification requires that applications ignore chunks they do not recognize and applications may not necessarily use this extra information.

At a minimum, the encoding should be the same in the two metadata containers. I'm not sure how MPD's decoders deal with WAV containing metadata in both RIFF INFO and ID3.

Regards,
Kent

Here's what MPD database looks like for the failure and success case.

Code:

pi@moode9:~ $ telnet localhost 6600
Trying ::1...
Connection failed: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OK MPD 0.23.5

# Failure
lsinfo "USB/VFAT64/Test/Bjørn Roar/01 - Du er p† Youtube n†.wav"
file: USB/VFAT64/Test/Bjørn Roar/01 - Du er p† Youtube n†.wav
Last-Modified: 2016-11-13T20:06:02Z
Format: 44100:16:2
Artist: ?ystein Sunde
Album: Bestefar
Title: Du er p? Youtube n?
Track: 1
Date: 2016
Time: 182
duration: 182.080
OK

# Success
lsinfo "USB/VFAT64/Test/Bjørn Roar/Some files without the problem/01 Den gr† eminensen.wav"
file: USB/VFAT64/Test/Bjørn Roar/Some files without the problem/01 Den gr† eminensen.wav
Last-Modified: 2011-02-24T20:31:30Z
Format: 44100:16:2
Artist: Blå Tåget
Album: Brustna hjärtans hotell  (LP)
Title: Den grå eminensen
Track: 1
Genre: Progg
Date: 1972
AlbumArtist: Blå Tåget
Time: 338
duration: 338.090
OK
Connection closed by foreign host.

IIRC ffmpeg is being used by MPD to decode WAV format and extract the tags.

The result of ffmpeg tag extract for the failure case shows @ (at sign) where the Norwegian character should be. That indicates that particular character could not be decoded correctly, prolly having something to do with the presence of RIFF INFO tags in the file.

Code:

# Failure
pi@moode9:~ $ ffprobe -loglevel error -show_entries stream_tags:format_tags /media/VFAT64/Test/Bjørn\ Roar/20\ F†glar\ \(Intro\).wav
[STREAM]
[/STREAM]
[STREAM]
TAG:comment=Cover (front)
[/STREAM]
[FORMAT]
TAG:artist= -  (Intro)
TAG:title=F�glar (Intro)
TAG:album=Den Flygande Holl�ndaren
TAG:track=20
TAG:date=1988
[/FORMAT]

# Success
pi@moode9:~ $ ffprobe -loglevel error -show_entries stream_tags:format_tags /media/VFAT64/Test/Bjørn\ Roar/Some\ files\ without\ the\ problem/01\ Den\ gr†\ eminensen.wav
[STREAM]
[/STREAM]
[STREAM]
TAG:comment=Cover (front)
[/STREAM]
[FORMAT]
TAG:album_artist=Blå Tåget
TAG:title=Den grå eminensen
TAG:track=01
TAG:genre=Progg
TAG:publisher=MNW 32-32P
TAG:artist=Blå Tåget
TAG:album=Brustna hjärtans hotell  (LP)
TAG:comment=
TAG:disc=Side A
TAG:date=1972
[/FORMAT]
pi@moode9:~ $

I would try to re-tag those files so that only ID3 tags are present.

[TheOldPresbyope]

@Bjørn Roar 

I don't know the Tag&Rename program so I looked it up. Appears to be available for MS-Windows only

My recurrent complaint about many GUI-based tagging programs is that they obscure what is actually present in a file. This includes popular programs, such as Mp3tag, which can actually handle many metadata representations yet require users to click through menu trees to find the details. (Every time a user presents to us a FLAC file with an ID3 tag stuck on it, I know it's likely to have been tagged using Mp3tag with its default settings.)

I checked on my Linux box this morning: the Linux-only Kid3 tag editor does a decent job revealing the presence of multiple tags---ID3v1.0, ID3v2.x, RIFF INFO chunk, etc. The Kid3 effort provides both a GUI-based editor and a CLI-based editor. Here's a screen shot from the GUi for one of your "bad" files

   

I'm sure there are other appropriate tools, and I can imagine scripting bulk deletions of specific RIFF chunks, but I'm too far removed from MS-Windows these days to know what to suggest.

Regards,
Kent

[Bjørn Roar]

@Bjørn Roar 

I don't know the Tag&Rename program so I looked it up. Appears to be available for MS-Windows only

My recurrent complaint about many GUI-based tagging programs is that they obscure what is actually present in a file. This includes popular programs, such as Mp3tag, which can actually handle many metadata representations yet require users to click through menu trees to find the details. (Every time a user presents to us a FLAC file with an ID3 tag stuck on it, I know it's likely to have been tagged using Mp3tag with its default settings.)

I checked on my Linux box this morning: the Linux-only Kid3 tag editor does a decent job revealing the presence of multiple tags---ID3v1.0, ID3v2.x, RIFF INFO chunk, etc. The Kid3 effort provides both a GUI-based editor and a CLI-based editor. Here's a screen shot from the GUi for one of your "bad" files



I'm sure there are other appropriate tools, and I can imagine scripting bulk deletions of specific RIFF chunks, but I'm too far removed from MS-Windows these days to know what to suggest.

Regards,
Kent

Thanks for the help, guys. I am really impressed. :-)
I did a test by deleting the LIST INFO chunk from one of the albums and now it seems to be ok. 
Se attached file
I will test som more tomorrow and will come back to you with the result.

I still does not understand why this error only shows up in the albums where the Artist tag are different from Album Artist.

BTW. Is there a user guide for writing messages in this forum? I attached the file since I cannot find a way to put the picture in the tekst.

/b