Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Poison Dan]

My music collection consists of APE CD images, with APL files for each song on the CD. I have stored the cover art for each CD within the APL files.

Until recently, everything was fine, but now I suddenly noticed that the visualizations didn't show my cover art anymore. I checked out the properties of the files, looked at the "Image" tab, and saw that the location was changed from "inside file(s)" to "linked to external file ... (I can't read the entire path, but it seems to be somewhere in my temp dir).

The strange thing is, some files are showing the internal image, and some files don't show it.

Here is an example from the album "Odelay" from "Beck":

Track 1, "Devil's Haircut", is OK:


Track 4, "The New Pollution", is not OK:


I didn't change anything inside the tags over the last couple of weeks, except replay gain: I did analyzed my entire collection over the last couple of days, so maybe this has something to do with it.

You can download the two APL files here (144 KB each):
http://users.skynet.be/bk343709/01 - Beck - Devils Haircut.apl
http://users.skynet.be/bk343709/04 - Beck - The New Pollution.apl

How can I "repair" the defective APL files ? Are there any bytes that I could change (I could write a program to automate it) ? Or is there a way I could extract the cover art from the good APL files and add it back using the file properties ?

Downloading all cover art again is really the last option I would consider.

TIA.

Edit: forgot to include my system info:

Media Jukebox PLUS 8.0.331
Install Path: D:\Program Files\J River\Media Jukebox\

CPU: Intel Pentium III 839 MHz MMX
Memory: Total - 523 MB, Free - 329 MB
OS: Microsoft Windows XP  Workstation 5.1  (Build 2600)

Internet Explorer: 6.0.2600.0000
ComCtl32.dll: 6.00.2600.0000
Shlwapi.dll: 6.00.2600.0000
Shell32.dll: 6.00.2600.0000
wnaspi32.dll: 4.71 (0001) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc.
Aspi32.sys: 4.71 (0001)

[Matt]

Not sure how it happened, but the tag thinks there's an internal and external image.

The next build of MJ (Monday) will fix it so that it'll clear an external link in those cases.

However, I wish I knew how it happened?  Can you reproduce it on some test APL's?

Thanks.

-Matt

[KingSparta]

I guess you can rebuild the data base, then search local only for the Clip art.

and then wait for a fix on monday.

the J river parking lot is almost empty

[Poison Dan]

Matt,

I thought about it some more, and now I think I know how it happened. However, I don't have any time right now to thoroughly test it and write a detailed explanation. I'll probably write about it sometime this weekend.

[Poison Dan]

Right, I figured out what went wrong.

My apologies for the long post, but I wanted to make it as thorough and detailed as possible.

The "executive summary":

Make sure the checkbox "Store image(s) inside music files when possible" is unchecked by default (you can safely uncheck it by opening the properties of a file that doesn't have any cover art). Next, open the properties of a file with an internal image, and click on "Save" WITHOUT CHANGING ANYTHING. Now the file will link to an unexisting image file, as you have seen in my second screenshot.

The details:

I analyzed the replay gain of my entire music collection during the last week. At first, I analyzed about 200 files at a time, but in the end I analyzed the remaining files (most of my collection) during the night. I noticed that the files that were affected by this problem of "disappearing cover art" were the files that got analyzed during this big "batch run". In the "analyze replay gain" dialog, files are sorted alphabetically, and all my files up until "Everybody Hurts" by R.E.M. were fine, and the files starting with "Everybody In The Place" by the Prodigy up until the end of my collection were faulty. This is consistent with the problems I saw with the Beck album: "Devil's Haircut" was fine, "The New Pollution" wasn't.

Anyway, I got thinking "what could have gone wrong during that batch run" ? A few days after that batch run, I added another 4 albums to my collection, and analyzed those, and they were perfectly fine. Then it occurred to me: when I added the cover art of those 4 albums I did notice the checkbox "Store image(s) inside music files when possible" was UNchecked. I was a bit surprised by this, because normally this would have been checked. Anyway, I checked the checkbox and thought "maybe the default for this was changed with some new build of MJ", and I figured I only needed this checkbox when I add some cover art, so it couldn't have been a big deal.

However, this proved the be the key to my problems: I clearly remember that, when I analyzed those 4 latest albums, I pressed "Cancel" at the file properties dialog when it was finished. With the big batch run, I probably pressed Save. Normally, pressing Save at this point shouldn't change any tags when you don't change any fields in the dialog, but it did.

As a test, I did exactly what I mentioned in the "executive summary" at the top of this post.

Of course I never would have gotten the problem if I always clicked "Cancel" in the file properties dialog when I don't change anything, but it seems to be a bug. At least, I would say it is "inconsistent behaviour".

Look at it this way: the cover art is basically just another tag item. In that case, the "Store image(s) inside music files when possible" checkbox should change according to the file that the user has selected:
- When the user selects one or more files that have internal images, the checkbox should be checked.
- When the user selects one or more files that do not have internal images, the checkbox should be unchecked.
- When the user selects multiple files, with some files containing an internal image, and some file without an internal image, the checkbox should be the equivalent to "", consistent with the other tag fields. Because you can't change a checkbox to contain a "" value, the checkbox could e.g. be greyed out.

In any way, as long as the user opens the properties of a file, doesn't change anything, and presses "Save", no changes should be made to the tags, and this is clearly not the case right now.

Another option would be to disable the "Save" button as long as the user hasn't made any changes to the tags.

From now on, I'll remember to press "Cancel" whenever I look at the properties again without changing anything, but I hope you will correct the bevahiour of MJ8 accordingly soon.

I hope this explanation is clear enough. Let me know if I have to provide some more information.

Media Jukebox PLUS 8.0.331
Install Path: D:\Program Files\J River\Media Jukebox\

CPU: Intel Pentium III 839 MHz MMX
Memory: Total - 523 MB, Free - 345 MB
OS: Microsoft Windows XP  Workstation 5.1  (Build 2600)

Internet Explorer: 6.0.2600.0000
ComCtl32.dll: 6.00.2600.0000
Shlwapi.dll: 6.00.2600.0000
Shell32.dll: 6.00.2600.0000
wnaspi32.dll: 4.71 (0001) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc.
Aspi32.sys: 4.71 (0001)

[Poison Dan]

Although the length of my previous post might suggest otherwise, I was actually in a hurry when I wrote it. Afterwards, I realised I made a small mistake:

Look at it this way: the cover art is basically just another tag item. In that case, the "Store image(s) inside music files when possible" checkbox should change according to the file that the user has selected:
- When the user selects one or more files that have internal images, the checkbox should be checked.
- When the user selects one or more files that do not have internal images, the checkbox should be unchecked.
- When the user selects multiple files, with some files containing an internal image, and some file without an internal image, the checkbox should be the equivalent to "", consistent with the other tag fields. Because you can't change a checkbox to contain a "" value, the checkbox could e.g. be greyed out.

This is of course not true. That checkbox isn't part of the tag, it's simply an option that tells MJ how to handle images in general. So please ignore this part.

Let's just keep it at this:

In any way, as long as the user opens the properties of a file, doesn't change anything, and presses "Save", no changes should be made to the tags, and this is clearly not the case right now.

Another option would be to disable the "Save" button as long as the user hasn't made any changes to the tags.

And now I'll shut up for a little while.

[Poison Dan]

And now I'll shut up for a little while.

For a very little while...

I fixed the APL files ! I found out that I simply had to select the file properties, make sure the "Store image(s) inside music files when possible" is checked, and press "Save".

I did this for the file properties of my entire collection, and I can see my covert art again for all my files.

Well, that was easy enough.

[Poison Dan]

Bump, just to make sure Matt sees this thread.

[Matt]

Will you try to confuse MJ again when the next build of MJ 8 comes out?  I'm thinking we may have fixed it, but I'd like to be sure.

Thanks Poison Dan.

-Matt

[Poison Dan]

Sure, I was planning on doing this anyway.

[Poison Dan]

Well, I tried to "break" the internal images with build 334, but MJ keeps working great, no matter how hard I try to "abuse" it.

So, to conclude: good job, two thumbs up !!

Listening to: 'Break Stuff' from 'Significant Other' by 'Limp Bizkit' on Media Jukebox

"GIVE ME SOMETHING TO BREAK !"