Since the 'Clone Tool' doesn't work for me as of yet, I have been doing it by hand, my ? is if I download my playlists from player 1 to a temp folder on PC then reupload to a duplicate named playlist on player 2, will the songs that are referenced in a previous playlist copied from player 1 to player 2 be copies or thrown out as dupes?
Long ? but I think I described it best as possible.

If you upload file(s) that were downloaded the same physical tunefile on source empeg to the target more that once, I am affraid they will end up with duplicates. At least that was behaviour up to 2.0b3. There were plans to do some de-dupping (perhaps using checksums, I don't remember), but I am not sure the feature made its way to 2.0b7. Roger?

Was that the question?

Deduplication of tracks currently only works within a single playlist. If the tags match, then the file is discarded as a duplicate.

This is recursive -- you can drag the root of your music directory from the PC to the root playlist on the empeg, and it should "just work".

This doesn't work for deduplicating across the entire player, and the tags are a little restrictive -- meaning that you can't change the year, for example, without the file on the PC not being spotted as a duplicate.

No, there's no extra deduplication features in v2.0b7.

I did just have an idea, though: ID3v2 allows for an application-specific file ID. If emplode modified this when you loaded the file for the first time, and then stored it in the *1 file, it'd give us a very quick way to check if a file was already present.

Don't know if this is feasible, though. For a start, it means adding ID3 write support to emplode. This is no bad thing, OTOH.

For a start, it means adding ID3 write support to emplode.

You promissed that already!

Hm, some rippers put checksum in the comment field. Could emplode do similar (i.e. is calculating CRC, MD5 or something like that on a tune file too processor-intesive to be routinely done)? This way we could massage ID3s to our liking, or even repeat (perfect) rip, and duplicates would still be recognised.

The problem with using an MD5 checksum is that it's designed to spot if two files are identical. This is not what we're looking for here. We want to know if two files are almost identical.

We could spot that only the tags have changed by restricting the checksum to the MP3 frames. This is messy, but doable.

If you rip a file, to perfect it, say, then you're completely hosed. If the MD5 didn't change, then the file didn't change, and re-ripping it didn't buy you anything. If the MD5 did change, then it _is_ a different file. How is emplode supposed to spot this?

Thus, the only reliable way to spot that a file is semantically the same as another one is to ensure that it has a unique ID embedded in it somewhere at creation time. As long as this ID is the same, then it's the same file.

However, even this won't work in the face of a freshly ripped track.

I have given this problem some thought, trust me .

What I had in mind *was* preventing uploading a tune identical to one already there. For that checksumming non-tag portion would do. However, you are right, the actual problem is more often detecting duplicate *songs*, not exactly duplicate *files*.

I believe you are pondering this and other problems now and then