Metadata Not Displaying Correctly On Certain Media Players?

picard
Tags: #<Tag:0x00007f11c6cdbca0>

#1

I own a Sandisk Clipjam, and I noticed that all songs that have metadata edited by Musicbrainz Picard have errors once transferred. The look fine on the computer, but artists in the MP3 have a weird symbol next to them.

Is my player somehow not compatible with MusicBrainz, or is there a process I’m unaware of that is doing this?


#2

What have you set for ID3v2 version in Options > Tags > Tag Compatibility? For best compatibility with players set this to v2.3

If this does not fix the issue , can you provide a photo of this?


#3

The fun of a specification like MP3 Tags is every hardware manufacturer reads it in a different way.

I have one awkward player I always have to retag the tracks after copying them onto the player. It doesn’t like the way Picard does track numbers on multi-disk releases. Stoopid player assumes all albums are just a single disk.

You may find your player is doing something equally stupid. Also worth trying in the Tags section is dumb old ASCII (ISO-8859-1) or even the “Also include ID3v1 tags in the files

I guess the SanDisk is showing a little square after every artist name? Could be worth checking SanDisk’s website in case there is a firmware update available.

SanDisk ClipJam Firmware Update. May help, may not…
https://kb.sandisk.com/app/answers/detail/a_id/16717/


#4

I was bored, so did some reading. And you are not alone. Someone in 2011 was reporting the same problem occurring and he was using MP3TAG.

Interesting idea there - setting the music files to read-only before they are copied onto the player. Though that thread didn’t say if it worked. There are plenty of other references to corrupting tags on the player. (No idea why the player should be editing the files - probably a bug)

It is also very noticeable that in the SanDisk help files everything is showing just default\basic Windows methods. Either Windows Media Player editing the tags, or just right clicking on the files in the OS and editing them.

Ah - bingo. I found it for you. Someone in the forums said that the SanDisk Sansa is “most compatible with ID3v2 v2.3 ISO-8859-1 tags”. So old standards. I expect it will be the same with your player.

More about tags: when it says “refreshing your media”, what it’s really doing is building a database of all the information in the tags (title, artist, album, track number, etc.). The player can choke on messy tags, particularly very long comments. For some reason, some people try to put the artist’s entire history (or some other ridiculously verbose nonsense) in the “Comment” tag. The best thing to do is to use a program like MP3Tag (highly recommended, and FREE) to clean up the tags, deleting comments and paring down the other tags to only the essentials. Whatever tag editor you use, change the settings to save tags in ID3 v2.3 ISO 8859-1 format if possible. This format is the most compatible with Sansas. https://forums.sandisk.com/t5/All-other-MP3-players/stuck-on-refreshing-your-media/m-p/276336#M18650

So, if I was you, I’d keep my main music collection fully tagged up with Picard using the most up to date tags. And then when I want to put music on the SanDisk I’d copy the albums to a temporary set of folders first and downgrade the tags to make them more compatible with the player’s needs. (MP3TAG is quick good at that kind of bulk editing)


#5

It’s already set to 2.3 now that I’ve checked.

IMG_20181021_093804825|375x500

Here’s what the issue looks like however. This same artist is split into two artists on the MP3 as well.


#6

It is showing s weird curved “E” symbol (or a parenthesis with a line through it) connected to a Greek alphabet “β”. I have a picture of it that I replied to someone else.

By default, the “Include ID3v1 tags” is enabled by default in the options and I haven’t tinkered much with them. May try the ISO method if I need to. Thank you for the advice!


#7

Thanks for all the research! I didn’t know my MP3 was so out of the loop. That may explain why a few songs didn’t display correctly before all this.


#8

From looking around those SanDisk forums I think your MP3 player is like many of these kinds of products. Pretty basic. BUT that is all you need really.

Kit like this doesn’t get much testing at the factory. Once they have something working it gets shipped. Then us geeks break it with our needs.

I would clear out the player, format, then start clean. Updating the firmware will help get you any bug fixes too.

Make a “MP3Player” folder on your PC. COPY your various albums to this folder. Use MP3TAG to strip the tags down to a more basic set. And set then in plain old ASCII (ISO 8859-1). Use Windows to set the ReadOnly tags. Now move these albums to the SanDisk player and see how they behave.

Why do I keep pointing to MP3TAG? Well, you can use that to set a different profile in there following this older standard. It is also easy to load up dozens of albums and then just delete whole chunks of data in one go. (For example - deleting ALL comments)

Also note how I am suggesting you keep your main library fully tagged up with Picard. And then make that temporary staging area to COPY albums to. That way you can downgrade the tagging for the albums as they get transferred to the player, but keep your main music library properly tagged.

Do a few experiments to see what your player likes the most.


#9

Alright thanks! Hopefully that will fix the issue.


#10

Just treat it as a fussy little device and you will soon find a solution.

One other trick to try. The text being displayed is actually coming from a database on the SanDisk player. So it could be just the database that is actually corrupting. So try this trick.

Connect the player to your computer in MSC mode, and look for the mtable.sys file in the root directory. This file is the database on the player. Delete it and disconnect the device. That should force a rebuild and re-reading of the tags.

It is very possible that all you need to do is delete this one file when you see the madness appear… it may just be the database itself corrupting.


#11

How would I do that? I looked up how to do so, but the support site says Clip Jam’s connect via MSC by default. The file you mentioned isn’t there.


#12

Maybe a hidden file? Do you know how to turn on Windows hidden files and system files?


#13

The setting is already enabled on my computer. The only hidden files are the .LIB files for each respective folder on the MP3.


#14

Wild guess - I wonder if those .LIB files on the SanDisk player are the library?

Drag one over to the PC and have a look inside. Use Notepad or a Hex Editor. If small, attach here at the forum. (Ideally from a folder where there is a corrupted album name)

We may be able to reverse engineer the player enough to just delete a few files.


#15

Just checked, the .LIB files are indeed the databases. I’m not going to bother pasting, because there’s just so much music there.

The data is arranged from left to right in an alphabetical fashion, going to the next line as needed. The leftmost entries don’t have much garbage symbols, (usually a “ÿþ” before the track and artist) but the further right you go, the more garbage symbols are added ( “ ­LAQ>/ÉuÀ¿ÿþ” appearing before one track name for instance)

I’m not a code expert, so I have no idea if that’s normal or not. I’d be happy to paste or send the .LIB file if that would make it easier.


#16

How big are the lib files? If all else fails, sling them onto wetransfer.com and paste the link up here. I’ll grab a copy and look,.

OR… try hacking the files yourself.

Make a backup of the .LIB and then download Notepad++ ( https://notepad-plus-plus.org/ ) and just try editing them like text files. Notepad++ will maintain any Unicode, linefeeds, etc (unlike Notepad). You should be able to see a pattern to follow.

I’d just edit one or two and then put it back onto the device. Restart the device and see what happens.

if it totally messes it up, then just put your backup back onto the device. (Or delete it and let the SanDisk player rebuild it)

Does that make sense? You don’t need to “code” to be able to hack a file like this.

edit: One of the main things to look out for is how one bit of data is separated from the next. I expect a NULL between each field. Or it may be two NULLs.

Once you crack the pattern of the database you are going to be able to clean it. :slight_smile:


#17

Downloaded and opened in notepad++, and it’s even more nonsensical than before. A bunch of "nul"s and other code terms everywhere.

The .LIB is hardly anything big, so if you want to take a look, here’s a link.


#18

I’ll have a bit more of a look at that database file later today.

What happens if you delete this library from the player? Does the player initially rebuild it clean?


#19

I took a look at this file, and this clearly shows the data is encoded using UTF-16.

TL;DR: Change you Picard settings to use either UTF-8 or ISO-8859-1 for ID3v2 Text Encoding. Use ISO-8859-1 only if UTF-8 does not work.

What you see as weird characters in front of the artist names is the so called BOM (Byte Order Mark), which is mandatory for UTF-16 and indicates in which order the bytes that make up each character should be interpreted. It is also likely mostly luck you see the other characters correctly, if you would use anything outside of ASCII characters I bet your player would fail rendering this character properly and display some garbage.

I really cannot recommend using UTF-16 for most use cases. Better go with UTF-8, it is better supported by software (btw, this is not only true for music metadata) and just like UTF-16 allows you to make use of the Unicode characters for international scripts. For older hardware players you might even need to use ISO-8859-1. As long as you are using pure ASCII characters that doesn’t make a difference anyway, since for this character range UTF-8 is indistinguishable from ISO-8859-1. But ISO-8859-1 has a very limited character range (all ASCII characters plus some western European characters like Umlauts and accented characters).

UPDATE: I just realized that for ID3 v2.3, which I recommended for compatibility and which you probably already use, you only have the choice between UTF-16 and ISO-8859-1. So my recommendations in your specific case is to use ID3 v2.4 with UTF-8, and if this does not work as expected try v2.4 and v2.3 with ISO-8859-1 encoding.


#20

@outsidecontext I always find it slightly comical when a “Built in China” device can’t handle Asian text. Shows how little testing happens with hardware like this.