I had unpleasant experience of loosing tags on more then 5,000 MP3 tracks
Main reason for that to happen was my quick tactic to make definite tagging scheme on my MP3s (ID3v2 + ID3v1). Initially, all MP3s had ID3v1 tag then some of them ID3v2 (v2.4, v2.3) and others APEv2, while there were also tracks with all tag types inside.
What I did was select all MP3s with APEv2 tag (more then 10,000), then [Tagging - MP3 tag types] command and choose ID3v1 and ID3v2 (deselect APEv2).
In advanced preferences:
- "force tag scheme" was not selected
- default, ID3v1 + ID3v2 scheme was used
- use padding was selected
This resulted in approximately half of the processed tracks to loose some tags.
I first noticed that some of the files miss ReplayGain values, as all my files are processed with ReplayGain, and then realized what just happened. I tried to detect the reason for this, so that I could resolve to previous state with as less effort as possible, but without luck.
The files affected are with arbitrary MP3 profile, and mainly it affected whole album tracks, but in some cases it affected all album tracks but one, and in rare cases (like screenshot) couple of tracks. I'm providing screenshot to make more sense:
(http://img844.imageshack.us/img844/8329/scgy902v2s.jpg)
Above two example releases are grouped by folder and shows some tags. They were affected in two different aspects
1. Lets take first two tracks from the first Artist (Sub) which have ID3v2.3 tag:
- missing some TXXX fields like: %album artist%, %style%, ReplayGain
- TRCK is without %totaltracks%
- COMM is truncated to 28 bits
- TPE1 is truncated
- TLEN is reported as wrong
2. Opposite, lets take third track which has ID3v2.4 tag:
- missing TXXX fields as: MUSICIP, MUSICMAGIC, fingerprint, etc
Other than that, they both share same ID3v1 tags, and both lost additionally TXXX frames, like Discogs ID, MusicBrainz IDs...
So this is like general picture of consequences I have from using quickly masstagging capabilities of foobar. It doesn't happened to all files, and mainly the issue is like the first one described (ID3v2.3). I assume it's caused by some ID3v2 tag type, but that's not an answer. Hope that information is comprehensive and there is someone who can point at what happened, for indulgence and curiosity
Thanks for reading
I guess the post is hard to read, and of course no one has to read it
Right now I'm going to make ALL MP3 playlist and process the files with "force tag scheme" ticked - to write ID3v2.4 to all of them because as posted some still have ID3v2.3
Not to be so quick minded as in first try I did "rewrite tags" (with "force tag scheme" ticked) on first two tracks from example 1, and they ended with ID3v2.4 tags as expected.
Output from Axone (as suggested in couple posts on HA):
Does fb2k even ever use TLEN for anything?
I thought it determines track length only by rough calculation like (frame_count * samples_per_frame / sample_rate) or from the LAME "gapless" header.
Hey, thanks for you reply Yirkha
I guess you are right, and that issue is rather minor, but why is that frame left wrong?
What do you think about missed tags from the first post, if you can answer?
Is forcing tag scheme right approach? Because I'll have to do manual retag on 5,867 MP3s that lost discogs ID and MusicBrainz ID (important for tagging) and ReplayGain process them (ARGHHH)
Thanks
I tried to read and parse your first post here the other day and I did not have any clue what could cause such an inconsistent mess and just felt sorry for you losing so many tags.
Now, I'd probably go the rewriting route too. Or maybe even copied all info in Properties, do Tagging > Remove tags from files, then Paste Fields and write it all again - just to be sure the file doesn't have anything else than the MP3 stream itself before tagging them again.
But I'm not sure how that would deal with e.g. multiple ID3v2 tags, or how awfully long would it take (due to removing padding and then adding it again, shifting the whole payload each time).
Thanks again Yirkha, I feel sorry too
I guess this is better than solely rewrite tags:
Now, I'd probably go the rewriting route too. Or maybe even copied all info in Properties, do Tagging > Remove tags from files, then Paste Fields and write it all again - just to be sure the file doesn't have anything else than the MP3 stream itself before tagging them again.
Then again, I burned myself there, maybe command [Tagging - MP3 tag types] should warn user about ID3v2 inconsistences (like 2.2, 2.3, 2.4 presence) because I think that was the main problem.
If I had track with ID3v1 and APEv2, it would successfully be written to new tag scheme, but something went wrong with ID3v2 schemes.
It looks like mess, that's true, but half of processed tracks were left behind. Presumption that files can be tagged by other software* must be taken. I'm not saying that it's not, but maybe some more checking can be made in such destructive scenarios (then maybe it's just me burned).
*I tagged those files either with Mp3tag or genpuid.exe (ftp://ftp.musicbrainz.org/pub/musicbrainz/genpuid)
No other software was used, and all of them were first passed to foobar tagger and then used additional tools for tagging some mentioned data
edit: Also, thinking more now, it might had been that all those affected files were with all tag types (ID3v1, ID3v2x, APEv2) then deleting APEv2 tag led to this mess (assumption)
It might be that the tag scheme rewritting tool doesn't work well in complex cases. I personally haven't used it for years and I would not be surprised if seldom used code breaks over time without anyone really noticing.
I might try experimenting with files with all ID3v1, ID3v2 and APE tags to see if something breaks here too when I have more time. I think something like mismatched offsets during removal of one tag due to another tag being removed before could cause those curious truncations and other weirdness.
I did one more check (before going cycling) and I'll do more when back
One mp3 track with pure ID3v1 tag
Do ReplayGain - to APEv2 tag (ID3v1 + APEv2)
Do genpuid - adds ID3v2.3 tag with wrong TLEN attribute and all other data correct to ID3v2.3
Do command [Tagging - MP3 tag types] and choose ID3v1 and ID3v2 => left with partial data, loosing ReaplyGain and other (from APEv2) as explained in example 1 from 1st post. So it seems self-explanatory
Even "force tag scheme" doesn't help here (ID3v2.3 still remains, unexpectedly), so be cautious user of this command
I gave up on tracking the reasons for this mess, and now have some free time to finish what I started
I made playlist and use Mp3tag to differentiate between ID3v2 tags and make final playlist which I'll process afterwards in foobar: copy tags - remove tags - paste tag fields - write new ID3v1 + ID3v2.4 (padded)
"rewrite tags" won't do it for me, as Yirkha suggested
However I run on another issue: one release is reported in Mp3tag that has APEv2 tag, but foobar doesn't report so. This release also has LYRICS3v2 tag So I went to foobar properties, copy tags, remove tags, paste fields then write tags - result the release has the same APEv2 and LYRICS3v2 tags:
(http://img202.imageshack.us/img202/1233/v8skppfqzi.jpg)
Editor is split, and that which looks like garbage in the second split is part of JPG cover embedded
I could guess only the reason for LYRICS3 tag not being removed: foobar doesn't care about LYRICS3v2 tag, and it wont read, nor remove this tag
But could it mask APE tag to foobar, or what?
I just finished rewriting tags on 10K MP3s instead 5K, so I would like to present this method if someone has the same crazy idea
1. make desired settings in advanced preferences
2. make MP3 playlist and select all items then go to properties
3. ^A, ^C, then Tools > Remove tags *
4. ^#V (paste fields) then Apply
* If the number of files is huge, don't forget that you have all data in clipboard. Even if you know like I knew, I made mistake and copied other data in clipboard and then just felt cold breeze (I was doing this on my main PC). However this can be solved by simply right clicking already selected files (while remove process is still working) and then copy all tags again (thanks God)
But wait! Another issue, like Yirkha suspected maybe in post #7? Even if I made myself sure that all files to be processed are only with ID3v1 + ID3v2.4 (no ID3v2.3, no APE, no LYRICS3v2...), I lost %album artist%, %total tracks%, maybe alse, on some of them. The files that lost data were not padded. Now, how can that be?
Seeing modified time it's clear that files were written in right sequence. I have copy of raw clipboard data, that I made after the accident just in case, but nothing interesting there I guess
In conclusion: Don't try this at home, it's bad practice