MIP doesn't recognize MP3 tags (FLAC tags OK)... how to fix?

[lork]

Hello-

I have archived my MusicIP anaylysis to all my FLAC files, no problem, all mixable. However, when I do the same thing to my MP3 files they do not show as mixable.

I assume this is a tagging issue, but not sure how to fix it. Any help appreciated.

Some details:
I used Spicefly's suggestion as to getting the MusicMAgic Fingerprint field to show up in mp3tag, and it does for FLAC... however for MP3s, the field is empty... but when I click on a file in mp3tag & have it display the extended tags, the MM data & fingerprint are there (though in FLAC they seem to start with "MusicMagic Fingerprintxxxxx" where xxx is the hash, whereas in the mp3s they just start directly with the hash. The tags for flac files show up in mp3tag as "FLAC" tag type; those for my mp3s show up as "ID3v2.3 (ID3v1 ID3v2.3)". I can easily re-do the analysis (already have once), but need to know what to change in how the tags are written... or how to fix these tags in mp3tag.

[egd]

May be quickest to try the MusicIP forum for an answer.

[Nonreality]

Try to get rid of the ID3v1 tags in mp3tag. Do this on just a couple of your albums then rescan in SC and see if they show up as mixable. It's a good thing to get rid of them anyway unless you have some old player that only reads v3.1 tags.

[lork]

Thanks for the suggestion... I did, and then had to re-analyze since the analysis went away with the v1 tags...

But MIP (headless on Ubuntu) still won't recognize them as analyzed, though MIP running on XP does (and mp3tag shows the fingerprints when I do "extended tags". I do not have this problem with FLACs.

Maybe Mixer writes tags to mp3's differently than to FLACs? I can't find any option that varies where/how MIP writes the tags.

Confusing.

[Nonreality]

Yes you are right. My Flac files don't have the "magic" in front of tag names. But my SC recognizes both styles. Are the mp3's getting kicked because their duplicates? If you add a mp3 album with the GUI and analyze it then close and go to the headless, the cache needing updating doesn't show up? Or does that work and SC doesn't recognize it? The next time you get rid of the 3.1 files make sure you have it write all the info to ID3v2.3 first. Have it set to save ID3v2.3 in the options and highlight everything (ctrl a)and hit save. Sorry I didn't think to tell you that before. It would have saved your MIP tags.

[lork]

As far as I can tell, they were already saved both ways, and anyway I did save as v2.3 first, so nothing (other than the fingerprints/analysis, which must not have been int he saved v2.3... is this a clue?) was lost. It was not so well planned, but I keep backups to ease the pain of learning these systems

I'll try deleting the MIP cache on the ubuntu machine- thanks to egd I know where it is. I doubt that's it, though- I deleted a few songs from my MP3 folder (that had FLAC duplicates elsewhere) while changing the tags around, and the headless MIP (on ubuntu) recognized the change in the # of tracks and the # of "songs to validate" (= # of mp3 tracks... the FLACs all are recognized as already analyzed.

I am doing the analysis using Music Mixer on XP, then transferring the files to Ubuntu (where MIP runs headless). Are you doing everything in XP (I'm trying to figure out if the step to ubuntu contains the problem)?

[Nonreality]

Yes I'm doing it all on XP. I wish I had more ideas for you but for me it just works. I thought maybe the 3.1 tags were the culprit. For example SC would read the 3.2 tags and not the 3.1 which had the Musicip tags. But even after getting rid of the 3.1 tags it isn't working? Have you gotten rid of all of your 3.1 tags? I really don't know how SC works in reading tags but if it happened to lock on whatever type tag it first encounters and used that exclusively then that could be a problem. Do you ever see any Long titles that are cut off? Thats a sign of 3.1 if it's happening. BTW I'm just throwing ideas out.

[lork]

Hey, NonReality-

Pretty sure the 3.1 tags are fully gone. No long-tag cutoffs or anything, & mp3tag shows not 3.1 tags. Thanks for the ideas, though!

The (helpful) folks at musicIP are taking a look at the tags to see if there's a bug affecting the linux side. I actually doubt it, since I've heard no one else mention this, but maybe I'm the only one analyzing on XP and running headless on ubuntu (yes, I have a reason for this- NTFS is more reliable for archiving than ext3 as far as I can figure it out, but that's another topic).

Anyway, to avoid duplicate threading, I'm not going to post here again (except once, if I find the answer).

For those interested, the active thread is at MusicIP's forum:
http://forums.musicip.com/index.php?showtopic=3583

[egd]

I actually doubt it, since I've heard no one else mention this, but maybe I'm the only one analyzing on XP and running headless on ubuntu

This isn't the problem, I did a lot of my analysis on XP/W2K3 before genpuid existed. MiP GUI for Linux has always sucked so I gave up on using it in the early days of my intro to MiP

(yes, I have a reason for this- NTFS is more reliable for archiving than ext3 as far as I can figure it out, but that's another topic).

Don't want to start a Lin/Win discussion here, but in my experience it's the other way around. I've only once had an ext3 file system go belly up and it turned out to be a drive issue, whereas I've lost numerous XP partitions when there's been nothing wrong with the physical drive.

(Anyway, to avoid duplicate threading, I'm not going to post here again (except once, if I find the answer).

Just one question, are you rebuilding the cache to recognise the new files you're copying across from XP? If you're not using genpuid to append the cache you could try MiP GUI for Linux, however, genpuid would be simpler and adding new music is now covered in the Wiki entry.

[lork]

Problem solved!

In short:

The trick appears to be that one must write tags (if they include the MIP analysis) as UTF-8, which one can only do in mp3tag if one writes as "ID3v2.4 UTF-8" under tools/options/tags/mpeg.

A kind soul at MIP looked at my (sine wave) test track and found that:

The tag is stored in Unicode, which is the cause of the disconnect. Did you use any other tools on this file after the tag was written by the mixer? (I'm asking because the mixer is supposed to always write this as 8 bits, so that's an unexpected case).

I had used mp3tag to fix tags on things (moving them from ID3v1 to "ID3v2.3 UTF-16". I did this instead of "ID3v2.4 UTF-8" since I know Squeezecenter works with the v2.3 tags but wasn't sure about the v2.4 ones.

After the above response, I removed all tags from the track, rewrote them as "ID3v2.4 UTF-8", then (since the MIP fingerprints were gone) reanalyzed it in XP and moved it onto the Ubuntu server. There MIP recognized it as already analyzed, and SC allowed me to mix with it. (Surprisingly good mix it came up with based on a sine wave

To check, I then redid the above and furthermore read the tag up (including the fingerprint) and rewrote it as "ID3v2.4 UTF-8"... so this time the fingerprints/analysis were rewritten by mp3tag as well, just in UTF-8 this time. This track also scanned in MIP on the Ubuntu machine as already analyzed & was mixable by SC.

Thanks to all for the help.