View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000246 | MMW v4 | Virtual CD cache / Preview | public | 2003-03-28 02:54 | 2007-09-11 17:05 |
Reporter | rusty | Assigned To | |||
Priority | low | Severity | major | Reproducibility | always |
Status | feedback | Resolution | open | ||
Summary | 0000246: Metabug: revamped CD Album catalog & Virtual CD functionality | ||||
Description | Here's the promised revamp to the virtual CD. The doc is long, but the actual proposal lead to a much easier to understand set of features from the user perspective. Also, I don't believe that it involves too many code changes, but you might disagree. Please let me know what you think. | ||||
Additional Information | 5/29: Triaged to 'high' with Jiri (along with bugs 0000082, 0000383, #412). See: http://www.songs-db.com/forum/viewtopic.php?t=805&view=previous http://www.songs-db.com/forum/viewtopic.php?t=693 http://www.songs-db.com/forum/viewtopic.php?t=1981 | ||||
Tags | No tags attached. | ||||
Attached Files | virtualcd.txt (10,804 bytes)
Virtual CD currently has several functions (as perceived by users): 1) Means of cataloguing songs that are in CD collection and on hard drive, without creating duplicate listings 2) Means of saving files to a specified directory, in a specified format, allowing users to easily create mixes for special occasions that can in turn be exported to portable devices and/or cd burners At the moment, Virtual CD supports both of these functions to some extent, but functionality in both cases is somewhat limited as there are several issues that prevent these functions from being executed to their full potential: Function 1) ---------- Issues: a) There are several cases, in which users need to track CDs and songs, however, the current caching functionality doesn't support all of them: i) Have song (mp3) but not CD - this is supported/works well (via song/artist/etc. nodes) ii) Have cd but not song - this is supported/works well (via same nodes as i) + location node) iii)Have cd and then get song from CD - this is supported/works well by 'caching' the song from the CD iv) Have cd and then get song from elsewhere - this isn't supported. If the user has the CD, and then gets an MP3 of the same song, there doesn't appear to be any way to eliminate the duplicate records that result v) Have song in collection and then get CD - this isn't supported--there doesn't seem to be a way of indicating that a song is the same as one on the CD, and thus there are duplicate entries vi) Have a song from a CD that is owned, but then lose the CD --this isn't supported, as there doesn't seem to be a (understandable??) means of changing a song that is cached, to one that is just part of the library. b) There are several nodes used to represent the concepts of: 0) CD that isn't in Library: appears in 'My Computer' node, but not in the 'Locations' node i) Inserted CD that has been added to Library: appears in 'Locations' node but in a confusing manner: -CDs are represented in the same hierarchy as CD Drives (bug #206) ii) Uninserted CD that is part of Library: appears in 'Locations' node but in a confusing manner: -CD Label is often missing (bug#206) iii) Song that is 'cached': Always appears in the 'Virtual CD' node. This is confusing because: -Only some of the cached songs appear sub to /Locations/CD and yet a different set appear in the 'Virtual CD' node c) If the user wants to change the attributes of a song that is in the 'Cache' it is unclear what they are actually changing (bug #82). e.g.: i) One song in the cache is 'One thing leads to another', Path: c:/Mymusic/thefixx/The Fixx - One Thing.mp3 -If the user deletes, moves, changes the properties of this song, What are they changing?? In fact it appears that they're changing the original file which was copied to the cache!! ii)A second song in the cache is 'One thing leads to another', Path: [-]\Track01.cd -If the user deletes, moves, changes the properties of this song, what are they changing?? It's anyone's guess?! The net result of the current implementation is that the user is forced into a mode of operation in which they _must_ add CDs to their collection, then create virtual CDs, and then eliminate any duplicates that may arise because they already have certain songs. Any other order is incompatible with the current design. Moreover, concepts such as 'virtual cds' are not needed for this basic functionality. The functionality _is_ extremely useful, but needs to be radically simplified into something that the average user can understand intuitively. What follows is how I think the usecases should transpire: 1) To add song to Library from CD (no real changes here): -User inserts CD -Album info is looked up automatically (bug #157) -User selects a song from '/My Computer/CD xxxx/, right clicks it, and Rips the contents (bugs #86, #130) -->Songs appear in expected nodes as they do today 2) To add a CD to the Library but no songs (some changes here): -User inserts CD -Album info is looked up automatically (bug #157) -User clicks 'Add to Library' (bug #206) --->CD label is added next to the physical D:/ node (currently doesn't work -- bug #206) --->CD Album entry for that particular CD is added sub to a '/CD Albums/' node (bug #206) -If no album info was available, the CD is added, but most fields are empty for the user to edit 3) To add songs from a CD that is already catalogued sub to '/CD Albums/' (big changes here): -User inserts CD -->The /Location/D: node is filled with the correct label and contents (since the CD is already in the library) -->The previously greyed-out node/contents of the /CD Albums/CD xxxx becomes black (bug #206) -User Selects one or more of the songs from the CD, and clicks 'Rip CD' -->Rip CD dialog appears as defined in bug 130, except that the dialog has an additional checkbox: [x] Associate with CD Album: xxxx -->When the song is ripped, it is associated with the Album to which it belongs, and is represented in: -/Locations/CD Albums/CD xxxx in black (not greyed out) -the nodes in which 'normal' songs would otherwise appear Note: it does _not_ appear in a 'Virtual CD' node 4) To add songs obtained from somewhere else to a CD that is already catalogued sub to '/CD Albums/ (some changes here) -User drags the file from some location in the library to the /CD Albums/CD xxxx node -If file artist/title is a 'close' match, the attributes of the song are changed and the file is 'cached' in the album i.e. --> the track appears black instead of greyed out -If the file artist/title isn't a 'close' match, the user is informed that 'The Track is not part of the CD Album xxxx. Do you want to add it to the album anyhow? If user clicks 'Yes' then it is added as the last track in the album. 5) To add songs that are already in the user's collection to a new CD, the user must add the CD to the library (described in 2)) and then perform the same actions described in 4). 6) Disassociate a song from an Album (some changes here): -There are multiple ways of accomplishing this: i) Drag and Drop: User drags the 'black' file from /CD Albums/CD xxxx node to the Library/Title/Artist/Album/Genre or Year nodes ii)In the properties panel, uncheck [ ] Associate with CD Album xxxx either action results in: --->Song that was previously black becomes greyed out in /CD Albums/CD xxxx node 7) Delete an Album: Delete the CD Album from /CD Albums/CD xxxx by deleting the node -->'Are you sure you want to delete x songs?' [Yes] --> /Location/CD Albums/CD xxx is deleted, along with all the songs that were 'cached' IMPORTANT: Throughout these 7 portions of the usecase, the term Virtual CD is _not_ used. It doesn't need to be used because there's no value in introducing a new term when existing terminology adequately represents what is happening. Moreover, in all cases, songs are represented in the listview exactly as they are i.e.: -When a song has been 'associated', the song's actual path/filename are shown so that it is clear that what is being shown is simply a song from the db, the only difference being that it is one that is part of a particular CD Album that the user possesses. Function 2) ---------- At the moment there are several issues preventing the user from easily creating 'Virtual CDs' of _any_ content, that could be later used for: -export to devices -export to burner -temporary store for later import into the main area of the collection a) Only a single Virtual CD & Queue can be created, when, in fact, it's likely that the user may want to create different ones for different projects (#209) b) The base directory must be predefined, as must be the conversion format, when in fact the user will want to use different ones for different projects (#209) c) Songs that are copied to the virtual cd aren't correctly identified with their path, so the user is unclear where they are actually stored--problematic when the user is using a specified directory for the purposes of a project (they're unsure of whether or not they're actually saving files to the correct directory and/or what files are being edited). The usecase should proceed as follows: 1) User want to create a mix to export to other device: -User copies files from My Computer/D: to Virtual CD Queue -->Songs appear in Queue, and in the DB (greyed out if CD is missing). They do _not_ appear in the /Location/CD Album directory unless the user explicitly adds the album. -User copies files from any location in the library to Virtual CD Queue -->Songs appear in Queue, and originals in the DB remain. -User saves songs from the Queue to the Virtual CD -->A dialog appears that allows the user to configure directory, mask, compression, and to accept all of these parameters before saving (same as Rip CD dialog, except that there's no option to associate to a CD) IMPORTANT: -when files are displayed in the Virtual CD, their actual path should be shown, as should their source (Library/CD/HD) -the VCD node should be moved sub to Location since it is effectively a 'place' to temporarily store files NOTE: The above usecase is fairly similar to the current VCD implementation except that: -There's no tie-in to physical CD Albums -There's no Property for a virtual CD--the virtual CD is effectively a place on the HD -To move files from the VCD to the collection, the user simply drags the file(s) from the VCD folder to a 'real' physical location on the drive -The usecase above doesn't deal with how to create a new Virtual CD. I haven't fully thought this through, but it could work like this: -No virtual CDs exist by default -Save to virtual CD would have subcommand>New, and existing VCDs -If the user selects New, a 'New' node would be created (or 'NewX' if 'New' already existed) -Dialog would pop up, user selects 'OK', songs would be saved to the chosen node. Related Bugs: 082 Cache / Preview minor 03-27 Unclear how to move songs from cache into the library 080 Cache / Preview tweak 02-26 Save to Virtual CD --> redundant Freedb query 206 Main Panel major 03-25 Library/Locations/CD nodes are confusing/inconsistent 066 Player feature 03-25 Player: CD Detection Wizard 212 Cache / Preview minor 03-24 Unclear what is being deleted when user deletes a VCD/Preview song 210 Cache / Preview minor 03-24 Drag and Drop to Virtual CD or Virtual CD Queue doesn't work 209 Cache / Preview feature 03-24 Problems caching from HD | ||||
Fixed in build | |||||
|
Quite long, indeed, I probably do not understand everything properly yet but hopefully will after more thinking. First of all, it could be useful for you to know how it internally works (it ex lains my idea how should it be used): Each song has a flag - whether is it cached or not and in case it is, there is stored a ath information about where the cached file is. There isn't any more complicated relation among songs and their cached versi ns implemented and also it isn't necessary in my opinion. Then, I must say that I agree that there are some things th t should be modified in the related bugs you mentioned, but I don't think that it is necessary to make any huge modification - at least not now, when it works quite well and we don't have resources for such changes and time to do it. Re. new proposed functionality: I don't think that cache should be used for solving duplicate versions of songs, either on audio CDs or HD. The scenarios you described { 1) a) iv) & v) & vi)} should be more or less solved by user or some other function lity (as setting some kinds of links among songs, e.g. between the original version and some remake, not only the cases you men ioned). This brings possibly more general solution, where a song in the DB is just something virtual and contains one or more 'instances', e.g. one audio CD track, one MP3 and one off-line cassette recording. However, this is something that is proba ly too much to be solved by an ordinary user-friendly software. Anyway, if we decide to do something in this field, either simp ier as you described or more general as I wrote here, I think we shouldn't do it now in the current situation (as repeated s veral times - we need to make something reasonably good very soon ;-) ). The second big issue you mentioned was making m ltiple VCD. Even here I think it isn't necessary (at least not now). Maybe some users could have another opinion, but I thin that playlists should be used for this functionality. Playlists are in their hierarchical structure very powerful and can be u ed easily to prepare any kind of mix. Cache can help here a lot as you can select the whole playlist, execute Cache now and aft r inserting few CDs you are sure that the full playlist is available and you can play it at your party, for example. Then you c n use other features (like copy or convert) to prepare the playlist in a custom-chosen location in any format you want. hortly, as I wrote, I agree with several proposed fixed, but I think that any major changes are impossible now and even probabl not too necessary. |
|
With your description of how the cache works, I have a better understanding of the problem. I would guess that the cache was designed for Function 2), and was kind of retrofitted to meet the needs of Function 1). From your description of how the cache works, I would disagree with you re. whether the current 'back end' is suitable to meet the needs described in Function 1). I think that the current 'back end' _could_ be used for associating a _file_ with an Album Entry--the only difference is that FROM the user's perspective, there is no 'cache/Virtual CD', there's just a song, and the song is the same as a song that exists on one of the user's CDs except that it may or may not be stored locally. (i.e. each song that is part of a physical CD Album that the user possesses has an attribute: File available / File_not_Available). This seems simple to me, but haven't seen the innards of the code ;-) Re. Function 2), there shouldn't be many changes vs. what is implemented today--the primary difference would be that: -This 'cache' shouldn't contain the items FROM Function 1) (i.e. there would have to be 2 separate 'caches'--one for Function 1) and another for Function 2)) -This 'cache' has an interface that is slightly modified as compared to the current implementation, so as to give the user more flexibility. -Regarding multiple VCD, I agree with your assessment Let me know if you think I'm off base. p.s. I've shown the VCD to 3 people (non-technical, but use computers on a daily basis) thus far, and none of them were able to grasp the 'Virtual CD' functionality. |
|
Another refinement to this would be that: -When the user rips from /Library/Location/CD Albums --> song is associated to the album -When the user rips directly from the CD --> song is stored in the library like any other song (no association is formed) |
|
Re. the purpose of cache: I think it isn't and wasn't either for function 1) or 2) (even though 1) is quite close). The scenario I use and I know several users that use it too and are satisfied with it: You have a number of audio CDs, but you don't wan't to insert them in order to play them. Ok, you simply cache them and from this moment there is still one entry for the file in the database, but you can play it even if the audio CD isn't present. This applies to mp3 CDs as well. It does nothing more, it is actually a copy of the original file only, but for the user it solves problems with handling removable media. The most important aspect isn't that there is 'Virtual CD' node, but that you can play 'Abba-Waterloo' and don't need think about inserting proper media. It's even more obvious with playlists - you can cache a 'party' playlist to be sure that when you play it, there won't be any problem (and the songs can be on several media). Maybe you think it isn't that useful, but this feature was one of the main reasons I have ever started to write my own application! And as I wrote, many others feel the same way. Anyway, any major changes would definitely take a long time so I would defer further discussion. |
|
pushedfrom22 |