Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Album Art Downloader XUI (Read 2051327 times) previous topic - next topic
0 Members and 7 Guests are viewing this topic.

Album Art Downloader XUI

Reply #1225
AlexVallat
What about support APEv2 tags of TAK files in 'File Browser'?
when I drag-and-drop TAK files in a File browser window - AAD does not read tags
but all is well with MP3/WAVPACK/MUSEPACK/APE (APEv2 tags) files.
In 'foobar browser' all ok.

Album Art Downloader XUI

Reply #1226
I have one more problem..

I have this track:11. Рубль - Обезьяна.mp3 (it is free track):


preference page in foobar2000 v1.0:


when I drag-and-drop this file in ADD File Browser (problem with tags?):


then I open mp3tag and click save:


size unchanged


but..
then I drag-and-drop this file in ADD File Browser and all is well:


where is the problem?

Album Art Downloader XUI

Reply #1227
What about support APEv2 tags of TAK files in 'File Browser'?
It doesn't look like TAK is one of the supported file types by TagLib, sorry.

I have one more problem..
That mp3 file, as downloaded, has slightly corrupted ID3 info. As with the previous case, the artist name has not been null terminated. In this case, it is in UTF-8 (type $03), so only needs one null to terminate rather than two, but it doesn't have any! I don't know what piece of tagging software is missing off the tag terminators, but something is doing it.

Rewriting the tags with Mp3Tag fixes it because Mp3Tag writes them out properly. I'm guessing the file size doesn't change because tags involve padding to make sure they align on specific boundaries, and adding a single byte (the null terminator) to a tag isn't pushing it over the next boundary, it just has a little less padding.

The only thing I can suggest is the same as I suggested to helstegt, use Mp3Tag to rewrite all your tags (should just be a simple operation) and they'll be fine, or use the Foobar browser instead of the File browser, as Foobar seems to be more robust to slightly malformed tags.

Alex

Album Art Downloader XUI

Reply #1228
Hi! The AllCDCover Plugin seems to be broken. Or disabled ACC their API?


Album Art Downloader XUI

Reply #1230
i see.. some covers seems to be broken... but today i checked the one which doesn't worked ysterday and today it works. If i find another one which doesnt work i will post that album, so you can check that

Album Art Downloader XUI

Reply #1231
sorry i cannot find the Edit Button O.O

nit happend again today...  the album was Borknagar - Epic.  It loads a dummy pic which says: "Ooops, so ething went wrong.. like you followed an old link "

Album Art Downloader XUI

Reply #1232
hm..now the Edit Button appeared but i dont have the permission to edit my own posts 
This picture appears:



Album Art Downloader XUI

Reply #1233
It's always a good idea to search the topic first (field under the last post).

Quote
...AllCDCovers...
...protection...irritating, but I'm not going to spend too long trying to work around it and get into some sort of arms race.
I completely agree with you. We (users) can still wait the 15 minute grace period (as Akkurat pointed out) or just follow the link and type the captcha if we can't wait at all to get the image.

Hmm, I may have phrased my previous answer a bit oddly (didn't remember the full story and I glanced the post I made in 2008 too quickly). The about 15 minutes is the time when you can see the images in the result list, after that EVERY search to AllCDCovers will yield the leech prevention images only (there seems to be an IP detection too, not just the "hash" I wrote about). At least that's how it was back then. Below is a quote from the post I linked to:

...So, it seems that this would happen in AAD if user searches some covers and doesn't touch the results for a while. After that "don't leech" image, all subsequent searches would yield only thumbnails (or possibly the "don't leech" image) for X amount time which has been set by AllCdCover in the server side. Yes, it's definitely an IP address leech prevention; right after the both above image URL's "failed/timeouted", all my AAD searches started to show only thumbnails.

I then waited about 20-30 minutes and ran AAD search again, still thumbnails. Then some browsing in their website, all full size images load up fine. Back to AAD, still thumbnails. Tried to close&reopen AAD, nope, still doesn't work.  Nasty leech prevention.




This is the 3rd time already, Alex I think that you need a FAQ.

Album Art Downloader XUI

Reply #1234
It's always a good idea to search the topic first (field under the last post).

This is the 3rd time already, Alex I think that you need a FAQ.

Hah, I'd forgotten about that AllCdCovers thing myself!

You're right, of course, there should be an FAQ. And a manual. And a proper website. Any volunteers?

Album Art Downloader XUI

Reply #1235
I'd love to help you out but I've my own problems of allocating time to do everything.  Doesn't sourceforce have a feature which you could use to house the FAQ? Though a proper website would be much better.

Album Art Downloader XUI

Reply #1236
When I'm using the Foobar2000 Browser it shows some albums don't have covers. It's incorrect because they do have covers, but they are inside the id3 tag. Is there a way to scan those as well to eliminate redundancy?

Thanks,

Dennis

Album Art Downloader XUI

Reply #1237
Hi Alex, using the "stop all" feature while "search firsts" are searching (none results yet) just stops (=skips) the "search first" and continues with the "extended search", wouldn't it make more sense to stop everything? Not a biggie, just noticed this minor annoyance/inconsistency today.

Album Art Downloader XUI

Reply #1238
they do have covers, but they are inside the id3 tag. Is there a way to scan those as well to eliminate redundancy?
Not at present. Embedded image support (both reading and writing) is already on the feature request list, and may someday make it into a future version.

Hi Alex, using the "stop all" feature while "search firsts" are searching (none results yet) just stops (=skips) the "search first" and continues with the "extended search"
Yes, that's a bug, I've added an issue for it. Thanks for reporting it.

Alex

Album Art Downloader XUI

Reply #1239
If I download PNG images using the program, they all get saved pitch black (fairly reduced gamma or something). Is this a common bug or is there a problem at my end?

Example, in case you'd like to try reproducing it: Gas - Zauberberg front cover from last.fm covers.

EDIT: Well, further examination shows that I can download last.fm artist PNG images without problems using the program. Maybe it's something about the last.fm cover image source code on their site?

Album Art Downloader XUI

Reply #1240
Gas - Zauberberg front cover from last.fm covers.
I tried searching for this, and got one result. It was a jpeg and looked fine to me. Can you give any other examples that show the problem for me to try?

Thanks,

Alex

Album Art Downloader XUI

Reply #1241
Gas - Zauberberg front cover from last.fm covers.
I tried searching for this, and got one result. It was a jpeg and looked fine to me. Can you give any other examples that show the problem for me to try?

Thanks,

Alex
It shows up as JPG file to you? That's odd. Here's a screenshot:



As you can see, it shows up as PNG for me. This is what I get when I download the file:



The cover is there, but it's barely visible.

But try Moonblood - Taste Our German Steel, also from last.fm covers. It shows up as PNG for me and gets saved pitch black just like that GAS cover does.

And in case you're wondering, I'm using the latest version of the program. I updated after finding out about this, but the problem persists.

Album Art Downloader XUI

Reply #1242
OK, I'm getting a .png now, but not the darkened effect, on either example. That's weird. I'll have a look around and see if I can find any info on png saving issues in .net (as it appears to at least be displaying correctly).

Alex

Album Art Downloader XUI

Reply #1243
Right, cheers.

I'm also digging into it. I'm running Windows XP SP2 with .NET 3.5 SP1 on this machine which gives me the pitch black PNGs, but I haven't been able to reproduce the error yet on my laptop which runs Windows 7 (not RTM).

It's quite odd saving artist PNGs works though.

Album Art Downloader XUI

Reply #1244
I tested it on a third machine which runs Windows XP SP3 with .NET 3.5 SP1 and it gave me those black PNGs as well. So to me it at least seems that the problem lies somewhere in Windows XP, but I'm no programmer so I have no actual knowledge on this matter.  You probably know better.

Album Art Downloader XUI

Reply #1245
WinXP SP3 here and same thing with that png. Searched the cover with the api commands and saved it from Opera = correctly saved. So it's probably .NET in WinXP.


While I was searching the same cover from the last.fm site (couldn't find it first (from the webpage).. then used the api method), I stumbled onto something good: last.fm has (for some albums, tested only couple) 600x600px album covers too! They're just "hidden".

Found it when checking the source of the Zauberberg album webpage (http://www.last.fm/music/Gas/Zauberberg). The revealing bit:
Code: [Select]
"original":"http:\/\/userserve-ak.last.fm\/serve\/_\/41520903\/Zauberberg.png"
->
http://userserve-ak.last.fm/serve/_/41520903/Zauberberg.png

And when later checking/testing out the api (image) results, discovered 2 alternative links:
Code: [Select]
http://userserve-ak.last.fm/serve/_/41520903/41520903.png
http://userserve-ak.last.fm/serve/_/41520903.png

Now, the api returns the following info (for this album):

Code: [Select]
<image size="small">
http://userserve-ak.last.fm/serve/34s/41520903.png
</image>
<image size="medium">
http://userserve-ak.last.fm/serve/64s/41520903.png
</image>
<image size="large">
http://userserve-ak.last.fm/serve/174s/41520903.png
</image>
<image size="extralarge">
http://userserve-ak.last.fm/serve/300x300/41520903.png
</image>

I guess it would be "relatively easy"  for a BOO expert to add a check if the "original"/biggest cover exist at all and choose that cover instead.

I seem to enjoy "detective work".. too much.


P.S. Compared "hidden" Zauberberg 600px last.fm cover to the 600px (jpg) Album Art Exchange cover and they seem to be identical, except gamma/brightness. Interesting.

Album Art Downloader XUI

Reply #1246
Ahh, remembered another problem: Coveralia script doesn't work properly with "various" albums. It shows  " -  - Frontal/Back/etc." for the "title". And it of course affects the %name% variable. Parsing (regexp?) problems? Just try searching e.g. various / disco.

Album Art Downloader XUI

Reply #1247
WinXP SP3 here and same thing with that png.
I haven't had any luck finding any information about why .net (or GDI+, which is what it uses internally) would fail to save .png files correctly under XP SP3. I'll keep an eye out, though, and if I find anything I'll update.

For the hidden last.fm covers, the only thing I can think of would be to check if there was a file with the same name as the album name - but is that likely to always be the case? I suspect that there's no consistent naming scheme for them (just whatever filename they had when uploaded), which is why they aren't returned by the API. I could request the web page and parse the original out of that, but that's not a great solution. I'd much prefer to stick to the API where available.

Coveralia script doesn't work properly with "various" albums.
Thanks, I've fixed this and pushed out an update to v0.10 for that script.

Alex

Album Art Downloader XUI

Reply #1248
For the hidden last.fm covers, the only thing I can think of would be to check if there was a file with the same name as the album name - but is that likely to always be the case? I suspect that there's no consistent naming scheme for them (just whatever filename they had when uploaded)

I think you missed one thing:

API gives out an ID which could be used to fetch the "hidden" bigger* cover.

API: userserve-ak.last.fm/serve/[34s / 64s / 174s / 300x300]/41520903.png

Hidden (alternative 1): userserve-ak.last.fm/serve/_/41520903.png
Hidden (alternative 2): userserve-ak.last.fm/serve/_/41520903/41520903.png

And optionally checking with the (url-encoded?) album name:
Hidden (alternative 3): userserve-ak.last.fm/serve/_/41520903/Zauberberg.png

Last resort.. but I don't think that it's needed after checking the 2 alternatives above.. in fact, I really think that checking only 1 of these alternatives would suffice.

* Not always, couple of my tests showed that this was the same size as the 300px from API.. nevertheless, the "hidden" one would always return the biggest cover available, so it should be selected 1st if available.

Thanks for the super fast update, again! If only other devs could match your support..

Album Art Downloader XUI

Reply #1249
Experimental LastFM Cover update
I've modified the LastFM script, as suggested, to check for a hidden larger image. It will try to find an image of the size '_' (HTTP HEAD request), and if it doesn't receive an HTTP error response, assumes that it's a better result than the named sizes available. Unfortunately it won't know what size that image might be, so the size will display as Unknown until the full size image is downloaded.

lastfm-cover.boo

I'd appreciate any feedback on this, in particular if you find albums where the hidden image is not available (you can tell because the size won't be Unknown), or is smaller than 300x300, or wrong in some other way.

Thanks,

Alex