Bug#998212: easytag: overwrites tags containing UTF8 data with random rubbish

[Adrian Bunk]

On Tue, Nov 02, 2021 at 08:46:41AM +0900, Norbert Preining wrote:
> Hi
> 
> > What kind of files / tags did you process with easytag? If these files
> 
> that were mp3, not sure about what version of tags since they were gone
> afterwards. At least they displayed fine in all music players I used.
> But yes, I guess it is common here in Japan that id3v1 tags are coded in
> UTF8 (or even ShiftJIS).

It would be good to know what the tags were before, and what they are now.

What does "file" say about the affected files?

It is possible you have both latin1 id3v1 and Unicode id3v2 tags,
and your player displays the id3v1 tag.

> I still consider overwriting tags when there was an error during
> preparation, irrespective of the correctness of the original tags,
> a serious problem. easytag should *not* write broken tags.

Define "broken".

When writing both id3v1 and id3v2, it is common that some characters 
cannot be properly written in the id3v1 tag.

Existing tags in ShiftJIS would be broken since this is not a valid 
encoding for these tags in any case.

The situation around tags is a huge mess.

EasyTAG defaults to writing id3v2.3 and not id3v2.4 for reasons like 
Windows Media Player only learning in 2017 how to handle about id3v2.4 
that was published in the year 2000.

And then there are plenty of hardware mp3 players of different age and 
bugginess in use.

One might want to write both an id3v1 tag for compatibility with old 
players in latin1, and an id3v2 tag in Unicode for newer players. And 
then some player that supports both prefers the id3v1 tag.

The preferences of EasyTAG give quite a lot of control over what to 
write and how to handle errors, including how to read and write broken
tags. Most likely the default settings are not a good fit for whatever
was in the files you had.

> Best
> 
> Norbert

cu
Adrian