[quote="MoDementia"]Updated

Added writetags option, also has the advantage of refreshing MMs main track list woot.[/quote]

There are some issues with [url=http://www.mediamonkey.com/forum/viewtopic.php?t=28546]WriteTags[/url]. This may create some unexpected results
and
[url=http://www.mediamonkey.com/forum/viewtopic.php?t=28547]UnRegisterEvents[/url] (turning off writetags) This can be worked around by restarting MM when switching write tags

[quote="wolfzell"]"playcount" or "times skipped"
What happens when ratings got changed on both sides?
[/quote]
MM dosen't have times skipped and I can see some possible issues with playcount when syncing back from a player, but I will have to test this when I get my library sorted. Depends how MM syncs the informatin back, if it is incremented then it shouldn't be as big of an issue.

[quote="wolfzell"]
I am afraid that you are right. Well, many of my playlists are done manually and updated when adding new tracks. So this might be a challenge.
[/quote]
There is a/are scripts that set up nodes for different views etc I'm sure these could be used for building playlists without changing views.
It also depends on how many "player" playlists you have as to how much of an isssue it is.
I only synch 1 autoplaylist to my player, so....

[quote="wolfzell"]
Another challenge. :) As I mentioned, 85% of my library is in FLAC. But the other 15% are in 192kbps MP3. My sync settings are converting the FLAC files to 192kbps MP3 and the files already in MP3 format simply get copied.
[/quote]
This is also one of the main reasons for the script.
Many users have issues with the time it takes to convert tracks on the fly when syncing.
I have an 80gig iPod and there is no way I am going to convert 80gig worth everytime. It took 34-38 hours to sync my iPod, with the tracks already converted I think it took a couple of hours at most :)
So my synclist is from the converted tracks not the originals.

[quote="wolfzell"]
Still the auto organise function will be very critical. What would happen if the filter wasn't set? Ok, the resulting duplicates might be obvious to see, but still...
[/quote]
I do use a custom field as part of my auto organise mask where it forms part of the directory e.g. My CDs, My Cassettes, My Vinyl, My Conversions etc
My Music\<Custom5>\<Album Artist>\....

[quote="wolfzell"]
Wouldn't it be much easier and safer to use one of the user tag fields for this script? I myself would very happily sacrifice one of them if this would ease the situation.
[/quote]
Making the links more visible will be part of the alpha testing.
Using 1 of the custom fields would be advantageous, as you say, it would also be written to the tag for extra safety.
But it is quite difficult to use it as a "link" as such without making it un readable to the user.
One of the advantages of the script is that you can establish multiple links on various levels.
128 or 96 converted tracks for my 1 gig player, 256-320 converted tracks for my 80gig, Duplicate tracks on various albums that you want to keep certain fields synced, e.g. original artist/year, lyrics etc.
The uses are pretty much endless. :)

You can auto-organize on <type> which easily let you separate file types.

Updated

Added writetags option, also has the advantage of refreshing MMs main track list woot.

First I want to thank you again for your initiative. This is starting to sound very interesting.
[quote="MoDementia"]" sync-back of changed ratings on portable devices" This is the main reason for having it work both ways, I'm not expecting a huge headache.
In fact I think it could be written to to update different fields depending on the direction. Interesting :)[/quote]
Ratings and statistical info as "playcount" or "times skipped" are the fields I instantly think of. While the latter might better be done as an increment to the database, I still can think of some scenarios regarding the ratings that would justify a veto possiblity before updating.

What happens when ratings got changed on both sides? I do not suppose that the rating field has it's own change date, has it? But I guess we already do have the same problem without your script.
[quote="MoDementia"]
I havent checked if views affect the setting up of directories and tracks to be synched but manaul playlists will need to be created in the correct view I think, but autoplaylists should be fine to create in any view, they will both sync/play etc in any view[/quote]
I am afraid that you are right. Well, many of my playlists are done manually and updated when adding new tracks. So this might be a challenge.

[quote="MoDementia"]You can auto organise on many fields including bitrate which should help separate most of them.[/quote]
Another challenge. :) As I mentioned, 85% of my library is in FLAC. But the other 15% are in 192kbps MP3. My sync settings are converting the FLAC files to 192kbps MP3 and the files already in MP3 format simply get copied.

Now your script either most likely has to make another copy of the MP3 files in the converted directory (ok with me, hard disk space is cheap). Still the auto organise function will be very critical. What would happen if the filter wasn't set? Ok, the resulting duplicates might be obvious to see, but still...

[quote="MoDementia"]
The scirpt actually establishes the link at the point of the conversion regardless of where it is located. Only the catch up script (Manual Build Table Script) might have trouble locating all the links but can be modified no end to cater for any setup.
All future conversions will automatically be tracked.
[/quote]
Wouldn't it be much easier and safer to use one of the user tag fields for this script? I myself would very happily sacrifice one of them if this would ease the situation.

Think of the advantages:

This way you could put up the link between original and converted copy via index-numbers in there and also clearly mark the originals whatever format they might have. So the risk of mixing up original and copy will be greatly reduced.

You could easily select and delete the converted tracks at any time to get rid of them or to have new ones built. And the script would not have to rely on external tables only that could get lost/damaged but could use internal data stored with the songs. If external tables are necessary/faster, they could be build out of the data in that tag. This would allow you to keep the info related to the tracks, whatever might happen to them via auto-organise or else. Also the filter function could be set up on data there.

Could even auto organise work relying on that info?

That index could look something like that:
First char: "O" for Original or "C" for Copy
Next 3-5 chars: Format and bitrate, like M193 for MP3, 192 kbps or FLAC...
Next 20 chars: Unique index key number, identical for original and copy

This way for example you could use the first chars for auto organising the tracks in different directories...

Manual playlist copies for the sync of converted files could be generated on behalf of that info there too, I guess...

[/quote]
[quote="MoDementia"]Hope I've answered most of your concerns so far :)[/quote]
Yes you did. Thanks once more. But as you can see, I am veeeery critical and hard to satisfy... :)

bye
Wolfgang

[quote="wolfzell"]
The "vice versa" part is making me think. For your concept I guess it is necessary (otherwise there would be no sync-back of changed ratings on portable devices), but I am not sure if this will not give you a huge headache later.
[/quote]
" sync-back of changed ratings on portable devices" This is the main reason for having it work both ways, I'm not expecting a huge headache.
In fact I think it could be written to to update different fields depending on the direction. Interesting :)

[quote="wolfzell"]
1. Having the same data twice in a database and keeping it in sync seems risky to me and a very good way of getting into trouble when syncing somehow fails. It is hard enough right now sometimes to keep the metadata and the database in perfect sync.
[/quote]
This is what databases are good at, as long as the people telling it what to do get it right :P
There are people atm who simply neglect the upkeep of these other tracks, or reconvert them all every so often or like me have a separate database which is also heavily unkept. These scenarios are no worse than the occasional "bug" this might produce.

[quote="wolfzell"]
2. Personally I would like never having to see/manage/touch the converted tracks in MM at all. So I suppose the basic scenario for me would be to always have the filter active for the original library.
[/quote]
I agree here and it is how I will utilise my library.

[quote="wolfzell"]
But then: How does MM know that it should use the converted tracks when syncing? Does this mean I will have to switch filters before syncing?

3. How about the playlists and their management then? I mainly sync using my playlists. Does this mean, all playlists have to be there twice? Once with the original and once converted?
[/quote]
I havent checked if views affect the setting up of directories and tracks to be synched but manaul playlists will need to be created in the correct view I think, but autoplaylists should be fine to create in any view, they will both sync/play etc in any view.

[quote="wolfzell"]
4. What about file location? Renaming and sorting the files might get really tricky. MM does not have a way to sort the files into 2 different directories now, based on their format, or has it? And then: What happens if files in the original database do have the same format as their duplicates? For example, not 100% of my library is in MP3, but about 15% are in MP3 already. What is happening to them using your script?
[/quote]
You can auto organise on many fields including bitrate which should help separate most of them.
The scirpt actually establishes the link at the point of the conversion regardless of where it is located. Only the catch up script (Manual Build Table Script) might have trouble locating all the links but can be modified no end to cater for any setup.
All future conversions will automatically be tracked.

Hope I've answered most of your concerns so far :)

[quote="MoDementia"]I mean Alpha Testers :) for my new script SyncTheSync[/quote]
Wow. Great initiative and interesting concept. I would love to test it, but I am afraid I do not have the time right now. Nevertheless, I would like to make some comments.

[quote]What it does:
Keeps Converted Tracks MetaData in Sync with the Original Track and vice versa[/quote]
The "vice versa" part is making me think. For your concept I guess it is necessary (otherwise there would be no sync-back of changed ratings on portable devices), but I am not sure if this will not give you a huge headache later.

1. Having the same data twice in a database and keeping it in sync seems risky to me and a very good way of getting into trouble when syncing somehow fails. It is hard enough right now sometimes to keep the metadata and the database in perfect sync.

2. Personally I would like never having to see/manage/touch the converted tracks in MM at all. So I suppose the basic scenario for me would be to always have the filter active for the original library.

But then: How does MM know that it should use the converted tracks when syncing? Does this mean I will have to switch filters before syncing?

3. How about the playlists and their management then? I mainly sync using my playlists. Does this mean, all playlists have to be there twice? Once with the original and once converted?

4. What about file location? Renaming and sorting the files might get really tricky. MM does not have a way to sort the files into 2 different directories now, based on their format, or has it? And then: What happens if files in the original database do have the same format as their duplicates? For example, not 100% of my library is in MP3, but about 15% are in MP3 already. What is happening to them using your script?

These are the first few questions coming up in my head and I am afraid, there will be many more...

bye
Wolfgang

I mean Alpha Testers :) for my new script SyncTheSync

Installer [url=http://users.ncable.net.au/~modemen/Media%20Monkey/SyncTheSync/SyncTheSync.mmip]here[/url]
Manual Build Table Script [url=http://users.ncable.net.au/~modemen/Media%20Monkey/SyncTheSync/SyncTheSyncManualTableBuild.zip]here[/url]

What it does:
Keeps Converted Tracks MetaData in Sync with the Original Track and vice versa

When a track is converted to another format (and added to the library) the script saves the tracks as a pair, linked. (The manual build table script attempts to do this without doing the actual conversion)
Whenever one or the other is changed the linked track is also updated.
You can have multiple converted tracks per original i.e. a 96, 128, 192 version of the original. In this example all 4 tracks will be synced.

Currently the script is designed around this scenario.
Separate filters for Original and Converted Tracks
i.e. All 320, All 96, All 128 etc
This is mainly because MMs track list will only update/refresh the track that you update not the other tracks.
If you F5 or change nodes its fine to use a single filter

Converted Tracks are in a separate sub directory
My Music\320, My Music\96, My Music\128.
This only so the manual table build script works (any structure should be fine if you convert the tracks when the script is installed)
If you are capable the manual script could be modified to build the table from any structure.

Current Fields Updated:
All Custom Fields are optional (set in options.)
Artist,IdAlbum,Album,AlbumArtist,SongTitle,Genre,Year,TrackNumber,BPM,Author,Rating,LastTimePlayed,PlayCounter,
Custom1,Custom2,Custom3,Custom4,Custom5,Copyright,Publisher,Lyricist,Conductor,InvolvedPeople,OrigTitle,OrigArtist
,OrigLyricist,GroupDesc,ISRC,RatingString,OrigYear,Tempo,Mood,Occasion,Quality,Lyrics,Comment,DiscNumber

It has had very limited testing so far because I am actually runnig 2 databases atm.
Hence the alpha post and not an official release.
I hoping that a few brave people will be willing to test it out while I merge my 2 databases and can do significant testing myself as well.
As the database handles most of the updating there really isn't a way to log the changes. :(
But because the database handles most of the updating it should be free of script errors :P

I will be on for an hour or so to answer any questions, then back in 4-5 hours before i go to bed.

The first confirmation will be about the actual fields, too many, not enough, more optional fields etc.

I am aware of two limitations (well I think its there).
If you change the album name and art at the same time the art will not be updated.
You need to make the album name/artist change first so they are all linked to the album, then change the artwork.
It looks like it is not currently synchronising tags (just the database) but they are not showing up in the files to edit --> unsyncrhonised tags :(
I will have to add writetags to the script :(