Randomly disappearing tags (using Mp3Tag and MediaMonkey)

Hi,
i have a pretty well organised mp3 collection, but lately (about since i began using MediaMonkey) it occurs that tags randomly dissapear from files.
Most often some tracks in one Album suddenly miss all information (tilte, artist, allbum, track, year - everything). Sometimes it's also a whole album, with the albums alphabetically before or after it being complete.

I notice that mainly by opening the files in Mp3Tag. MediaMonkey seems to still have the information in it's libary - so there title, album and artist appear complete, though in the example i'm just looking at the genre and the album volume are missing in the two tracks which appear completely empty in Mp3Tag.

Maybe it's got something to do with the volume analyzing fuction of MediaMonkey? This morning I analyzed all the tracks still missing the volumes, so there shouldn't be any still missing it..

I just re-analyzed the volume for that album in MediaMonkey and now Mp3Tag find's Tags again, but the two tracks are still missing genre and the track number is one digit ("2" i jusually use "02")

Any ideas? I don't like my tags disappearing... :unsure:

I this is triggered by updating your tags using MediaMonkey, I'd suggest asking at their support forums. I don't have MediaMonkey installed.

Moderation: Removed full quote of previous post.

If you are not using the gold edition of MediaMonkey you need to manually scan any folder that you edit with MP3tag when you start MM. Make sure it's set to update your tags when scanning, I have mine set to update by timestamp. If you have the gold version you can have it watch your music folders and it will update automatically.
Also if you want to edit in Mediamonkey you need to make sure under options that you have it write the tags to the file and not just to the library when you edit them. This way you can use both Mediamonkey and outside sources to edit tags and keep them up to date.
Hope this helps.

Hmm, i've taken all these options into account, but still one of the two programs seems to forget witing the new tag sometimes when updating it.. I'm not sure whether it's mediamonkey or mp3tag but i asked in the mediamonkey forums too.
No other ideas?

I've come here in desperation via a Google search. I have been using MP3tag for years, since it was first developed in fact. I've always had a problem with MP3 tags disappearing. If any other tag-writing program writes to my MP3 files after I've set the tags with MP3Tag some tags can disappear. I really don't understand what's going on and I've tried to sort the problem out once and for all lots of times. I don't think it is a fault per-se with any of the tagging programs but feel that there is some sort of issue with the mp3 files and the space at the beginning of the file used for holding the tags.

The only way I can properly correct a file once some of the tags have been deleted is to delete all the tags in the file via MP3Tag and then put them all back in. It does not work if I just try to replace the individual tags that have been lost. If I do replace just the individual tags, although the tags look like they have been rewritten when viewed via MP3tag, SlimServer (and other programs) still cannot see them.

This has been happening to me now for at least seven years and I've never been able to figure out what has been going on (and once even Florian helped me to check that MP3tag was set up correctly!).

I also use MP3Tag for my flac files and have never experienced this problem with them.

MC

I'm guessing that you're using a program that adds APEv2 tags to your files (e.g., MP3Gain) while having reading of APEv2 tags enabled in Mp3tag.

Mp3tag reads different tags in MP3s in this priority: APEv2 > ID3v2 > ID3v1. So if you don't use APEv2 tags, just disable reading at Options > Tags > Mpeg.

I'm a new user of MP3TAG, it's just what I was looking for to make my files behave on some different devices. The way I describe my experience today is... "like dropping the needle in the groove" --Thanks!

So why post in this thread?

Windows 7 x64, a Zune software user (Windows phone,) MS Media player (for an old Sansa player,) and Media Monkey (DLNA stuff.) MM is only pointing to one directory, and that only has MPG (renamed from VOB,) IFO and BUP files.

I've noticed random tag losses while I'm using MP3Tag in directories that might be touched by other managers. It seems to happen when I am mass updating a directory. Win7 refreshes directory contents pretty much real-time and I noticed when the tags disappear in MP3Tag they are gone in Explorer a couple of seconds later (dual screen.)

Personally, I can modify my behavior to compensate for it without much problem. But if you would like me to help debugging the cause I will. I don't expect support for the other products but let me know if there are a couple of things to look out for.

ID3v2.3
I try to keep from running multiple managers at the same time. MM is NOT set up as a service (yet.)

Thanks,
Daddy-o

There is a thread that also deals with the cooperation of MediaMonkey and MP3tag.
[X] Mp3tag corrupts every mp3 file after editing the tag .
In short: don't use MM.

Also: it has been noted by other users in the forum, that sometimes MP3tag cannot access files for writing.
This seems to orginate in the Explorer that also reads (and blocks) the files while they are being updated. This is not quite the same as your approach but you tell us that you see the updates in WE. It may be a better idea to let WE point to a different folder and not to use the WE context menu on a file to open it in MP3tag but use the navigation from within MP3tag to open a folder.
Don't know if this helps

Thanks, I'll avoid that WE locking scenario. It makes a lot of sense in context with WE's realtime update behavior.

I haven't read the MM link yet. I sure hope it doesn't say something that makes me want to give it up for a DLNA server. I was really getting into the possibilities.

Turn off "Thumbnails" in Windows Explorer to stop it 'locking' files.

http://www.sevenforums.com/tutorials/11738...le-disable.html