Hey Guys,
I see there are users experiencing corruption of title info under Windows. I’ve seen this behavior with my computers for years. I saw it as a Jaikoz user on Windows XP, and I’m still seeing it now since transitioning to Mac three years ago. It doesn’t happen with all my mp3s but I get my music from a variety of sources, and have never been able to figure out why some tag fine and others don’t. Additionally, I found that even though this info was “corrupted” (displaying chinese characters), it always seemed to display fine on my iPod. I created another thread only because it seems people are looking for bugs in Windows causing this problem. I can attest that this exact same problem is happening in Mac OS X (see attached screenshot), and it has consistently behaved this way through several OS updates. This morning I downloaded a free MP3 track from Philip Selway’s (Radiohead) web site. As an experiment I checked the info prior to doing anything to it, and it displayed all info properly. I pulled it into Jaikoz and looked to see what info fields were blank. I added artwork, and filled in genre and date fields, saved and noticed that now the file was displaying corrupted info. I went back to the original file and tried changing only one thing at a time with the same result. Finally I tried pulling up the original file in Jaikoz, and saving it without making any changes at all. I got the same title info corruption.
Title Info "Corruption" under Mac OSX
Hi thanks for pointing this out. The problem on Windows was when you were using ID3v23 and encoding a field using UTF-16 with Unsynchronization (Preferences/Save/Compatability/Do not Unsynchronization Checkbox unchecked). This doesn’t create a corrupt/invalid file just one that Windows Explorer doesn’t fully understand.
So I tried the same thing on OSX , and got the same behaviour, disable synchronization and the file is handled correctly in FInder, enable and it isn’t.
I then tried the Radiohead file and when I saved this in Jaikoz it also showed up the funny characters, EVEN THOUGH I HAD NOT SELECTED TO ALWAYS USE UTF-16 and the TITLE DID NOT REQUIRE UTF16 TO ENCODE THE VALUES which was confusing.
Further investigation revealed the following, the original file had an ID3v24Tag and the fields were within the tag were ENCODED USING UTF-8 rather than ISO-8859-1. The default settings of Jaikoz convert this to an ID3v23Tag on save because this is better supported (although you can change this in Preferences/Save/ID3v2Tag/Write tag Version). Because ID3v23 does not support UTF8, the fields that were already encoded in UTF8 are encoded as UTF16 because this is the only encoding in ID3v23 that can handle full Unicode.
But if you also enable Preferences/Save/ID3v2 Tag/Save existing fields using these Preferences enabled then the problem does not occur because the existing encoding is not considered so ISO-8859-1 is used whenever possible.
So I hope this clears up the confusion and I will look at changing the jaijkoz behaviour regarding the UTF8 to UTF16 conversion regardless of the value of Preferences/Save/ID3v2 Tag/Save existing fields using these Preferences enabled
Paul,
Thanks so much for looking into this and coming up with an explanation for the behavior and a fix to prevent this from happening. I did as you advised with the Radiohead file, and it worked perfectly. I’ve used this software for years, and have been very happy with it, and with your continued updates and support of the program. Appreciate your efforts in tracking down the problem for me. Now I’m anxious to catch up on some overdue mp3 tagging. Thanks again,
Brad