INTERACT FORUM
More => Old Versions => Media Center 12 (Development Ended) => Topic started by: Mr ChriZ on June 06, 2008, 05:54:55 am
-
The Cover Art retrieval tool is quite impressive now adays,
but quite often it can't find cover art because the tags of an album aren't quite right.
For example a disc I just searched on:
Jeff Buckley: Sketches for My Sweetheart the Drunk (Disk 1)
retrieved no cover art.
Re-tag it to
Jeff Buckley: Sketches for My Sweetheart the Drunk
and cover art is found.
How about if the tool doesn't find anything, it cuts characters
of the end of the album name, until it does find something, and
then displys it as the closest match?
-
Trimming characters off the end isn't the way to go. Lookups are expensive, and repeated lookups would cost a lot.
The fuzzy matching usually does quite a nice job. This is a case where it isn't though. I'll look at fixing it, but it would be just a small tweak that only helps in a few cases, and requires a large change in the code, so unless something else comes up that needs the same change, it may be a while.
j
-
When I get an album name from YADB that includes (Disk 1) or similar extra data, I put the disk number in the Disc # field and delete it from the Album name. After that correction, the cover art is much more likely to be found.
However, manual cleanup happens AFTER the rip automatic cover art lookup. I usually rip a bunch of CDs, then go back in and clean them up, then try to add correct cover art. But I find the "new" manual cover art dialog cumbersome to use (various comments/suggestions in an earlier thread). So I resort to external cover art searches (Google, Amazon, etc) or scanning of my jewel case cover (I wish that was more streamlined in locking in the image shape and resulting image size for repeated operations).
Is there an in-between MC option, a way to trigger background cover art lookups (perhaps of selected tracks) similar to how it's done when ripping, but to be used after album and artist data has been cleaned up? Running in the background would avoid having to deal with the manual cover art dialog?
One area where lookup retry could be useful is with multi-artist albums. I have many of these and almost never find one in YADB, possibly because lookup is trying to find the Album title BY the track's Artist name. I find them readily in Google Images or Amazon. Maybe cover art lookup can notice when an album's several tracks have different artists, and do a lookup on the Album name alone? I know that will sometimes yield multiple hits ("Greatest Hits", etc), but that might be better than no results.
Also on my wish list, multiple-artists albums vs. cover art files. When looked up, scanned, or pasted, MC creates one .jpg for EACH track (because of Artist - Album naming). But each such image is identical, and with hundreds of such albums, there are literally thousands of duplicate images taking up space. Ideally with multiple artists there would be just one image per album, which I can do by manually saving the image, giving it a suitable name (va_album, usually, va being record-industry standard "various artists"), then manually attaching it to the tracks. It would be cool if MC could recognize a multi-artist album, and when MC is assigning the image file name, use a user-specified different naming convention. (I know, the Album Artists field can be used for something like this, but its behavior doesn't match the structure of my library.)
-
Would it not be better to remove () and [] and the contents than the ending?
-
Would it not be better to remove () and [] and the contents than the ending?
I agree, but many new users might just think oh this cover art tool is useless,
when in reality it's just because the tags aren't as someone else has them.
I was thinking the server could do the removing of characters rather than the client,
but I guess it don't work that way.
-
One area where lookup retry could be useful is with multi-artist albums. I have many of these and almost never find one in YADB, possibly because lookup is trying to find the Album title BY the track's Artist name. I find them readily in Google Images or Amazon. Maybe cover art lookup can notice when an album's several tracks have different artists, and do a lookup on the Album name alone? I know that will sometimes yield multiple hits ("Greatest Hits", etc), but that might be better than no results.
I've been asking for something similar for years. Cover art on compilations fails for me a lot. If an album contains multiple artists the search should use 'various artists' + album name. This almost always returns perfect results in google and amazon.
As an aside to this, I never understood why 'multiple artists' and 'assorted' where used instead of the much more common 'Various Artists' for the album artist(auto) field and renaming of folders. Instead of being able to set my rename folders to album artist(auto) I've had to set up a custom field and do some jiggery pokery to get my folders named as Various Artist.
Finally, I think the Disc # field is cool, but it would be much cooler if we could specify somewhere what text we wanted to use when naming files & folders using the Disc # field. So for example if Disc # is filled in with '1' I can get it to write '[Disc 1]' to the folder. The benefit of this is that I get a decently named folder and at the same time [Disc 1] doesn't interfere with the image search as it is no longer in the Album Name field.
Maybe an option to attempt to move (Disc X) and its variants into the Disc # field when reading from YADB would be cool too.
-
As an aside to this, I never understood why 'multiple artists' and 'assorted' where used instead of the much more common 'Various Artists' for the album artist(auto) field and renaming of folders. Instead of being able to set my rename folders to album artist(auto) I've had to set up a custom field and do some jiggery pokery to get my folders named as Various Artist.
It could be "Various Artists" or 'Varios Artistes' or any of a bunch of different language spellings. Also, many times a CD
is attributed to Time-Life or K-Tel or one of those companies that specializes in putting out compilations. I think this
is a reasonable thing to do.
j
-
What I do when it can't find cover art, I often go to Amazon.com and
select the CD first, then click on cover art and 'save as picture' to my
my cover art file, then attach it to my songs. I've had to do this to
many CDs especially if they are older ones.
Skylar
-
One area where lookup retry could be useful is with multi-artist albums. I have many of these and almost never find one in YADB, possibly because lookup is trying to find the Album title BY the track's Artist name. I find them readily in Google Images or Amazon. Maybe cover art lookup can notice when an album's several tracks have different artists, and do a lookup on the Album name alone? I know that will sometimes yield multiple hits ("Greatest Hits", etc), but that might be better than no results.
Also on my wish list, multiple-artists albums vs. cover art files. When looked up, scanned, or pasted, MC creates one .jpg for EACH track (because of Artist - Album naming). But each such image is identical, and with hundreds of such albums, there are literally thousands of duplicate images taking up space. Ideally with multiple artists there would be just one image per album, which I can do by manually saving the image, giving it a suitable name (va_album, usually, va being record-industry standard "various artists"), then manually attaching it to the tracks. It would be cool if MC could recognize a multi-artist album, and when MC is assigning the image file name, use a user-specified different naming convention. (I know, the Album Artists field can be used for something like this, but its behavior doesn't match the structure of my library.)
MC always uses the fields "Album Artist (auto)" and "Album" for the cover art lookup and for naming the downloaded cover art files (unless the "folder.jpg" option is selected). If you don't organize your library so that each multiple artists album has a single "Album Artist (auto)" value the tool cannot work as designed.
-
As an aside to this, I never understood why 'multiple artists' and 'assorted' where used instead of the much more common 'Various Artists' for the album artist(auto) field and renaming of folders. Instead of being able to set my rename folders to album artist(auto) I've had to set up a custom field and do some jiggery pokery to get my folders named as Various Artist.
(Multiple Artists) is the default value, but you can always override it by writing something in the separate "Album Artist" field. The "Album Artist (auto)" field will change automatically.
-
Finally, I think the Disc # field is cool, but it would be much cooler if we could specify somewhere what text we wanted to use when naming files & folders using the Disc # field. So for example if Disc # is filled in with '1' I can get it to write '[Disc 1]' to the folder. The benefit of this is that I get a decently named folder and at the same time [Disc 1] doesn't interfere with the image search as it is no longer in the Album Name field.
This part or your post is actually OT in this thread, but you can add text strings to the naming rules.
For instance, here are my naming rules:
Directories:
[Album Artist (auto)]\[Album]\
Filename:
If(IsEmpty([Disc #],1), [track #], CD[Disc #] - [track #]) - If(IsEqual([Album Type], Multiple Artists /(complete/), 1), [Artist] - [Name], [Name])
Some examples of the resulting filenames:
Single Artist, no disc number:
\The Cure\Japanese Whispers\06 - Speak My Language.mp3
Single Artist, disc number:
\Bob Marley & The Wailers\Burnin' (Deluxe Edition)\CD2 - 08 - Kinky Reggae.mp3
Multiple Artists, tagged Album Artist, no disc number:
\Tiësto\Elements Of Life\03 - Tiësto feat. Julie Thompson - Do You Feel Me.mp3
Multiple Artists, automatic Album Artist value, disc number:
\(Multiple Artists)\Champs-Élysées Café\CD2 - 04 - Chateau Flight feat. Beretta 9 - Down At The Rotisserie.mp3
-- The text string "CD" will be added if the "Disc #" field has a value.
-
i've been playing with the "get cover art from internet" over the past few days as well, after not having touched it in awhile. i LOVE the new interface, where i can now see what it's getting and can tell it what is good and what is not, but i don't like being tied to YADB for art lookup. why can't i specify a source? i seem to recall that we used to be able to choose amazon or google. i listen to a lot of mighty obscure stuff, and i'm literally finding less than 10% of my art on YADB. so, for me at least, the new interface is one step forward, one step back.
now, what would be really awesome is if i could use discogs as a source. whooooo... ;)
EDIT: here's another odd one - the limitation to 20 albums in a lookup window. the limitation is fine. it looks up 20, then goes on to the rest. the problem is, when i click on "save & continue", it doesn't actually continue. i look up again, then "save & continue" works. it seems to only continue if you make no changes to the initial 20 albums' cover art.
-
Trimming characters off the end isn't the way to go. Lookups are expensive, and repeated lookups would cost a lot.
The fuzzy matching usually does quite a nice job. This is a case where it isn't though. I'll look at fixing it, but it would be just a small tweak that only helps in a few cases, and requires a large change in the code, so unless something else comes up that needs the same change, it may be a while.
j
The "disc 1" problem isn't a "few cases" thing -- lots of tagging software puts that in the name automatically. All my files are tagged by musicbrainz, for example, so the album art lookup is almost totally useless. Would appreciate a fix -- surely there must be some way of handling this and similar name matching problems.
-
The "disc 1" problem isn't a "few cases" thing -- lots of tagging software puts that in the name automatically. All my files are tagged by musicbrainz, for example, so the album art lookup is almost totally useless. Would appreciate a fix -- surely there must be some way of handling this and similar name matching problems.
I've seen YADB do this too, also I'm not sure if this is still the case but for a long time it didn't actually support the disc field.
-
Thanks for the replies Alex and John. Very helpful with the Disc# stuff Alex.
MC always uses the fields "Album Artist (auto)" and "Album" for the cover art lookup and for naming the downloaded cover art files (unless the "folder.jpg" option is selected). If you don't organize your library so that each multiple artists album has a single "Album Artist (auto)" value the tool cannot work as designed.
While it's great that the cover art look-up is using Album Artist(auto) it still causes the same problem - searching 'Multiple Artists' isn't going to be of much use finding an album when the sources of such images don't use that text. The reasons for not using 'Various Artist' (language variation etc) are NOT reasons for using 'Multiple Artists' or 'Assorted' either.
-
While it's great that the cover art look-up is using Album Artist(auto) it still causes the same problem - searching 'Multiple Artists' isn't going to be of much use finding an album when the sources of such images don't use that text. The reasons for not using 'Various Artist' (language variation etc) are NOT reasons for using 'Multiple Artists' or 'Assorted' either.
... I've had to set up a custom field and do some jiggery pokery to get my folders named as Various Artist.
I just tried to say that you don't need to use a custom field and do "jiggery pokery" for changing the default Album Artist (auto) value and for being able to use it in the naming rules. Just type the desired value in the separate Album Artist field.
Naturally, this doesn't resolve any cover art lookup problems.
-
Back to the topic: "Improving the intelligence of get cover art"
IMHO the current level of intelligence is good enough. The solution would not need to be a more intelligent automatic system. If and when the automatic lookup doesn't work the user should be allowed to use personal intelligence and try a different search criteria manually.
I have explained how a "Custom lookup for single cover art images" feature could work here:
http://yabb.jriver.com/interact/index.php?topic=46129.msg316211#msg316211
EDIT
After each succesful manual lookup the system could automatically improve the level of its intelligence by adding the user's real tags to the cover art database (i.e. the system should not stupidly use only the tags that were typed in the manual query).
-
What Alex said sounds good =)
-
I think Alex' idea is not such a good one. It is NOT so hard to build a smarter search that this task should be dumped back to the user.
-
I am not against anything that would make the system more intelligent. However, an automatic system cannot possibly handle everything. There will always be cases when a manual search would probably work better and as I explained, the automatic system could learn from every succesful manual search. Here is one of my posts from the beta board:
Perhaps my Elvis example wasn't very good. Classical music would provide better examples of possible tag variances.
For the same album the artist can be e.g.
- Beethoven
- Ludvig Van Beethoven
- Karajan
- Herbert Von Karajan
- Karajan & BPO
- Beethoven (Berlin Philharmonic Orchestra & Karajan)
- etc
and the album name can be
- Symphony No. 3
- Beethoven's 3rd symphony
- Eroica (3rd symphony)
- etc
It is nice that you have been able to add some fuzzy logic, but an automatic system can work only up to a certain extend. It can easily happen that the user misses a valid cover art image. A possibility to try different search strings is needed.
I also posted several real-life examples, which didn't work when the system tried to be too clever. For instance, at one stage during the development it ignored everything that was in parenthesis:
Also, my older test case is not working yet:
Eric Clapton - 461 Ocean Boulevard (MFSL)
I have submitted the MFSL version cover art:
(http://www.pix01.com/gallery/4AD73041-94E6-4810-80BE-EDB7F3274485/461_ocean_boulevard/8000417460.jpg)
However, the system completely ignores the file I have submitted and can find only the standard cover art:
(http://www.pix01.com/gallery/4AD73041-94E6-4810-80BE-EDB7F3274485/461_ocean_boulevard/8000417461.jpg)
-
I am not against anything that would make the system more intelligent. However, an automatic system cannot possibly handle everything. There will always be cases when a manual search would probably work better and as I explained, the automatic system could learn from every succesful manual search.
There already is a manual search - google & cut & paste, which is what I have to use now. The automatic system's inability to match all file names perfectly is not a reason to abandon the project of improvement.
Having the automatic system "learn" from manual searches seems like a far more complex project than MC is likely to take on, but maybe I'm wrong.
-
I don't think creating a simple manual tool would reserve JRiver's resources significantly. The tool would mostly use the existing code. Adding a couple of dialog boxes for bypassing the default tags would probably be a routine task for the developers.
Similarly it would not be difficult to make system learn from the user action. It could simply submit the selected image with the real library tags. Since the tool would be for single albums it could use the tags from the first selected file. Though, naturally, it would consume less bandwidth if it could just send the tags and the server would link them with the chosen image file.