|
|
I fixed issue a) in build 1344, i.e. 'Album Art' -> 'Artwork'
The rest is opened, based on discussion via email, just remembering text from the last email from Jiri:
"ok, it seems to me that the best option would be to not include 'image cache' in 4.0, since it complicates things quite a lot (e.g. to implement its correct scanning) and in case there'll be a strong need for it, we can think about it for 4.1." |
|
|
|
OK, if we agree not to include the concept of an 'image cache' in the UI, then the UI could be simplified as follows (assuming all of the other requirements are to be met):
Options Panel
-------------
Artwork:
Audio Files:
Image location: _______________^ [[Save image to tag (if possible) otherwise save to file folder]; Save image to file's folder; Save image to tag (if possible) and to file's folder]
Image filename: _______________^ [Use custom filename, [Use folder.jpg if (if possible) otherwise use custom filename], Use original filename (not recommended)]
. . . . . . . _<filename>.thm_^ [Mask setter]
Video Files:
Image location: _______________^ [Save image to tag (if possible) otherwise save to album folder; [Save image to file's folder]; Save image to tag (if possible) and to file's folder]
Image filename: _______________^ [Use custom filename, [Use folder.jpg if (if possible) otherwise use custom filename], Use original filename (not recommended)]
. . . . . . . _<filename>.thm_^ [Mask setter]
[x] Confirm desired options on addition of Artwork
Note: 'Use folder.jpg (if possible)' means: use folder.jpg if Album/Series information is defined for all A/V files in a directory, AND all files are part of a common Album/Series
Note: The use of the .thm suffix so that files are saved in a format that will not be treated as images by photo scanning software (most presumably ignore 'folder.jpg' files)
Note: in cases where multiple AA images are stored for a single album, MM can just add suffixes e.g. <filename>_2.thm etc.
On all tagging Operations:
--------------------------
Title Bar: Add Album Art --> Add Image
On Auto-tagging Operations
---------------------------
Image to be saved to: _____________________ [tag, ..../<folder>/<mask>, tag and .../<folder>/<mask>] (note: this is greyed out--user can't actually make any config changes)
[ ] Apply to all files in the Album/Series
[ ] In the future, do not ask me
[Options] [OK] [Cancel]
Note: Auto-tagging dialog AA tagging options can be removed entirely.
On addition of Artwork via Properties Dialog
--------------------------------------------------
Change Tab: Album Art --> Artwork
Image Type: ___Front Cover____
Description: _________________
Image:
Image to be saved to: _____________________ [tag, ..../<folder>/<mask>, tag and .../<folder>/<mask>] (this is greyed out--user can't actually make any config changes)
[x] In the future, do not ask me
[Options] [OK] [Cancel]
Note: the folowing appears external to the dialog because multiple images are supported
[ ] Apply to all files in the Album/Series
Note: Removal of option to create a custom link
On addition of Thumbnails via Art & Details Window
---------------------------------------------------
Image Type: ___Front Cover____
Description: _________________
Image:
Image to be saved to: _____________________ [tag, ..../<folder>/<mask>, tag and .../<folder>/<mask>] (this is greyed out--user can't actually make any config changes)
[ ] Apply to all files in the Album/Series
[x] In the future, do not ask me
[Options] [OK] [Cancel]
Note: Removal of option to create a custom link
Back to the original requirements:
a) be generic to Music and Video (e.g. use Artwork instead of Album Art) - Ludek indicated this has been implemented.
b) allow for option to save to cache, and defaults that allow for multiple files within a single directory -- we've agreed to push this
c) store video artwork to directories in a fashion that will not cause it to be scanned as an image / photo (via use of .thm suffix)
d) limit use non-standard links (for which metadata is lost on rescan--this is implemented by limiting use of generic filenames to occasions when they won't cause conflicts)
e) make the options settings a bit more consistent
f) persist different settings based on File Type (e.g. Tags for audio, files for Video)
g) always give priority to Art that is stored to the tag/folder vs the cache |
|
|
Ludek
2011-02-11 15:06
developer
~0023014
Last edited: 2011-02-11 15:15
|
As discussed over email, there are still some questions:
1) Are we sure that we want to remove the
[x] Link to image file
option when adding Artwork?
As I remember we already tried to remove it in the past (MM3) and many users wanted this option therefore we added it as an alternative to the a common AA folder that was deprecated in MM3.
2) The config seems to me still unnecesarrily complex and hard to understand, especially options like "Use folder.jpg if (if possible) otherwise use custom filename".
I see your point that for videos (unlike audio files) can often happen that a lot of unrelated videos are presented in the same folder, but in such a case we could simply set the default mask to something like
[iff(<series>, <series>, <title>).thm]
or
[iff(<series>, <series>, <title>)/folder.jpg]
for videos and leave current [folder.jpg] for audio files? This would simplify things a lot, don't you think?
3) There is still a question why should be the filename config greyed out on addition of Artwork, is there a particular reason for this? We always allowed the config changes on addition, why should we deprecate it now?
|
|
|
|
1) In the new spec, users still have the option of linking to a file 'Use original filename (not recommended)' option. The new spec does 2 things, though:
a) it removes the need to choose image location each time the user tags an image (just as we don't prompt the user to choose ID3v1 vs ID3v2 each time they tag an MP3 file), thereby ensuring that the images are stored consistently in the collection.
b) it makes it more obvious what approach should be used.
2) I agree that the options are a little unclear, but would a mask really solve the problem? e.g. if the user has 10 different movies in a single folder, they're not part of a series, and yet, we need a way of storing Artwork for each film. How could we do so?
What we really need is a way of setting one mask for cases where only a single image exists in a folder, and another mask for cases where multiple images exist.
Image filename:
1 image per folder: _folder.jpg_ [mask setter]
> 1 image per folder: _<filename>.thm [mask setter]
What do you think? |
|
|
|
Sounds good, but I believe that the wording needs to be improved, what about:
Image filename:
First image in folder: _folder.jpg_ [mask setter]
Subsequent images in folder: _<filename>.thm [mask setter] |
|
|
|
The wording that I chose was intentional; if there's 1 image in a folder, then the first setting should be used. But if there's > 1 image, then ALL images should be named based on the second mask.
The rationale is that otherwise, on rescanning the folder, it would be unclear which artwork is associated with which file(s). (i.e. it would be impossible to determine which file(s) are associated with folder.jpg). |
|
|
Ludek
2011-02-14 10:09
developer
~0023068
Last edited: 2011-02-14 12:16
|
OK, just to be sure we are in understanding
1. Adding 1 image to a folder with files from various series/albums results in adding folder.jpg
2. Adding another image to the same folder results in adding <filename>.thm
=> AND according to your proposal MM is expected to change the former image from folder.jpg -> <filename>.thm ?
And what if user would apply the former image to whole album/series? Probably not a big deal, just the image filename will need to be updated for whole album/series?
So wouldn't it be better to use words instead of digits then?
i.e.
Image filename:
One image per folder: _folder.jpg_ [mask setter]
More images per folder: _<filename>.thm [mask setter]
|
|
|
|
I think we're not fully understanding each other:
1. Adding 1 image to a folder with files from various series/albums will add folder.jpg _only_if_ there exists a single album in the folder (i.e. if there are files from multiple albums, then the second mask should be used--even for the first album/artwork image) |
|
|
Ludek
2011-02-14 13:57
developer
~0023072
Last edited: 2011-02-14 14:47
|
OK, then:
Image filename:
The first image in folder with single album/series: _folder.jpg_ [mask setter]
Otherwise: _<filename>.thm [mask setter]
would be more accurate and an additional tooltip would be useful?
|
|
|
|
Image Filename:
First image per Album/Series: _folder.jpg_
Format for multiple images: _<filename>_X.thm
Tooltips:
1) This is the filename for the first image, as long as only a single Album, Series, or Movie is contained within the folder.
2) This filename is used whenever more than one image is stored to a folder. It is used a) for images other than the first image, when only a single Album/Series/Movie is contained within a folder b) for all images when multiple Albums/Series/Movies are contained within a folder. |
|
|
|
Fixed in build 1349 |
|
|
|
Tested 1349, but it doesn't seem to be fully implemented
1) Whenever the Art format doesn't match:
a) it takes ~10s for the conversion to occur--it shouldn't be noticeable to the user
b) if the user exits the auto-tag from web dialog before the 'Add Image' dialog appears, then the 'Add image' dialog appears behind the Auto-tag dialog, and cannot be accessed (the auto-tag dialog can't be moved).
2) In the Options dialog: the don't save image option should be removed
3) The various dialogs where Images are added to the files haven't been updated as per http://www.ventismedia.com/mantis/view.php?id=7070#c22386
Instead, they each have various differing options that conflict with the intent of the design which is to have this configured once globally in such a manner that would facilitate re-use of saved images if the database were corrupted (see attached images). |
|
|
Ludek
2011-02-16 13:02
developer
~0023140
Last edited: 2011-02-16 13:11
|
1a) I cannot reproduce, in my case it converts even large PNG (1 MB) file into JPG (217 KB) in a second. Could you send me your image to be able to reproduce?
1b) I cannot reproduce too:
- clicked the [Auto-tag] button
=> I cannot exit the Auto-tag from web dialog before the 'Add Image' dialog appears, because the action isn't performed on background, I guess you used some different steps?
2) Fixed in build 1350
3) I think that the dialogs are consistent and the image locations and filenames are there right (based on the general config in options). I don't think it is a good idea to forbid editing of them. If we would do so then the dialogs would became just an information dialogs and would be rather meaningless. Why should we remove a feature we have already added in the past and is useful for a lot of users? Shouldn't we just change the defaults of the checkbox
[ ] Confirm desired options on addition of Art
to be unchecked and thus the dialogs wouldn't be shown by default?
|
|
|
|
1a/b): I can't reproduce. I think MM must have been in a strange state, because 0007384 was also occuring consistently, but is no longer reproducible.
3) By inconsistent, I mean that for both the Auto-tag, and Art&Details versions of the dialog, the user can define an alternate format for saving the Artwork, that can conflict with the format defined in Options (e.g. User can change tag setting / save image to a different folder/filename than specified and set 'In the future do not ask me', which from a UI perspective would cause the user to think that they've configured new settings for how Artwork is saved. note: I'm not sure what actually happens, but the UI leads the user to believe that the configuration has changed).
My goal was to have saving of artwork be similar to the choice of tags (i.e. the user sets it once and doesn't have to think about it again) so that:
a) the ui would be simpler
b) the forced consistency would give a better experience for rescanning the library |
|
|
Ludek
2011-02-16 16:17
developer
~0023155
Last edited: 2011-02-16 16:18
|
OK, so then the issue is, that we should remove the
[x] In the future, do not ask me
checkbox, because it actually doesn't change config and is in fact duplicate of
[x] Confirm desired options on addition of Art
checkbox presented in Options.
And probably be better in defaults to uncheck:
[ ] Confirm desired options on addition of Art
?
|
|
|
|
The option to hide the dialog isn't the problem--the problem is that the user can hide the dialog having set a different configuration than is set in the Options dialog.
The intent was that the user should, upon first addition of Album Art, choose the format to be used (for any time Art is added in MM), and afterwards, to be exposed to as little of this complexity as possible.
i.e. the user would try to add AA
--> dialog appears (displaying the AA settings in a read-only manner), and allowing the user to click the 'Options' button to change the settings. User would change the settings, if desired, and then disable the option to see the 'Add Artwork dialog' so that this complexity would be completely hidden.
--> On future Artwork Addition, the artwork just gets added
The only downside with the above is that then the user isn't asked to choose _which artwork image is being added_ (e.g. cover, insert, etc). |
|
|
Ludek
2011-02-16 17:09
developer
~0023161
Last edited: 2011-02-16 17:16
|
1-I see your point, but the downside is that user cannot customize the rules just at the moment for the current addition. He needs to change defaults by going into options first and then change it back, this is a pain.
2-And also your approch implies removeal of the [x] Link to image file
i.e. your approach is more restrictive than the current
3-If we would just change the defaults and remove the "in the furute don't ask me" checkbox then your needs would be met without a downside
To understand: I like your approach, because it simplifies things for us, I am just afraid that there are users that wouldn't like it because of the downsides.
|
|
|
|
1-The question is "when would a user have a need to change the artwork saving format 'on-the-fly'?". My contention is that just as users of MM have no need to change tagging formats on the fly, they have no need to change Artwork formats on the fly. It's something that should be set once, and reconfigurable at any time, but it doesn't need to be in the users' face every time they save an image.
2-Right--as I described above, the user should choose the format for album art once, and MM should help the user enforce consistency rather than creating a collection where images are stored differently from one file to the next.
3-Thinking this through (and this conflicts with some of my previous statements about the design), the need to hide the 'Image location' section of 'Add Artwork' dialogs differs slightly for each of the three dialogs, and as a consequence, removal of "In the future don't ask me" applies differently to each:
a) The Add Artwork dialog for 'Art & Details'. This dialog _must_ always appear, because it has options which probably should never be hidden:
-Choose the image type
-Apply to all files in the Album/Series
i.e. The option to 'In the future don't ask me' shouldn't appear, and the Option to 'Confirm desired options on addition of Art' should have no effect on whether this dialog appears. However, this is also an argument to have an Options button vs. showing the Image Location options explicitly within the dialog (since it's strange to show the options even when the user has disabled 'Confirm desired options on addition of Art').
b) The Add Artwork dialog for 'Edit Properties'. This dialog _should_probably_ always appear because it has options to:
-Choose the image type
i.e. The option to 'In the future don't ask me' shouldn't appear, and the Option to 'Confirm desired options on addition of Art' should have no effect on whether this dialog appears. However, this is also an argument to have an Options button vs. showing the Image Location options explicitly within the dialog (since it's strange to show the options even when the user has disabled 'Confirm desired options on addition of Art').
c) The Add Artwork dialog for 'Auto-tag from web'. A confirmation dialog should not appear at all if the user has set the Album Art options to have it not appear.
i.e. The option to 'In the future don't ask me' _should_ appear within some variant of the confirmation dialog. By the same token, the dialog must make it obvious that any configuration changes made re. Image location are _Global_ (which is also an argument to have an Options button vs. showing the Image Location options explicitly within the dialog).
Note also: the Auto-Tag from Web dialog has the ability to set Options that conflict the with Artwork Options (click the 'Options' button at the upper right of the dialog). These options can conflict with the global Artwork options and should therefore be replaced with a single shortcut to 'Artwork Options...'
Summary: I agree that for 2/3 cases, the "in the future don't ask me" can be removed, but in thinking this through, it only makes it more clear to me that it would also be preferable to remove the 'Image Location' options so that they're not explicitly chosen within the dialog. |
|
|
|
Fixed in build 1350. |
|
|
|
I disagree that MediaMonkey should decide this for the user. Especially as I have seen some users that only embed the cover art for compatibility and save the rest of booklets that can run into several megabytes as external images to save space.
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=56687 |
|
|
|
It seems that the 'Confirm desired options on addition of art' is implemented only for Auto-tag from web. It's not implemented for:
Properties > Album Art, or Art & Details > Add image.
Note: 'Don't show this again' option should be removed, since this is now configured via the Options panel (and only in the options panel, since otherwise, it's unclear what 'this' (in 'don't show this again') is referring to. |
|
|
|
It has been implemented exactly according your spec in the note
http://www.ventismedia.com/mantis/view.php?id=7070#c23162
The Add Artwork dialog for 'Art & Details' _must_ always appear, because it has options which probably should never be hidden:
-Choose the image type
-Apply to all files in the Album/Series
and the rest is also implemented according your spec in the note. |
|
|
rusty
2011-05-04 19:31
administrator
~0024834
Last edited: 2011-05-04 19:31
|
I agree with that the Add Artwork dialog must always appear; the question is "what should be user-configurable on Art-tagging operations if the user has enabled 'Confirm desired options on addition of Art'. My thinking is that if the user leaves this checkbox enabled, then it means that they would expect to be able to the image location for the current operation and ignore the default setting.
At the moment, this is only possible for case 3c (auto tag from web). For case 3a ('Art and Details' > Add Artwork), and case 3b in the spec ('Edit Properties' > Add Artwork), the dialog always appears (as it should), however, if 'Confirm desired options on addition of Art' is enabled (in Options), the user doesn't get the ability to manually change the artwork location.
As far as implementation goes, there are currently 3 defaults that need to be supported:
i) Save image to tag (if possible) otherwise save to file folder
ii) Save image to tag (if possible) and to file folder
iii) Save image to file folder
I would propose that e.g. if the user chose i) as the default, and 'Confirm desired options...' is enabled, then the resulting dialog should include:
---------------------------
Image location: _Save image to tag (if possible), otherwise save to file folder_^
Image filename: _<shows name based on the masks in the default options>_
...other stuff depending on whether it applies... (e.g. Image Type, Description, Apply to all files in the Album/Series, etc.)
[Options] [OK] [Cancel]
----------------------------
If 'Confirm desired options on addition of Art' isn't enabled, then the Image location and Image filename entries can be greyed out, or not shown at all.
One final point in relation to the spec for item 3a,b,c (although the issue only applies to 3c since it hasn't been implemented for the other cases): "In the future don't ask me", should probably be eliminated as an option since it duplicates the functionality of the selector (i.e. if the user has selected 'Confirm desired options on addition of Art' in Options, then 'In the future don't ask me' can conflict with this setting.).
Note:
- The above changes don't require any new strings
|
|
|
Ludek
2011-05-04 22:32
developer
~0024842
Last edited: 2011-05-04 22:33
|
And wouldn't it make more sense to just make the 'Add Artwork' dialog in Auto-tag from Web window consistent with the 'Add Artwork' dialog elsewhere so that user could specify also 'Image Type' and 'Description' when auto-tagging from web?
Is there a reason why these two dialogs are different?
Note that this would result in removing the
[ ] Confirm desired options on addition of Art
entirely.
|
|
|
|
Eliminating [x] Confirm desired options on addition of Art could work except for the fact that it would introduce an extra step for the Auto-tag from Web dialog (the reason why the dialogs are different is that the Amazon Artwork is always Image Type=Cover, whereas for 'Add Image'/'Paste', the image might be a cover or something else).
On the other hand, Auto-tag from Web can use other services, which may yield Artwork other than covers--I'm not really sure... in which case the dialog should show the Image Type selector, which means that the "[ ] Confirm desired options on addition of Art" option could be removed (because it would always be possible to change the default options.
Maybe in the future, we might add a setting to the Artwork defaults to:
[x] Automatically save first image as 'Cover' |
|
|
|
Reminder sent to: peke, stephen_platt
Stephen, Peke, based on your experiences with other auto-tagging addons, does it make more sense to allow the user to set the Image Type when tagging via the Auto-tag from Amazon dialog?
note: even if the answer is yes, we could consider adding the selector directly in the Auto-tag from Web dialog. |
|
|
|
Discussed with Ludek over IM with the following result:
1. The current workflow when adding AA from the main MM window makes sense, no changes needed.
2. Showing any Add Artwork dialog when covers are added from Auto-tag from Web dialog doesn't make much sense, user will hardly ever need to change anything there, so this is just an extra step. So we can completely eliminate the older design 'Add Artwork' dialog.
3. Given 1&2, we can eliminate '[ ] Confirm desired options on addition of Art' option, since it isn't needed in either case.
4. Given 2., first-time user won't have any chance to modify default setting of AA storage (tag vs. file) when tagging from Amazon. It probably isn't a big deal, but we might consider moving Options\Artwork Options command in 'Auto-Tag from Web' dialog to a dedicated button next to Undo button in this dialog. |
|
|
|
I'm not quite sure I understand what you're proposing.
1. The main point of comment 24849 is that the current workflow doesn't meet users needs to sometimes override the default settings configured in artwork options (e.g. to add images other than the cover on a one-time basis to the folder and/or to change the filename of the image, when the default is to save to the tag). The current implementation doesn't support this, but MM3 does.
2. As with 1: the feedback that we've received is that some users do want to change Artwork options from the default on one-time basis, so the Auto-tag from web dialog should present the user with similar tagging options as are presented in cases 3a/3b (the only difference in this dialog is that there's probably no need to choose between Image Types).
3. TBD--need to first clarify 1&2.
4. See 2--I don't see why Amazon is a special case (from an Image Storage location perspective). |
|
|
Ludek
2011-05-05 14:12
developer
~0024863
Last edited: 2011-05-05 14:24
|
Rusty, but you previously proposed to eliminate the options, see item 3)
http://www.ventismedia.com/mantis/view.php?id=7070#c23152
and we finally concluded that we like the approach.
Namely (quotation):
3) By inconsistent, I mean that for both the Auto-tag, and Art&Details versions of the dialog, the user can define an alternate format for saving the Artwork, that can conflict with the format defined in Options (e.g. User can change tag setting / save image to a different folder/filename than specified and set 'In the future do not ask me', which from a UI perspective would cause the user to think that they've configured new settings for how Artwork is saved. note: I'm not sure what actually happens, but the UI leads the user to believe that the configuration has changed).
My goal was to have saving of artwork be similar to the choice of tags (i.e. the user sets it once and doesn't have to think about it again) so that:
a) the ui would be simpler
b) the forced consistency would give a better experience for rescanning the library
|
|
|
|
You're right--and user feedback proved me wrong.
Users are complaining about the loss in functionality (that they're no longer able to set exceptions to the default). What i didn't realize is that many users use this function in order to be able to save 1 image to a tag and others to the folder.
So the UI now _encourages_ consistency. We just need to let users deviate on occasion from the default. |
|
|
|
Based on latest comments and IM discussion with Rusty:
1. Add:
Image location: _Save image to tag (if possible), otherwise save to file folder_^
Image filename: _<shows name based on the masks in the default options>_
to Add Artwork dialog (as already proposed by Rusty in a comment above).
2. Use this dialog also for adding artwork from Auto-Tag from Web (i.e. discard the previously used and different dialog).
3. As for '[ ] Confirm desired options on addition of Art', let's try to eliminate it.
4. Remove Options\Artwork Options in Auto-tag from Web, since after 3. is implemented, it isn't useful anymore. |
|
|
|
Fixed in build 1370. |
|
|
|
Reopening since the source code contains warnings which should be reviewed (FormSongProperties.pas). |
|
|
|
Fixed in build 1371. |
|
|
|
Verified 1387 |
|
