View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001585 | MMW v4 | Properties/Auto-Tools | public | 2004-11-09 05:23 | 2004-11-11 14:22 |
Reporter | rusty | Assigned To | |||
Priority | immediate | Severity | text | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Summary | 0001585: Album Art Terminology Changes | ||||
Description | As requested, here are all the Album Art-related terminology issues that I've noticed: In the Dialog Title Bar and Config (as already discussed): Selected Album Cover --> Album Art Now Playing Album Cover --> Album Art (Now Playing) Track Properties Dialog (+ Mass edit version): Covers --> Album Art Cover Properties Dialog: Cover Properties --> Album Art Properties Picture Type --> Image type & change default value from Not Specified --> Cover (front) Store picture in: --> Store image to: Tag --> Tag (if possible) Picture Types: Cover (Front) --> Cover (front) Cover (Back) --> Cover (back) Band LogoType --> delete this Publisher LogoType --> delete this Question: If Album Art is saved to a file, where is the file's location? (I couldn't find it in the Track's directory or in a /MediaMonkey/Album Art directory...) | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
Fixed in build 805, except for: - Default value of Image Type wasn't changed to Cover (front). MM currently tries to get this value (either directly from tag, or guess it from .jpg filename - e.g. if it contains words 'front' or 'back'). In case it cannot find any suitable value I think it's better to keep unspecified there. - Band LogoType and Publisher LogoType weren't removed, they are part of ID3v2 standard and are used e.g. by WMP, thus removing would cause problems. - Do you mean if user specifies to store image in 'External File'? In that case the file is kept in the location from which user 'linked' it to the track. |
|
RE. Default value of Image Type: I'm not referring to the value that is automatically assigned when a scan occurs. I'm referring to the value that is assigned when the user manually adds a cover--right now, with every cover that I add, I have to manually change this value to Cover (front)!! Re. 'Store to external file'. I misunderstood the functionality--I thought that mm was copying the 'temporary' file that I'd downloaded to the 'correct' location. Given the current functionality, the wording should be changed to: Image location: (o) Store image to tag (whenever possible) ( ) Link to image file... Note: I would prefer the following, though it implies some additional functionality: Image location: (o) Store image to tag (whenever possible) ( ) Store to image file . . (o) Link to image in current location . . ( ) Move image to track's directory |
|
Fixed in build 805. Re. Default value of Image Type: I think that in case MM doesn't know what type of album art an image is, it's better to make it 'Not specified' rather that make it automatically 'Front cover'. As I wrote, MM can guess the correct value many times from filenames, can read it from tags and later would e.g. know that imported album art from Amazon are all front covers. Re. additional image storage options - I though about them when I implemented this, but I would say that for now it isn't much important. We can add more options depending on users requests and on other features we implement (e.g. album art retrieval from Amazon). |
|
One minor text issue re the context menu that appears when the user right clicks on the Album Art dialog: -Selected Album Cover --> Album Art (Selected) -Now Playing Album Cover --> Album Art (Now Playing) Re. the default image type. I would suggest that the logic that makes most sense is that if the user is _manually_adding_ an image and no images are associated with the track yet, then it should default to Album Cover (front) . I agree with you that for the purposes of scanning tracks, MM should not assume that any image that exists is a Front Cover (though it would probably be a fair guess that if only a single image exists, that it's a front cover). |
|
Fxied in build 806. |
|
Verified in 806. Minor issue remains: Cover (front) always appears by default when manually adding covers (even if a cover already exists). Tracking in new bug. |