Download feature and ID3 tags.

I can't get the clone feature to work, so I thought I would start downloading the tracks from one player and uploading to the other one. But what I have run into here is that the tags are never correct for what they show on the orginal player. I willhave to edit every single tag as it goes back on the new one.

What to do?

You can use MP3 Tag Studio to re-tag the files based on their file names.

You lose the Year and Genre that way, so I'm hoping Roger can come up with a way to handle this situation in a future release.

Next time, get the tags right BEFORE sending the files to the player.

(They don't have a smiley icon for someone who is blue in the face.)

No-no-no, emplode download is not the right way to go (TM) if you haven't got your ID3 tags right originally. Engage in a bit of BBS archeology and locate recipe for installing ftp (both server and client) on the player. With server running (or ready to run if it is started via inetd) on one player, fire up ftp client on another and copy all FID files (/drive[01]/FIDS/*). Dummy sync will rebuild the database from *1 (tag) files.

This, of course, if both players are MkII and you are too impatient to wait for Jemplode or empeg guys to fix their respective utilities.

Roger: can you please fix and release serial number fix on clone tool?

A bit of my collection is just that. A collection that I had before my Empeg. So I really never worried about the tags and such as long as the file name was right. On anything that I have encoded since I got my Empeg, the tags are usually correct.

I am just impatient over this cloning not working. Can't use my newest toy till it has some tunes on it.

Do we have a clue that the Empeg guys are working on the clone tool fix, or are we speculating? I didn't see an actual post where they said it would be out soon.

it would be great also if a folder would be created for each playlist after downloading

I think that Roger said creating folders on download from the player is planned (I am not sure whether for regular of 'copious free' time, though ). No details on handling multiple links, either...

On my list of things to do are:

1. Get download to write out ID3 tags according to the empeg database.
2. Support arbitrary filename formatting for the download (e.g. you can specify {artist}\{album}\{tracknr} - {title}.mp3 and stuff like that.
3. Remind Mike to add the clone "swap" button (or do it myself).

As far as the playlist hierarchy goes, this is fairly simple. What to do if the track appears in multiple playlists, though?

Alternatively, I could download the whole lot and then generate some M3U files (can you nest them?).

Great! Any timeframe?

m3u playlists cannot be nested (at least an oldish version of WinAmp won't do anything with them). Heck, why don't Windoze support proper symbolic links!?

I don't have idea how to *exactly* mimic empeg playlist structure (and its behaviour) on Windows...

We're focussing on the stability problems right now, before we start adding too many new features. This means that it won't be next week. It could be the week after. Of course, the time between a feature being implemented and a public release being made is not under my control.

I just copied the file multiple times if the user has it in multiple playlists .. I think it's the "closest" thing to whta the user wants ... On linux, maybe a sym link would do it, but that's kind of a pain to keep track of.

Mike

I'd have to agree that if there are multiple listings for a song, it should be downloaded each time. I think most people have a single playlist that has nearly all their songs, so they could just download that entire playlist and nothing else. I'd just need to download my 'artists', 'comedy', and 'classical' playlists to get all of mine. Everything else is a duplicate that's in one of the other three.

I agree, I think the file should be copied multiple times. It is not that hard to find duplicates in emplode, now.

I agree that on Windows probably the best we can do (without some heroic efforts) would be to download each time (or perhaps just make a local copy - much faster - if it's not too much trouble to find 'the original').

On Unices using symlinks should not be a problem, especially if we (partially) copy empeg approach and dump all tunes to a single directory while populating playlist tree with symlinks only.

Well, I was thinking, maybe in windows simple "shortcuts" may be created rather than making a physical copy of the file. Those may be detected by emplode so that it could recreate the "link" when copying mp3s back to the empeg. Shortcuts (*.lnk) also work well under windows command line, at least in Win2k/XP (which is not dos! In dos they would not work!), but after all if you're using emplode that means you are using windows.
Actually, NTFS always had a symlink featiure that is not very well known (the best way to use it is to dload the free utility JUNCTION.EXE from SysIntrnals), which works more or less the same way as under unix, so that could be used too, but maybe using .lnk is simpler.

I didn't know NT had real symlinks. Nice.

When deciding on using *.lnk or some other form of links it would be nice to maintain the proper hierarchy not just in emplode's view, but also that of 'regular' Win apps (e.g. MP3 players).

Sorry, I was not precise. NTFS 5.0 always had symlinks ("junctions" in MS world), so Windows 2K/XP have it, NT does not, since it uses NTFS 4.0. I think there was some SP that brought the NTFS version up to 5, but I am not sure. I think it was release after I moved to 2000, so I do not remeber well.

What do you mean by maintaining the hyerarchy in regular win apps like "winamp" ?
What I was thinking was to create a tree structure on the hdd that mirrors that of the USer Playlists on the empeg, and when emplode detects that a file is present in more than one playlist, it may

1) put it in the first playlist and make a .lnk in all the others
or
2) copy it in a special folder and create a link in all the other playlists.

Now, wait, as Rob said (sorry, I just got what you menat now ) it could also copy all the files in one single folder and then create in another folder playlists as M3u files, but that could make it harder to make changes on the hdd and then sync them on the empeg, which is a feature that may hopefully be implemented later... So maybe the simple tree folder structure and .lnk is the way to go... What do you think?

One more thing. Does WInamp "play" .lnk? Let me go and check what happens if I drag an mp3 shortcut on it...
Ok, now this is great. It plays it! also, I tried with a shortcut to an mp3 that was on a network drive, so no problem with that either!

Well, if WinAmp and company understand *.lnk files, that could be a way to go... OK, I just tried to make a directory full of shortcuts, and then a shortcut to it. That works as well. Good, so a single tune directory and a tree od playlist directories populated with shortcuts to tunes and other playlists?