View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002624 | MMW v4 | Conversion/Leveling | public | 2006-08-30 04:57 | 2013-01-10 15:09 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 3.2.3 | ||||
| Target Version | 4.1.1 | ||||
| Summary | 0002624: Rip CD: Users are often unclear how to edit the metadata | ||||
| Description | If the user attempts to rip a CD there are some specific situations that can arise which result in all tracks being ripped to a single filename: a) If the metadata isn't in freedb, then the default mask will result in all tracks being assigned the same name. Aside from the filename problem, this also results in tracks being added to the library that users often cannot identify subsequently. This can be resolved by: -Prompting the user for Album Metadata if none can be found b) If the user inadvertently sets a default mask that doesn't correctly assign metadata -The new mask configuration UI (still more work needed, but that will be tracked elsewhere) -Making it more clear that paths can be manually assigned -Giving a clearer error message Suggested changes: 1) Show the actual CD metadata when the user clicks 'Rip' instead of making the dialog filename-centric. e.g. as with WMP, MM should show all known attributes and allow the user to edit them as needed. 2) Tracks to be ripped: --> Select / Edit Tracks to be ripped: 3) Change 'Format Settings' --> Settings In this box, show: i) A sample destination path (like in the mask wizard) ii) The format settings iii) A warning if necessary i.e. 'Duplicate Filenames exist (in red). Please change the filenames.' --> 'Highlighted tracks will have duplicate filenames and will overwrite one another. To correct this, change the destination, or edit the filenames of the tracks to be ripped. e.g. ----------------------------------------------------------------------- |Rip CD ----------------------------------------------------------------------------- |Record Tracks to your hard drive | Destination: _____________________________^[Browse] [>>] [Options] | Audio: _____________________________^ [Settings] | |Select/Edit Tracks to be ripped: Settings: | [ ] Tr# Title Length Artist Genre Composer C:\ | Album Art [x] 01 blah mm:ss U2 Pop My Music\ | <Album Title> [x] 02 U2\ | <Album Artist>[x] 03 War\ | <Year> [x] 04 Gloria.mp3 | [x] 05 | MP3 128 VBR | ... | ... | | <WARNING> ---------------------------------------------------------------------------- The downside to the above scheme is that: -It duplicates much of what we've implemented when the user clicks the CD node, so an alternate proposal is that when the user clicks the 'Rip' button: -If the user is on the CD node, the Rip begins -If the user is not on the CD node, MM switches to the CD node -The CD node would have to have checkboxes like WMP -Another alternative is that the Rip Button is disabled unless the CD node is selected, forcing the user to first select the CD node. This is not feasible at the moment, however, it becomes feasible once we implement 0001618. This is probably the simplest approach and would yield a good solution to aspect a) of this bug. Aspect b) could be resolved by making suggested changes to the dialog except for the suggested changes re. the addition of metadata to the dialog. | ||||
| Additional Information | Comment re. the fact that some metada (disk#) isn't saved for cdplayer.ini http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=39518 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
| duplicate of | 0008976 | closed | Ludek | Some generic metadata should be added to ripped tracks that have no metadata |
| related to | 0002701 | closed | Ludek | Context toolbar + rationalize commands between menu and toolbar |
| related to | 0002918 | closed | rusty | Automated Album Art lookup when playing/ripping CD |
| parent of | 0001597 | assigned | Ludek | Automated / Simple lookup of Album art for newly inserted CD |
| parent of | 0007024 | feedback | jiri | 1304 How to enter Disc# when ripping? |
| related to | 0001618 | closed | petr | Inserting a CD --> CD node doesn't appear |
| related to | 0008403 | closed | Ludek | Rip CD: Metadata edits are lost (regression) |
| related to | 0008491 | new | CD Metadata is lost if it contains more than just basic metadata | |
| related to | 0011745 | new | Ludek | Tagging: Introducing wizard to automatically fetch metadata |
| Not all the children of this issue are yet resolved or closed. | ||||
|
|
I'd prefer leaving the current structure of the dialog as is, particularly because I think that the its filename part is very important aspect of the functionality. The aspect of giving user an option to edit metadata could be handled by adding some new columns, i.e. something like: Output file|Title|Artist|Album|...|Source file (Album Art, Album and Album Artist could be shown in the first column as suggested above). The aspect of handling duplicate target filenames could be handled as it currently is (i.e. show the red text warning) + if user presses OK button while there's that warning, another confirmation dialog appears: There are tracks selected with duplicate filenames, it will results in overwritten files. Do you want to automatically modify filenames? [Modify] [Continue] [Cancel] Modify - would try to update target mask, or add some _1, _2, postfixes to prevent duplicates. Continue - would continue without any change. Cancel - would return to Rip dialog and let user to make changes manually. |
|
|
I think we're good re. the solutions to MM assigning metadata incorrectly, but you didn't comment on the alternative approach that I'd suggested to resolve the issue of missing metadata. i.e. -Implement 0001618 -leave the Rip function disabled until the user selects the CD node. Then when user inserts a CD, they'd see the metadata in MM and would be able to edit it directly in MM _prior_ to ripping a CD. |
|
|
I see the reasons for this, but I'd rather not do it. Although it might help some users, it would force others to select CD node, even though they wouldn't like to do so. Maybe, if user clicks Rip CD and the CD doesn't have any known metadata (not album, artist, tracks only as track01, track02, etc.), there would be some kind of a notification shown giving user a chance to: 1. Go to the CD node and edit, 2. Use some autotag feature, 3. anything else? |
|
|
This made me think a bit more about bugs 0002701 and 0001346 and after updating them, it makes me even more convinced that any time we spend on updating this dialog to allow for editing of the metadata may be wasted effort. i.e. when we fix those issues it will be obvious to the user to click the CD to rip it since that's how ALL commands will work. |
|
|
Well, it still doesn't convince me that we should disable CD ripping button for all other views than CD node. Actually, I'd say that now we have two sub-issues: 1. Metadata are sometimes missing completely for CD tracks and we would like to give user an option to fix this before ripping. My preferrence for this case is to add more fields to CD rip dialog (particularly Album, Artist, Album Artist, Title, Genre and Year) so that user could enter them manually before ripping and so the correct output filenames are created. 2. Even if metadata are present, ripping (and also Auto-Organization) can result in duplicates (i.e. overwritten tracks) for several reasons, mainly: 2a. Wrongly selected masks, e.g. c:\<artist> 2b. Duplicates in metadata, e.g. two tracks of on album case have the same title. This could be prevented by an approach I suggested above, i.e. (copying text from above): The aspect of handling duplicate target filenames could be handled as it currently is (i.e. show the red text warning) + if user presses OK button while there's that warning, another confirmation dialog appears: There are tracks selected with duplicate filenames, it will results in overwritten files. Do you want to automatically modify filenames? [Modify] [Continue] [Cancel] Modify - would try to update target mask, or add some _1, _2, postfixes to prevent duplicates. Continue - would continue without any change. Cancel - would return to Rip dialog and let user to make changes manually. (As I wrote, this approach would be useful not only for Ripping, but also for Conversion and Auto-Organization) |
|
|
So this boils down to the fact that ripping a CD is really a 2 step process: 1) Verify/edit/lookup the metadata (keeping in mind that only a subset of metadata is currently saved for CDs) 2) Rip the CD according to user-selected settings (that make sense) I have 2 issues with the approach you're suggesting: 1) We already have other tools that would allow the user to edit properties (i.e. the tracklist and auto-tag from Amazon) and I'd prefer not to re-implement those. 2) Eventually, there should be per track ripping status indicator (like in WMP) shown in the tracklist. This only makes sense if the user is forced to the tracklist to begin with. Note: what I'm suggesting isn't any different than how Podcast subscriptions work: the user first visits the podcast node, and then does 'podcast things' like subscribe to a podcast. The subissues that you describe in your last comment can be resolved within the framework I propose. e.g. -user visits CD node (maybe MM should auto-switch to CD node upon Music CD insertion) -user edits metadata and adds artwork (note: we need a way to add artwork for read-only tracks) -user clicks 'Rip' and gets warnings if relevant Let me know what you think. The alternative is to create a 2 step Wizard (step1: edit metadata with button for Auto-tag from Amazon; Step 2: current screen) OR a single much larger dialog (along the lines proposed above). |
|
|
Another factor to keep in mind: users entering metadata for the CD only have a subset of the metadata saved to cdplayer.ini. Any approach should be able to save _all_ metadata. If only some metadata is saved, then the UI should perhaps not allow it to be edited in the first place. See: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=10231 |
