Win7 - ID3 / Artwork / Chinese character corruption with Jaikoz 3.6.0

[hejohnson]

Sorry, Paul, but I think there’s a connection between Jaikoz 3.6.0 (and under certain circumstances, 3.5.1 - see below) and the reported Artwork/Chinese character corruption issues (referred to here as just ‘corruption’).

I’ve used Jaikoz 3.5.0 on Win7 for a couple of months to manually clean up album art on hundreds of albums. I really like the way Win7 displays the artwork on the file and folder icons in the Large Icon view. When Jaikoz 3.5.1 came out, I just automatically upgraded - no problems.

[Aside - When I completed the clean up of my music library a few weeks ago, I turned my attention to another, unrelated task - chopping up large 8-9 GB MPEG-2 files of converted home videos into individual scenes. For anyone trying to this, I highly recommend HandySaw DS. It has literally saved me months of painstaking effort.]

A few days ago, I added music to my library and needed to fix up some of the album art. I opened Jaikoz, gleefully upgraded to the new version 3.6.0, and started to work. To my surprise, I found that when I tried to delete/update the artwork in an MP3 file, Win7 showed a default music icon, not the artwork. When I looked at the file properties, there were Chinese characters in the track title. I noticed that sometimes the corruption would impact other fields, such as Genre or Track# (which would be blank). This was very disappointing and aggravating since every file I touched with Jaikoz while trying to troubleshoot the problem became irreversibly corrupted.

I sent Paul Taylor an e-mail about the problems I had encountered, and he nicely replied:

[quote]HI, this is a bug in Windows 7 but I havent actually tested against
Windows 7 so Im not hundred percent sure of the issue, but I dont think
it understands tags properly, there are some posts on the issue on the
forum http://www.jthink.net/jaikozforum/posts/list/1319.page . I should
be testing against Windows 7 very soon then I can give you a more
comprehensive answer.[/quote]
I reviewed all of the various postings on the Jaikoz forum regarding Windows 7 issues. I was not satisfied with what I read, because my experience with Win7 had been flawless up until recently. I wanted to know what had changed on my system that was now causing me to experience these corruption issues. Even before I contacted Paul, I had tried uninstalling 3.6.0 and reinstalling 3.5.0 and 3.5.1, both of which had worked fine for me under Win7. Given Paul’s response, and what I had read on the forum, I wanted to find out what else had changed on my system to cause the corruption. Was it a recent Windows Update patch, or some interaction with HandySaw DS (which was the only software I had installed since last running Jaikoz successfully)?

I decided to use VMware Workstation 7.1 to test my working theory that something had changed on my system that was now causing the corruption. I started by installing Jaikoz 3.6.0 in a VM with a clean install of Windows XP. My test was very simple - In Jaikoz, delete artwork from an MP3 file (or copy artwork from another file), save it, and look at the results in Win7. I was using a shared folder in VMware, so it was easy to have the VM update a file, and then either copy the file to a mapped Win7 folder, or just update the file in a shared Win7 folder directly, then go to the Win7 host and view the results in Windows Explorer.

I found that Jaikoz 3.6.0 under WinXP still produced the corruption when viewed in Win7 when I performed my simple test.

I then tried a VM with a clean install of Windows 7 and installed Jaikoz 3.6.0. Same result --> corruption.

To make a long story a little shorter, I have tried installing Jaikoz 3.5.0, 3.5.1 and 3.6.0 under different scenarios of clean Win7 and WinXP VM’s, with the following easily reproducible results:

[b]Clean install of Jaikoz 3.5.0 --> No corruption
Upgrade from Jaikoz 3.5.0 to 3.5.1 --> No corruption
Upgrade from Jaikoz 3.5.1 to 3.6.0 --> Corruption!

Clean install of Jaikoz 3.5.1 --> Corruption!
Clean install if Jaikoz 3.6.0 --> Corruption!

Uninstall Jaikoz after any of the above corruptions and reinstalling 3.5.0 --> Corruption!
Uninstall Jaikoz and Java after corruption and reinstall 3.5.0 --> Corruption![/b]

This last part is particularly disturbing, because my desire is get Jaikoz 3.5.0 working again on my Win7 host machine, but I have currently been unsuccessful at completely removing Jaikoz so that I could revert back to a clean install of Jaikoz 3.5.0 without corruption.

Paul, if you could just help me do this successfully, I would be a very happy camper!

Also note that the corruption occurs even when Jaikoz is running under Windows XP, you just can’t ‘see’ the corruption until you transfer the files to a Window 7 environment.

'Hope this helps.

[paultaylor]

[quote=hejohnson]
Also note that the corruption occurs even when Jaikoz is running under Windows XP, you just can’t ‘see’ the corruption until you transfer the files to a Window 7 environment.
'Hope this helps.[/quote]

Hi, Im sorry you have gone to all this effort but I think you are misunderstanding the issue a little, Jaikoz is not corrupting the file the problem is that there is a bug in Windows that did not exist in WIndows XP which is why the problem only shows on WIndows 7. If you tried viewing these files on Windows 7 using a 3rd party application like Winamp you’ll find the files are displayed correctly.

The reason you get the error only in 3.5.1 and 3.6 I think is due to changes in the default preferences rather than a big in Jaikoz itself, when upgrading from 3.5.0 to 3.5.1 it keeps your 3.5.0 preferences, but when installing 3.5.1 from scratch it uses the new defaults.

When you reinstall 3.5.0 delete all your Jaikoz files from under your user folder before installing to give you a vanilla 3.5.0 that should work as you hope.

When I have done by Windows 7 testing I can give you a definitive answer to this problem, but please be assured Jaikoz IS NOT creating corrupt files, just files that Windows 7 Explorer cannot handle properly

[Sock]

I didn’t notice this thread until I had already posted mine (http://www.jthink.net/jaikozforum/posts/list/1409.page), but I wanted to add my observations:

1. This issue has been occurring for me for at least two versions back, which I guess would be 3.50? I believe I may have even seen the issue prior to that.

2. It is clear to me that Jaikoz is doing something to a file (don’t call it corruption if you don’t want to) that causes problems in certain situations. One of those situations is viewing the file properties in Windows 7, and another is when the file is being parsed by Orb Media Server on Windows 2003. The files are fine before Jaikoz, cause Orb to crash after Jaikoz, and work fine again after I remove the “bad” characters.

3. It doesn’t affect all files.

4. I had files showing these “bad” characters that were edited with Jaikoz on Windows Vista. I couldn’t actually see what the corruption was, however, until I looked at the file properties with Windows 7.

[hejohnson]

Paul, you said:

When you reinstall 3.5.0 delete all your Jaikoz files from under your user folder before installing to give you a vanilla 3.5.0 that should work as you hope.

I have searched for all files/folders with Jthink or Jaikoz in the filename, and removed them, as well as, the Jaikoz installation in Program Files. I then reinstalled Jaikoz 3.5.0 but I still get the ‘corruption’ when I try to use Jaikoz.

Any other ideas?

[paultaylor]

I had files showing these “bad” characters that were edited with Jaikoz on Windows Vista. I couldn’t actually see what the corruption was, however, until I looked at the file properties with Windows 7.

It appears there are a number of bugs in Windows 7, some mentioned here http://social.technet.microsoft.com/Forums/en/w7itpromedia/thread/492ae52a-bdff-44fe-9900-ffeb5c6b4d41 but because I do not yet have Windows 7 I cannot give you a definitive answer which is why Windows 7 is not listed at http://www.jthink.net/jaikoz/jsp/support/start.jsp . But rest assured I will get onto this very soon and that Jaikoz IS NOT corrupting the files they are simply using options that Windows 7 does not understand.

You say it only affects some files.

Are the problem files ones that contain non-latin chars if so and you are using ID3v23 then Jaikoz would need to write UTF-16 for these fields instead of the default of ISO-8859, this could be a problem for Windows 7.

Are the problem files ones that contain cover art, songs with cover art are much more likely to need unsynchronization than ones without. But you can disable this in Preferences/Save/Compatability/Do not Unsynchronize tags, also make sure Preferences/Save/ID3 Tag V2/Save Existing Fields using these Encoding Preferences’ is enabled before forcing another Save option.

Could also try saving Tags as V23/V24 and clearing the Disc No and Disc Total Fields

[hejohnson]

Paul-

Do you have a list of the default settings in 3.5.0 vs 3.6.0?
It sounds like I should be able to use 3.6.0 in Win7 if I reconfigure it to match the default settings of 3.5.0. Right?

I’m still concerned that I have not been able to completely uninstall Jaikoz to the point that I can do a clean install of 3.5.0 and get back to the original ‘working with Win7’ state.

In fact, there appears to be some very strange ‘memory effect’ going on now since I’ve been trying to clean out all the Jaikoz files. When I make a copy of my test music folder and then open it up in Windows Explorer, it shows one of the files with the default music icon instead of the album art. When I go into Jaikoz, it also shows that the album art is missing. But, the original folder remains untouched and still contains the files with all the album art. Very strange. All I’m doing is making a copy of the folder with Windows Explorer. It’s repeatable, and it wasn’t doing that a few hours before.

[paultaylor]

[quote=hejohnson]Paul-
Do you have a list of the default settings in 3.5.0 vs 3.6.0?
It sounds like I should be able to use 3.6.0 in Win7 if I reconfigure it to match the default settings of 3.5.0. Right?

I’m still concerned that I have not been able to completely uninstall Jaikoz to the point that I can do a clean install of 3.5.0 and get back to the original ‘working with Win7’ state.
[/quote]
Looking at another post Im not sure what the issue is , please be patient and I’ll get to the bottom of it.

[quote=hejohnson]
In fact, there appears to be some very strange ‘memory effect’ going on now since I’ve been trying to clean out all the Jaikoz files. When I make a copy of my test music folder and then open it up in Windows Explorer, it shows one of the files with the default music icon instead of the album art. When I go into Jaikoz, it also shows that the album art is missing. But, the original folder remains untouched and still contains the files with all the album art. Very strange. All I’m doing is making a copy of the folder with Windows Explorer. It’s repeatable, and it wasn’t doing that a few hours before.[/quote]
Jaikoz adds album art to the file itself so whether it shows artwork as missing or not is based upon this rather then there is artwork in the folder the song is in, I don’t know about how Explorer works

[paultaylor]

Another link giving details of some of the issues with WIndows 7 and WMP 12

Hasta la Vista, baby: Ars reviews Windows 7

[paultaylor]

Ive been testing Jaikoz against Windows 7 (64 bit).

The main problem is Windows 7 does not understand unsynchronized tags, so if you are using Windows 7 you should enable Preferences : Save : Compatibility : Do not Unsynchronize Tags if it is important for the information to look correct in Windows Explorer. However this may break the compatibility with your music player (i.e iTunes). To apply this change to existing files when you havent actually modified any fields you then need to run File:Force Save

This will fix both text fields and Album art.

Secondly, Windows 7 doesn’t understand ID3v24 , so if you use this version of ID3 nothing will be shown in WIndows Explorer unless your file also contains an ID3v1 tag.

[paultaylor]

Further investigation detailed in http://www.jthink.net/jaikozforum/posts/list/1429.page revealed the following when the original file had an ID3v24Tag and the fields within the tag were encoded using UTF-8 rather than ISO-8859-1 then when saved would be converted to ID3v23 encoded as UTF-16.

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 UTF-8, the fields that were already encoded in UTF8 are encoded as UTF-16 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 Jaikoz behaviour regarding the UTF8 to UTF16 conversion going from ID3v23 to ID3v24 regardless of the value of Preferences/Save/ID3v2 Tag/Save existing fields using these Preferences enabled