Print

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

[MusicHawk]

When I find the need to edit an artist or album name (such as to fix a typo or inconsistency), if there is existing cover art, the .jpg gets disconnected from the music tracks and either is abandoned or deleted.

Scenario: I have an existing set of music tracks in an album, in a folder named by MC using pattern Artist\Album. If I paste in a cover art image, it gets embedded in the tracks, and also added to the folder using the Artist - Album convention. Good!

Later, I edit the artist and/or album field. I use MC's "rename files from properties" feature, and MC "moves" (renames) the folder and its music files to match the changed properties. Perfect!

However, the cover art file does NOT get renamed or moved along with the music files. The embedded image seems to be retained, so I don't readily notice the problem. But if I look in the new album folder, the image file isn't there. It gets orphaned, left behind in the old folder; or sometimes the old folder and image disappear.

Now I have a new folder with music tracks but no image file, and an old folder with nothing but an image file. This leads to a lot of hard-drive clutter and/or cleanup work.

If I'm correctly describing what is happening, is this normal and desirable behavior? Is there a better way to store cover art images?

It seems like this could all be improved by having cover art files behave the same as music files, using the same naming patterns, and processing both via "rename files from properties". Treating music and cover art files the same when MC renames/moves, including updating the locations of both files in the track fields, would keep stuff from breaking.


APPARENT BUG: Discovered during testing for the above report...

When I Remove Cover Art from a track, and say YES to Also Permanently Delete Cover Art Files From Your Hard Disk -- it doesn't. I have tested this repeatedly with .410 and the .jpg file is removed from the music track but it is NOT deleted from the folder.

 

[Alex B]

This has been beaten to death on several occasions before. I think a few of my "cover art links" point to threads that have related discussion.

MC doesn't have any kind of separate cover art database. External cover art exists only as file metadata (in the Image File field). Cover art is called when needed by using this tag, but the cover art file itself is not a library file by default. Because of this the standard library tools cannot handle cover art files directly.

I suppose the developers could add code for reading the link data in each audio file and moving the image file too, but because you can link any images manually with any audio files (this is not limited to albums or certain filenames or folders) and move individual album tracks it would be quite difficult to create a tool that would take every possibility into account.

I solved the problem years ago by importing the cover art files to the library. Whenever I want to move my albums I use a view scheme that can show the audio files and the cover art files simultaneously (i.e. I use a view scheme rule that makes this possible). In addition, I have tagged the cover art images with the Artist and Album tags so that they show up with the audio files in an album view (without tags the only way to browse them is to use the disk location).

Embedded cover art is different. In this case MC doesn't have any kind of connection to the possible copy on the disk because the Image File field value is "Inside File". MC can't delete a disk file if the file link is not available in the Image File field.

[AoXoMoXoA]

I find it cumbersome but have gotten into the habit when renaming albums etc, to first right-click on the files and use Cover Art -->> Copy Image File (to clipboard), then once renamed use Cover Art -->> Paste from clipboard.

[Doof]

The other alternative is to set yourself up a central cover art folder and move all cover art there using an [Album Artist (auto)] - [Album] naming convention. Then link all of your files that way and even if you move the audio files around, they should stay linked. I used to do it that way. Then I saw that using the Folder.jpg scheme tells Windows to display the folders using that image and so then I actually started putting it in both places. Eventually I moved to just the Folder.jpg method. I've since run into the same issues you describe when moving files around, so I'm starting to think about doing it differently, either going back to a central cover art folder, or trying AlexB's method. I think Alex's would be easier in the short-term, but long-term, I think a central folder would be easier to maintain. I just wish I could remember why I stopped doing it that way in the beginning. I'd hate to get bitten by the same problem twice.

[Doof]

I find it cumbersome but have gotten into the habit when renaming albums etc, to first right-click on the files and use Cover Art -->> Copy Image File (to clipboard), then once renamed use Cover Art -->> Paste from clipboard.

The problem with that is that you wind up with orphaned folders all over the place. With Alex's or the central folder method, MC can automatically clean up the empty folders for you.

[AoXoMoXoA]

The problem with that is that you wind up with orphaned folders all over the place. With Alex's or the central folder method, MC can automatically clean up the empty folders for you.

Alex's method's for handling cover art is stellar if you have the covers in the same folders as the media files.
Not in my case as I do not have them in the Artist Artist/Album folders, but in one Cover Art folder. Worst I see in my case is orphaned cover art files with now erroneous names.   

[Alex B]

I wonder if anyone who uses a central location has stumbled on two different albums with the same default cover art name. For example, (Multiple Artists) - Best Of.jpg

Naturally this is easy to fix by naming one of the files differently and linking it manually.

[Doof]

I wonder if anyone who uses a central location has stumbled on two different albums with the same default cover art name. For example, (Multiple Artists) - Best Of.jpg

Naturally this is easy to fix by naming one of the files differently and linking it manually.

I wonder if MC has a built-in handler for that type of thing, that when you pasted the image to the files and that image name already exists, it just tacks a 1 to it or something? I'll have to test that.

I know part of the reason I abandoned the central folder method was that I kep losing it. Like I'd forget to back it up or something and it would get deleted.

[Alex B]

I wonder if MC has a built-in handler for that type of thing, that when you pasted the image to the files and that image name already exists, it just tacks a 1 to it or something? I'll have to test that.

You don't need to test it. Any existing file with the same name is overwritten.

I know part of the reason I abandoned the central folder method was that I kep losing it. Like I'd forget to back it up or something and it would get deleted.

I moved my cover art files from a central location to album folders even before the option to use the audio file folder became available in MC (I linked them manually).

I like to keep all album related files in the same folder and use MC for handling them all. Quite often I have several image and document files in the album folder (e.g. back, cd, booklet and artist's images, album review, rip log, other related documents etc).

[MusicHawk]

Thanks for the comments.

>> This has been beaten to death on several occasions before.

Maybe that indicates it's still an unresolved situation that won't get improved by shutting off conversation.

I used a central Cover Art folder for a long time, but kept getting one image replaced by another without knowing it. (More than 75 thousand tracks so can't keep track of all the names in my head.)

So I switched to putting cover art images in the album folders, with embedded as a sort of safety net, but with the reported problems.

Many things about MC are flexible, but they also have defaults or best practices that meet the needs of most users.

Wouldn't it be a terrific OPTION to let users lock cover art files to music files? How much of the endless discussion would go away if it was an easy option to treat cover art files just like music track files, putting them in the same file location/name control via properties, therefore renaming/moving them as a set?

For those special cases, it could even be possible to offer a per-track flag field to override the behavior and accept a per-track embedded and/or linked image that doesn't get touched by MC.


PS: I'm not trying to argue, just find a workable method and move on. I don't think stepping outside MC to manually copy+paste or move/rename (which is what I, too, have been doing) is a viable procedure in a commercial media management product. Most of the powerful features of MC could be removed if it was deemed normal to have users jump out to the file system to keep things orderly for MC. The big value comes from what MC automates for the user, which is well-evolved for music files; why not polish up the rough edges of cover art management?

[AoXoMoXoA]

Wouldn't it be a terrific OPTION to let users lock cover art files to music files?

welll we have 'Otto' for auto-import, why not 'Otto Jr' to auto-manage covers?   
 

I don't think stepping outside MC to manually copy+paste or move/rename (which is what I, too, have been doing) is a viable procedure in a commercial media management product.

What I outlined above as my work-around is all done inside of Media Center. Just to clarify in case you misunderstood.
Actually you could move/rename cover art files inside MC as well.

[Alex B]

Wouldn't it be a terrific OPTION to let users lock cover art files to music files? How much of the endless discussion would go away if it was an easy option to treat cover art files just like music track files, putting them in the same file location/name control via properties, therefore renaming/moving them as a set?

Actually, I tried to explain that I already do this. I treat the cover art files just like other media files in the library.

Here's a screenshot of one of my "All Media" view schemes:


Click to enlarge.

In my library this album consists of 15 audio files, 4 document files and 8 image files. I don't need to go to my storage room and try to find the CD if I want to read the liner notes.

The actual cover art file is selected in the screenshot.

If I want to move this album I select all files and use any of the standard tools for moving the files. Quite often I just type the new path in the "Filename (path)" field. (Some of my "details" view schemes have over 50 visible columns.)

The cover art link will be correct after the operation because MC doesn't store a path when the image file is linked from the audio file folder.

[MusicHawk]

Alex, I appreciate your suggestion. I'm experimenting with your technique.

But, I don't see any file paths in the Image file column, so I can't edit them. This is because all my tracks are set to store the image in a tag, so every track that has an image shows "Inside File". Of course, these tracks also have external .jpg files; is there any way to get all these converted to purely an external file? (I hope I don't have to remove the cover art, but not delete the file, then re-add it only as a file -- a huge job with my library.)

[Alex B]

The Image File field is not directly editable. My system is usable with MC's cover art automation because I use the [Album Artist (auto)] - [Album].jpg naming templete for the actual cover art file. The other image files are named differently.

I have explained my system a few times before (check the "cover art links" link in my earlier reply for tips), but I don't think MC has any convenient way to mass-extract cover art from tags. Personally, I would use Mp3tag and its "Export Cover To File" feature, which is designed for that purpose.

Do you actually need to extract the embedded image for some reason? You can keep it as it is and still import the separate disk file for moving it together with the audio files. If you use a separate view scheme for tagging and moving operations you don't need to see the file in other view schemes. Later on you can add additional images if you want.

I have currently about 9000 imported images for my about 3000 ripped CDs and recorded vinyls. The project advances slowly. I started four years ago and I think I am about half way through scanning and/or downloading more or less complete cover art sets.

[hit_ny]

What was the reason for tagging non audio files Alex ?

Is it because MC can only move files that it knows about so if you want to move a folder using rename file from properties then all files must be imported into the library.

If so, this method is way too tedious. I only imported the art & the audio files, the  rest is left in the folder un-imported. Cover art not embedded in the files.

If i ever need to move folders i do it manually via drag-drop and the tree.

Never lost any cover art linking when moving folders.

[Alex B]

What was the reason for tagging non audio files Alex ?

For example: Ctrl+F

When I created the screenshot I clicked my "All Media" root view scheme and wrote Hunky Dory in the search. All files appeared in the bottom details view.

I use MC for viewing the images and opening the document files in external apps.

Also, I can easily run a slideshow of the images during album playback after I have browsed to a certain album in one way or another (without needing to browse by the directories).

Is it because MC can only move files that it knows about so if you want to move a folder using rename file from properties then all files must be imported into the library.

This is also true.

[hit_ny]

I use MC for viewing the images and opening the document files in external apps.

So do i if for instance i want to see a txt file usually there is just one/folder.

Click a audio file from the album in any [Audio] viewscheme and then Send To->Send(to external) will call a batch file to open up notepad with this txt file already loaded.

Actually this cmd would be very useful button for the toolbar, if we could configure buttons for send To (external) commands.

[dcwebman]

I find it cumbersome but have gotten into the habit when renaming albums etc, to first right-click on the files and use Cover Art -->> Copy Image File (to clipboard), then once renamed use Cover Art -->> Paste from clipboard.

I have been using Alex's method, but used to do this method. The only thing to avoid the orphan files that is to insert a step:
use Cover Art -->> Copy Image File (to clipboard), then Remove Cover Art (permanently).
then once renamed use Cover Art -->> Paste from clipboard

[AoXoMoXoA]

I have been using Alex's method, but used to do this method. The only thing to avoid the orphan files that is to insert a step:
use Cover Art -->> Copy Image File (to clipboard), then Remove Cover Art (permanently).
then once renamed use Cover Art -->> Paste from clipboard

hmmm, good idea and makes sense, but sheesh another step to remember and do 

I wish I had gone with Alex's plan when I only had a few gigabyte of music instead of a central cover art folder.
At this point it woul be too huge a project to change over without something like the old King Sparta 'Move Cover Art to Album/Artist.jpg' plugin.
This is because my folder naming structure contains tag fields in the names that the covers do not have:
[Album Artist] ([Genre])\[Album] ([Date])\[Artist] - [Album] - [track #] - [Name]
i.e.:  Grateful Dead (Rock)\Live Dead (1969)\Grateful Dead - Live Dead - 01 - Dark Star.flac

Yes this appears overly complex, but early on in MC's incarnations I had issues with losing tags and decided to safeguard the vital info by embedding it into the filenaming & directory structure for ease of retagging from filename.
Now that MC has matured and tags are stable I find this less necessary, and in the case of moving cover art it is a detriment. And yes in some cases filename length has been an issue, but mostly only with classical pieces.

[MusicHawk]

>> Do you actually need to extract the embedded image for some reason?

Why embed images? Just to have an all-in-one package? Or is there some other benefit, given the downside is, it makes fatter music files, and creates challenges when moving the files to an iPod or other device where the images aren't desirable due to limited disk space.

I dunno... I've read threads and the wiki for hours and the cover art situation seems totally unsettled. Other than putting more work on JR's plate to implement, I haven't heard what's wrong with the idea of treating cover art files just like music track files, all controlled as a set via Rename Files From Properties. Wouldn't this yield the same benefit but with more positive control than provided by Folder.jpg, and avoid losing the file when renaming/moving the album's music files?

[hit_ny]

>> Do you actually need to extract the embedded image for some reason?

Why embed images? Just to have an all-in-one package?

My guess is thats the answer. Embed & forget.

I haven't heard what's wrong with the idea of treating cover art files just like music track files, all controlled as a set via Rename Files From Properties. Wouldn't this yield the same benefit but with more positive control than provided by Folder.jpg, and avoid losing the file when renaming/moving the album's music files?

The set you mention above is achieved by using a common tag for all these files.

So as Alex mentions above, [Album] could be the set, so all audio + other files belonging to [Album] move as one.

I just used [Album] as an example, it can be any common tag.

[MusicHawk]

There's some good info in this thread, but as the starter of it, I want to point out that the original issue is still not resolved: How can a typical user, using the normal cover art method of auto-naming as Artist - Album, avoid losing images and getting orphaned folders/files when renaming Artist or Album? Why isn't this automatically managed by MC?

Clever workarounds are clever, but not for the average user. If cover art is a popular feature for normal people, why not evolve MC to eliminate the need for long discussions of how to get MC to do what I argue should be transparent?

[Alex B]

There's some good info in this thread, but as the starter of it, I want to point out that the original issue is still not resolved: How can a typical user, using the normal cover art method of auto-naming as Artist - Album, avoid losing images and getting orphaned folders/files when renaming Artist or Album? Why isn't this automatically managed by MC?

Clever workarounds are clever, but not for the average user. If cover art is a popular feature for normal people, why not evolve MC to eliminate the need for long discussions of how to get MC to do what I argue should be transparent?

The default cover art option works without any tweaking. AFAIK, it is designed for "normal" people. Cover art is stored inside tags (when possible) and a copy in a central location. There's no need to move the files from the central location.

IMHO, if someone wants to use MC's tools for handling any files, the best option is to import and tag the files. Maybe JRiver will introduce a new database for automatic and transparent cover art handling, but currently MC12 does not have such a thing.

[MusicHawk]

>> Cover art is stored inside tags (when possible) and a copy in a central location.

Aren't we just arguing about WHICH invisible trap a user should be exposed to?

Putting all images in one folder triggers the OTHER problem: MC sometimes overwriting one image with another, without warning or recovery. There are common actions that cause this, and I've experienced it big-time, which is why putting images in album folders is desirable, if it could be smoothed out.

And, because files in the central location still need names, what are the names? When pasting-in, MC gives them the specified pattern name, usually Artist - Album, which then loops back to the "change the Artist or Album" properties problem.

What is reasonable MC behavior to meet the needs and expectations of average users? I argue a user expects that cover art, once added to an album via ANY method (paste, import, lookup, whatever) and using ANY of MC's offered cover-art name/location/storage options, should not get "lost" by using normal MC activities -- defined as, actions available in the main menus. Cover art should be managed seamlessly with album tracks, no matter which of MC's "standard" methods is chosen.

OR, if there are unavoidable risks with each method, give explicit warnings, such as "don't click rename files from properties in an Audio-only view unless you want to manually repair your linked images."

You've offered some useful advice that helps me (I'm a developer, no fear of workarounds) but I can't recommend to an average user that MC has a reliable method of handling cover art.

[JimH]

>> Cover art is stored inside tags (when possible) and a copy in a central location.

Aren't we just arguing about WHICH invisible trap a user should be exposed to?

Alex has tried to offer help.  I don't think he's doing any of the arguing.

Could our cover art handling be improved?  Without a doubt.  Is it as terrible as you seem to believe?  I don't think so.  Is changing it a high priority?  No.

For now, your best option is to adapt to what's available or find a better program.

[Alex B]

There is no simple solution because MC has only individual files in the database. It does not have albums. Everything that shows up as albums is grouped by reading the file tags. By default the database does not have cover art files either. Similarly like the albums, cover art is created by reading audio (or video) file tags. When MC moves albums it moves the track files one by one.

Though, I think one relatively easy solution could be possible. What if each tool that moves files would have an option for moving all unimported files from the file folder to the new location together with the moved file. The first track file would move all unimported files from the folder. The following track files would not move any additional files because there would not be unimported files anymore. I don't know how slow that kind of code would be. Would it need to compare the folder contents with the complete database?

EDIT

When a central location is used MC overwrites cover art only when the [Album Artist (auto)] and [Album] tags are identical. In my experience this is rare, but could this be handled somehow automatically? Possibly MC would need check that the same file is not already linked from outside the current file directory. If such a link exists, MC would create a file with altered filename.

[hit_ny]

What if each tool that moves files would have an option for moving all unimported files from the file folder to the new location together with the moved file. The first track file would move all unimported files from the folder. The following track files would not move any additional files because there would not be unimported files anymore. I don't know how slow that kind of code would be. Would it need to compare the folder contents with the complete database?

I thought about this intially as a work-around but i fear it would be breaking a cardinal rule.

Don't touch what isn't yours !

[Doof]

I was just thinking that an even easier option would be to change how MC names the cover art files in the central cover art folder.

Right now it uses [Artist] - [Album], which doesn't really work because if you have a mix album, then you end up with one image for every one track on that album. If they changed it to [Album Artist (auto)] - [Album], that would mostly fix that issue, but you could still run into a problem where there could be one or more (Multiple Artists) albums that had the same album name.

But what if MC instead used a naming scheme that used something similar to [Date (filename friendly)]? I was thinking something like a [Date Imported (filename friendly)] field. Or some unique serial number assigned to each cover art image. With a method like this, every cover art file should have a different filename, so no accidental overwrites should occur. Their all in a central folder, so moving the audio files around won't break the connection, and there's no image imbedded into the file to cause larger than necessary filesizes and portable mp3 player problems.

[hit_ny]

Works if you must use a central folder. But i've never been a fan of this as it can be tricky to find anything in it.

Lots easier if its in the same folder as the album itself, which is the method i've been using for years now without any issues whatsoever. Everything that belongs to an album in one place

But then the OP says

To use "one .jpg per folder" I'd need a zillion folders (well, almost -- 72,000 tracks and growing).

and instead wants

..properties-based control over image-file naming, as we already have for music-file naming.

I'd have thought that the easiest way to go then would be to embed the images in the files and all is good cept...

My biggest concern, and reason for storing images separately, is making sure image files are EXCLUDED from my iPods. I keep running out of space and having a variety of synch problems, even though there should be plenty of space for the number of tracks I synch. After a failure, when I check with iTunes, I discover half the drive is full of images, even though I tried to exclude them from the synch. The only recourse is to reinitialize the drive and resynch which takes 17+ hours. If I was 100% sure images stored IN music files on my desktop would NOT be sent to my iPod, I'd switch to embedded cover art.

We have a unique use case here where there are just as many images as tracks in a user library and they need to somehow be mapped to each other.

So how does properties-based control for image file naming help here then ?

You can name images just like any media provided its tagged as Alex mentions above, regardless of whether the media supports tagging or not.

What you can't do is map between the image & the media file on a 1-to-1 basis.

Iow say, this image file goes with this or that media file ?

other than manually

[Doof]

Well, it could be just a change to an already existing option. Rather than force the user to use [Artist] - [Album], just let us pick our own naming scheme. Then people can use it or not.

[Alex B]

Right now it uses [Artist] - [Album]

No, it does not. Don't believe everything you read...

If they changed it to [Album Artist (auto)] - [Album]

They don't need to. "AA(a)" has been in use for a long time.

[Doof]

Ah, so it lies to us.

[Alex B]

It's a white lie. The [Album Artist (auto)] concept is not something that new users would understand when they select their initial options.

[JimH]

It's a white lie.

Points for idiomatic speech!