Sprint Music Store: "Error M506: Unable to Play Song."

A little white ago, I got a Samsung SPH-M620 Upstage phone that has a build in mp3 player. It included a 32 or 64 mb micro SD card, so initially, I just had a few mp3s on it. I finally spent $20 for a 2gb card, but when I copied a lot of songs to it, on some, the phone would pause for a second, then say:

Error M506: Unable to Play Song.
file:///memorycard/...mp3
cannot be played.

But the file was fine; Winamp and Windows Media Player played it just fine. I did some googling, but just found the problem--no solution. After a LOT of poking around and reverse engineering, I found out why: id3v4 tags only sorta work.

How to fix it:

There are a few other things that cause this (you'd think error codes would be unique, but no such luck). Older versions of the "Sprint Music Store" mp3 player have problems with long filenames (32 characters seems to be the approximate limit) and files in the upper 1gb on a 2gb memory card. The fixes here are short filenames and not storing too many files.

Onto my problem:

Windows users: use mp3tag (it's free). Drag all your songs into it, then hit the save button (or File, Save Tag). Even though you didn't change anything, it will rewrite your tags as id3v2.3 tags by default.

*nix users: use eyeD3 (available as audio/py-eyed3 in FreeBSD) to convert tags to id3v2.3. Run this command in a directory to convert all your mp3s:

find . -iname "*.mp3" -exec eyeD3 --to-v2.3 {} \;

Basically, use id3v1, id3v2.2, or id3v2.3 tags. If v2.4 tags are important to you, strip off the TXXX frames.

Technical details behind Sprint's bugs (headaches begin here):

When text encodings (these are used to store non-Latin characters as song names) in an ID3v2 (most modern programs store the artist, title, track number, etc. in an "ID3 tag.") are mixed, the parser chokes for no good reason.

• Files with only unicode (UTF-16 w/BOM) tags work fine
• Files with only ASCII (ISO-8859-1) tags work fine
• Files with A,U work fine
• Files with U,A work fine
• Files with A,U,A work fine
• Files with A,U,A,U work fine
• Files with U,A,U don't work with id3v2.4 (but work fine with id3v2.3)

For those who like too much information, here's a hex dump of a tag that will cause Error M506, but works fine if the fourth byte (04, indicating ID3 version 2.4) is changed to 03:

00000000 49 44 33 04 00 00 00 00 10 00 54 49 54 32 00 00 ID3.......TIT2..
00000010 00 1D 00 00 01 FF FE 4B 00 69 00 63 00 6B 00 20 .......K.i.c.k.
00000020 00 53 00 6F 00 6D 00 65 00 20 00 41 00 73 00 73 .S.o.m.e. .A.s.s
00000030 00 54 50 45 31 00 00 00 13 00 00 01 FF FE 53 00 .TPE1.........S.
00000040 74 00 72 00 6F 00 6B 00 65 00 20 00 39 00 54 52 t.r.o.k.e. .9.TR
00000050 43 4B 00 00 00 05 00 00 00 31 2F 31 32 54 49 54 CK.......1/12TIT
00000060 33 00 00 00 13 00 00 01 FF FE 53 00 74 00 72 00 3.........S.t.r.
00000070 6F 00 6B 00 65 00 20 00 39 00 00 00 00 00 00 00 o.k.e. .9.......

Yeah, it's a headache. Nothing in the id3v2 specs makes frames with differing encodings illegal.

But that wasn't everything. There were a bunch of TXXX (user-defined) frames added, and when I tried to add one back into the shortened tag, I got the error, again. When I switched the version to id3v2.3, it worked fine.

Why were reports so random?

What made this a little hard to debug was that people, myself included, found it happening randomly. Nothing indicted a single cause. The only solution that was posted was to use iTunes (which readers of my blog already know uses obsolete, but seemingly compatible tags). Playing around with Winamp, I noticed that tags get rewritten when changes are made, even if the change wasn't to other fields, and Winamp uses id3v2.3 (but can read 2.4). If the tag was edited in Winamp, it will work with Sprint's mp3 player.