SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Saving cover art as folder.jpg

#1

Hi there,
I have tried searching for this answer and came up empty - I hope this isn’t a repeat, if so, just point me to the answer, thanks.

I just started using jaikoz today, and am in the process of evaluating it. So far it’s quite interesting, that’s for sure!

My one beef, that I cannot seem to figure out is how can we also save the album art as folder.jpg in the album directory (and get moved over when correcting dirs from tags?

I like this so my jukebox software uses the jpg that gets downloaded by jaikoz.

thanks!

#2

Sorry, this cannot be done at the moment you would have to use another program to extract the artwork . But I do plan to add this functionality

#3

This is just what I was looking to do as well. Seems silly to have to use another program to do accomplish this when all the other elements are there.

Are we any further along to implementing this after all these months?

#4

Agree!!! This is the second most wanted feature for me, but I guess Apple doesn’t think this is a good idea? :stuck_out_tongue:

#5

Yes it should have been done, now would adding option Save Cover Art to File suffice or would it be better to have a configuration option which says when add artwork also save to file ?

#6

“Save cover art to file” in the right click drop down meny suffices. Tag&Rename has a function for saving cover art to folder.jpg as you correct tags/dl-metadata from the server - it could be a nice add, just remember the obvious: what to do if folder.jpg allready exists - rename or add suffix?
I agree with MaxSteele, but I think there should be an option to move ALL contents of the originating folder to the new/renamed folder. As a matter of fact this should be done by default, and the option should be to exclude other contents of the original folder on move. It’s quite nagging to have to move things manually each time you correct a folder from tags (other art, info.txt-files and so on), but I guess the routine for this would be rather complicated. What’s wrong with just renaming the folder, and then do a “move_all”? Actually you really don’t need to move anything unless you made an iTunes behavioral choice; to move the files to the iTunes directory - then you could discard all other data. And iTunes shouldn’t really have any problems with other than music-contents in the folders?
I want to be in control of my data, so I’ll never let iTunes copy any of my stuff. And as Jaikoz is still a third party app, I think it’ll benefit from leaving the choice up to us. I realize there must be quite a few choices to make when you do the programming: things should be as easy as possible, and still logical. Take a look at how VLC has organized the preferences menu, with an “advanced” option. And the need for an application other than iTunes to do advanced tagging must be the whole reason for Jaikoz in the first place! Making Jaikoz as flexible as possible, with the most obvious choices as default, but still able to do complex routines, will make it a “peoples choice” (- that’s my opinion though). :slight_smile: Good luck.

#7

Hi “Save cover art to file” has just been added to Jaikoz 3.7.0 Beta 3 give it a go.

But it just takes the simple approach of overwriting any existing folder.jpg , otherwise after running it a few times you would rapidly end up with folder(1).jpg, folder(2).jpg. If somebody has chosen the option I would think they would want the embedded artwork to take precedence over any existing folder.jpg but give it a go I’m open to changing it.

I may add the option of saving cover art to folder.jpg as you correct tags/dl-metadata from the server, but I would worry about users saving to file and then removing from the tag, this makes it very difficult for any subsequent Jaikoz updates to know what to do regarding finding artwork.

The issue of all items not being moved if the artwork is moved is another issue but is certainly valid and I need to get that sorted.

#8

Yeahh! Great.
My suggestion:

When saving cover art to file; if folder.jpg already exists: open a save_as dialog with the option to rename/replace or cancel.

Any existing folder.jpg in the base folder should take presedence over server data, except if otherwise is specified in preferences:

  • Reducing traffic
  • Keeping user data is preferable. (actually: never owerwrite user data except through dialog)

Add artwork if empty? or add artwork until max nr of jpg’s as chosen in preferences? I don’t know the inside of Jaikoz, so you’ll have to think it over.

Myself: I’d prefer just one cover art file for each album or file if you like.

Keep up the good work!

#9

Sorry: I did mean subfolder, not base folder. :slight_smile:

#10

[quote=nissene]Yeahh! Great.
My suggestion:

When saving cover art to file; if folder.jpg already exists: open a save_as dialog with the option to rename/replace or cancel.
[/quote]

“Niks”, :).

I’d like to see Jaikoz work as much as possible in batch-mode (and file-by-file).
Meaning, no user interaction after you’ve set it to auto-correct.

I really don’t think this preference requires any explanation, but consider that some of us have rather large collections.
[/quote]

#11

Agree, except what we’re discussing is not a part of the batch, but drop down type dialog? Or am I missing something?

#12

[quote=nissene]Yeahh! Great.
My suggestion:

When saving cover art to file; if folder.jpg already exists: open a save_as dialog with the option to rename/replace or cancel.

Any existing folder.jpg in the base folder should take presedence over server data, except if otherwise is specified in preferences:

  • Reducing traffic
  • Keeping user data is preferable. (actually: never owerwrite user data except through dialog)
    [/quote]
    You are confusing two things here, I’m saying artwork embedded in the music file should take precedence over a jpg file that happens to be in the same folder as your mp3’s. The ‘Save Artwork to Filesystem’ does not get data from the server, you can already specify whether to overwrite your artwork metadata when correcting from Musicbrainz or Discogs through the Preferences/Musicbrainz/Format/Artwork and Preferences/Remote Correct/Discogs/Artwork options

Its not in the Autocorrecter (at the moment) but it is a batch task, you can perform for all files, not just one file at a time. Give the Beta a go and I think it will be clearer.

#13

OK. Had a shower and a thought!

For the “auto correct” procedure there should be a preferences choice:
‘Save cover art as folder.jpg’
Option:‘Keep local folder.jpg’/‘Overwrite local folder.jpg from server’

From the Artwork tab: add ‘Save’.
if folder.jpg exists in the subfolder: open save_as dialog
otherwise save folder.jpg
from the right click menu add the same procedure, or when rightclicking on the actual cover art picture you could make a choice to save cover art and use the same procedure as ‘save’ from the Artwork tab.

What about that, then
MAzE5h1p69wB?

#14

OK
I’ll give the new Beta a chance. But it’s friday evening here now, so it’ gonna have to wait until tomorrow. :smiley:

#15

Couldn’t really wait…
Well this works, but it’s kind of rude. If you could add the ‘save’ button from the artwork tab with the before mentioned: check if folder.jpg exists-routine, that would leave us a chance to keep allready existing folder.jpg’s.
Or better: Simply add a dialog before writing: Keep existing folder.jpg’s: Yes/No? and then do the check. Guess it’s gonna slow it down a bit, but it’s absolutely worth the waiting.
Happy weekend!

#16

[quote=nissene]OK. Had a shower and a thought!
[/quote]

Yay! I kid, I kid.

Well I see it as an all or nothing kind of deal.

There’s no reason to keep the existing folder-image, if Jaikoz fetches the correct one (which may well be a higher resolution one).

Either you trust Jaikoz (and musicbrainz and so on) when you ask it to fix your metadata, or you don’t.

Of course, some asshat could have uploaded a 1x1 pixel image, which would instantly overwrite your precious, precious 1280x1028 one, but given that the resource-databases are contributed to and checked by others, silliness like that would be fixed quite soon.