UTF-8 characters interpreted as Windows 1252?

MP3Tag v3.00 Windows 10


I am having a problem with accented characters being misinterpreted when displayed in MP3Tag, matching the description found on this page, so I see "König" instead of "König". The files have ID3v2.3 tags generated from a cue sheet during ripping.
%_id3v2_character_encoding% tells gives me UTF-16 as a result, but pasting the text into Notepad++ tells me the encoding is UTF-8.

It is possible that this is a problem with the original cue sheet metadata, as I don't recall seeing this problem all the time. However, when I look at the cue sheet for this album in Notepad it displays correctly. In Notepad++ it also displays correctly and shows the cue sheet encoding as UTF-8-BOM.

Any idea why this is happening and if there is there a simple workaround / fix?

I know there have been many posts on the general topic of character encoding, but I couldn't find an answer to my questions above (sorry if I missed it).


If you put the cue sheet into a zip archive and upload it here, we can try and reproduce the problem.

Thanks. ZIP attached. Looking back at other rips I've done, I don't have so many extended characters in the tags, so it is possible that this is a consistent problem that I've lived with before. For albums like this one with 70+ tracks across 2 discs and numerous accents, it is a pain to manually correct.

I didn't mention above that I also tried the Convert Codepage action (to 1252) but this had no effect. I guess I need to go in the opposite direction anyway (1252 -> UTF) if this was going to work at all.

accents.zip (1.7 KB)

How do you generate the tags exactly?

I use ISO2DSF to generate tagged DSF files from the ISO. I don't do any editing prior to loading into MP3Tag.

To fix the tags you can load the cuesheet in Mp3tag (File> Load Playlist/Cuesheet)
and select the files and copy the tags to the clipboard (Ctrl+C)
Then load the dsf files and paste the tags (Ctr+V) (make sure the file order is the same)

1 Like

I used "CUE Tools" and the provided cue sheet to split a file into MP3 tracks with ID3v2.3 tags.
All the metadata appears correctly in Mp3tag, the same as in the cue file.
To me, that means that the cue file can be used to create unicoded metadata that will display correctly in Mp3tag.

When you say "I use ISO2DSF to generate tagged DSF files from the ISO.", does that mean that the same cue file is used?
If so, then it appears that ISO2DSF does not support Unicode encoded metadata.
But maybe an update to ISO2DSF added unicode support or there is some other suitable software.

However, dano has shown an elegant work-around for your problem.

dano - thanks for the work-around, that's just what I was looking for! To clarify, after copying the tags from the CUE you need to use "Add directory..." to load the files (as "Change directory..." clears the clipboard).

ryerman - I re-extracted from the ISO to troubleshoot this further. It seems that ISO2DSF creates a correct CUE file but the metadata it embeds in the DSF files are wrong. Attached is a screen shot of the second stage of this process where you can see what it is producing. These tagged files show the same characters in MP3Tag, fb2k and in Window Explorer using the dbPowerAmp viewer. However, as the simultaneously produced CUE file is correct, dano's work-around works.

So it is clear that this isn't a problem with MP3Tag. Thanks for your help, and maybe this thread can help others who run into a similar problem.
iso2dsf_small.zip (92.4 KB)