Jemplode 56 does not allow replacement of tune.

I re-did the SYLT lyric tag on Weird Al's "Your Horoscope For Today" using the new SYLT plugin for Winamp because it lets me do milliseconds. When I used Emplode to replace the tune on the car player (right click on tune, select "Replace Tune"), it worked fine.

But when I used Jemplode 56, connected to the Rio Central, and tried to do the same thing, it gave me and error message saying "You have selected a tune that already exists on your device".

Well, duh, of course it's the same, I was trying to replace it with a slightly different copy of the same tune. That's the whole point of the Replace Tune feature right?

Odd thing is, when I did something similar with Incubus' "Drive" earlier today, jemplode worked without complaining. The difference there I think is because with "Drive", the original copy of the tune had no SYLT tag at all and the file size was probably different. Or maybe the RID checksum is different with and without the SYLT tag. But with "Horoscope", I was replacing an existing SYLT lyric so the file didn't change much except for the timestamps on the lyric. I think the same RID would even be calculated for it because none of the song data changed.

Any ideas on how this should be handled?

I can just make Replace Tune not do the RID check and trust your judgement

Should replace ONLY replace content? That is, if you HAVE changed tags, should I copy those also, or just ignore it?

Good question.

Emplode grabs the new tags, too, if any. Personally, that would be fine with me, as long as that old Octal bug is somehow fixed or worked-around. The track I'm trying to replace is track number 08 (which would induce the octal bug).

Actually, I don't think it would, as there's no digit "8" in octal. Unless I'm misremembering the problem. Which, now that I think about it, I probably am.

You're correct about 08 not being valid in octal, and that is in fact the reason the problem exists. The problem was only on the Rio Central, and it went like this:

- If your ID3V2 tags had the track number padded to two digits so that everything sorts properly when you rename your songs based on tags (something you can only do in V2 tags, since the track number is ASCII, unlike V1 which is just a byte)...

- And, you add an album's worth of songs to the Central, with track numbers of 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12...

- The internal-to-the-Central C function that they're using to convert the ASCII track number field into a database number, by an accidental choice of the function that they chose to do the job, interprets a number with a leading zero as an octal value instead of a decimal value.

- So, track numbers 01, 02, 03, 04, 05, 06, 07 are all fine because those numbers are the same in both decimal and octal.

- Track numbers 10, 11, 12 are also fine because they don't have leading zeroes and therefore the function interprets them as decimal instead of octal.

- Track number 08 and 09 have leading zeroes so they are interpreted as octal.

- Unfortunately 8 and 9 are not valid octal numbers (as you said).

- So the function returns 0, and those tracks get tagged as 0 in the Central.

The work around would be for Jemplode to strip leading zeroes off of all track numbers before sending them to the Central.

Quote:
Emplode grabs the new tags, too, if any.

Emplode uploads the new tune as a brand new FID, then goes through fixing up every playlist that the original appears in, before deleting the old FID.

So it's not actually replacing the tune itself.