by tbessie » Mon Jun 25, 2007 5:33 pm
[EDITED]
Bex wrote:Yes, both set of files must be in the library. Actually I've been thinking a lot of this and came to the conclusion that it is the best approach. The reason for that is not all tags are supported between various formats but can still be present in the database. You also have explicit database values such as playhistory, playcount, Date Added, Last Played, Playlists entries. Those values would simply be impossible to transfer to a new set of files unless they are part of the library.
Remember, I'm talking about 2 sets of functionality:
- 1. "Take all the tags in the database which are currently associated with database Record X (and which may or may not be currently associated with File A) and write all tags *which we can* to File B."
2. "Do step number 1, AND change the association of Record X from File A to file B." (i.e. replace the "file" field in the database with the new file.
Bex wrote:The steps are going to be like this:
- Rip the CD and add the tracks to the library
- Select the new tracks and perform a new special search for the old tracks
- Drag & Drop the old tracks to a special node made for the purpose
- Confirmation window pops up. Select desired transfer/copy actions and hit ok
- Done (Well, you might want to auto-organize the new tracks and of course delete the old tracks.)
Yeah, that's a bit more involved than I'd like. I'd prefer something like:
- 1. Enter a special "sync mode", which brings up a window where you've got 2 panes. Both panes contain a navigation tree with all the functionality of the main view (searches, filters, etc.) on the left, and a tracklist on the right. The righthand pane, however, will only contain a "My Computer" navigation tree, to assure that the right pane contains actual found files, not database records that may or may not contain file paths in them.
2. I can drag/drop any track or group of tracks to order them, within the tracklist of each pane.
3. Once I am satisfied with the list of database tracks in the left pane, lined up with the list of files in the right pane, I press "go" and the tags (all that can be done) in the left pane are written to the files they are associated with on the right pane.
4. In addition, there may be a 3-state toggle (set of 3 radio buttons, possibly), which would have 1) "do not change database file association", 2) "change database file association", and 3) "add database file association". These would, as listed, (1) not change the file in the database record, (2) change the file in the database record to that of the new track file, and (3) ADD a new record in the database, which is a copy of the old one, but with the newly associated track file. As in a mass-rename operation, files that are *already* associated with a given track could be color-coded as such, as would any conflicts (not sure how that could happen, but it's a possibility).
It's not THAT much more different than your suggestion, just has a slightly different emphasis and feel, I think. I'd have to think about it more to put in more details.
Bex wrote:Try it on some copied files and let us know what you think. If you want to test my script as it is now send me a pm and I'll give it to you.
I'll definitely give it a try, to see how it is. I'll PM you in a bit.
- Tim
[EDITED]
[quote="Bex"]Yes, both set of files must be in the library. Actually I've been thinking a lot of this and came to the conclusion that it is the best approach. The reason for that is not all tags are supported between various formats but can still be present in the database. You also have explicit database values such as playhistory, playcount, Date Added, Last Played, Playlists entries. Those values would simply be impossible to transfer to a new set of files unless they are part of the library.[/quote]
Remember, I'm talking about 2 sets of functionality:
[list]1. "Take all the tags in the database which are currently associated with database Record X (and which may or may not be currently associated with File A) and write all tags *which we can* to File B."
2. "Do step number 1, AND change the association of Record X from File A to file B." (i.e. replace the "file" field in the database with the new file.[/list]
[quote="Bex"]The steps are going to be like this:
- Rip the CD and add the tracks to the library
- Select the new tracks and perform a new special search for the old tracks
- Drag & Drop the old tracks to a special node made for the purpose
- Confirmation window pops up. Select desired transfer/copy actions and hit ok
- Done (Well, you might want to auto-organize the new tracks and of course delete the old tracks.)
[/quote]
Yeah, that's a bit more involved than I'd like. I'd prefer something like:
[list]1. Enter a special "sync mode", which brings up a window where you've got 2 panes. Both panes contain a navigation tree with all the functionality of the main view (searches, filters, etc.) on the left, and a tracklist on the right. The righthand pane, however, will only contain a "My Computer" navigation tree, to assure that the right pane contains actual found files, not database records that may or may not contain file paths in them.
2. I can drag/drop any track or group of tracks to order them, within the tracklist of each pane.
3. Once I am satisfied with the list of database tracks in the left pane, lined up with the list of files in the right pane, I press "go" and the tags (all that can be done) in the left pane are written to the files they are associated with on the right pane.
4. In addition, there may be a 3-state toggle (set of 3 radio buttons, possibly), which would have 1) "do not change database file association", 2) "change database file association", and 3) "add database file association". These would, as listed, (1) not change the file in the database record, (2) change the file in the database record to that of the new track file, and (3) ADD a new record in the database, which is a copy of the old one, but with the newly associated track file. As in a mass-rename operation, files that are *already* associated with a given track could be color-coded as such, as would any conflicts (not sure how that could happen, but it's a possibility).[/list]
It's not THAT much more different than your suggestion, just has a slightly different emphasis and feel, I think. I'd have to think about it more to put in more details.
[quote="Bex"]Try it on some copied files and let us know what you think. If you want to test my script as it is now send me a pm and I'll give it to you.[/quote]
I'll definitely give it a try, to see how it is. I'll PM you in a bit.
- Tim