That may make it easier to work out the source of the Cover Art. When running MC on a client, then the "Image File" tag shows the path and file name of the image. If an external image file is being used when running MC directly on a local machine, which may be a server, then the "Image File" tag shows the file name of the image. Note that "Image File" tag says "Inside File" if an image in a tag in the file is being used. MP3 and FLAC file tagging is very standardised, but WMA file tagging is not. But the format of the music file makes a difference.
I think Jaikoz does write Cover Art into tags, or at least has the option to. What kind of files do you primarily have? (MP3, AAC, FLAC, etc) I keep coming back to thinking that one of the two programs here is not embedding art work. Set scale to 100% and you'll definitely see what JRiver sees. To be super sure what art JRiver sees, I would play a few files and see the art displayed. I just re-read part of your comments and now I'm really not sure. My comment about the discussion about how JRiver presents choices of artwork through "get from internet" was because I don't understand how it's related. But my tests were VERY far apart, so I'm not sure. I only know had it build a few missing thumbnails in between it not working and later working. I'm not sure what made my smartlist work. I believe that reads tags and embedded art from the files whenever they change. Under configure audio import there's a checkbox option for "update for external changes".
#Jaikoz vs songkong update#
And given I have over 50,000 tracks, and around 17,000 of them appear in my lo-rez art smartlist - of which perhaps 20% are genuinely lo-rez, which then makes me doubt whether it's picking up all real lo-rez art - I'd really like to find a way to automate this process.ĭoes Jaikoz embed the art inside the file? If so, I don't know how JRiver would not see it *unless* you have JRiver set to NOT update the database from file tag changes. Wasn't aware that there was 'all the discussion about how JRiver shows possible artwork.' except insofar as it relates to the point about external taggers above. I can open the same tracks in JRiver and Jaikoz and each shows me different art.ĭo you have any idea what you (or it) changed so your non-working smartlist started working? Perhaps its the same problem mine has.
However, the art it adds often doesn't get picked up by JRiver - no idea where it goes. I've been a long term user of Jaikoz, principally because I used it before JRiver came out, and it aggregates all the major databases, often giving me additional information such as composer/s, and almost always finds the best available album art (or at least as good as I can find easily using Google images). (i) individual track appears in lo-rez art smartlist (ii) the art is not lo-rez (iii) the art is exactly the same as on every other track on album (iv) nevertheless, replacing the art on the whole album doesn't fix the problem.Įxternal taggers. And checked that they are all built.Ĭonfusion about individual tracks. And while you can do this album by album (rather than track by track), it's still pretty slow and pernickety.
So far the only way I can see to fix this problem is to find the image on the web somewhere, cut and paste within JRiver via 'cover art/paste from clipboard' then to do the right thing by everybody else, 'cover art/submit to internet' and finally 'cover art/get from internet' to see that it got there successfully. It also appears that the resolution that JRiver offers depends very much on what's already been put there - and if the 225 x 225 image is what I have, and it's the best that anybody else has, then that's what JRiver offers when you apply Cover Art/Get from internet - even if I've already put a much larger image there via Jaikoz (or any other metadata editor). It's not that png is the issue, as I have other situations with hi-rez (ie >1000px x 1000px jpgs) cover art, that still don't show in JRiver.Ĭlearly JRiver puts its cover art somewhere different within the metadata than most other metadata editors.