foobar not recognising all id3 (1/2) tags!, i'm sure the files are tagged Options

[snek_one]

Hi i was wondering why foobar seems to have problems reading certain id3 tags from files.. I have been tagging my files with tag & rename v3 but for some weird reason foobar shows some files as having "no information" and they are not sent to Audioscrobbler then either..

Any ideas as to why this happens?

Like I said, it works fine with most files, but only a few just don't seem to want to be recognised

[kalmark]

Do you use the foo_id3v2 component?
Is id3v2 enabled under playback->input->standard inputs?

[Ruby]

Sounds like there are APEv2 tags in those files. Files touched by mp3gain used to produce this effect for me... Just remove the APE tags and the ID3 will show up. (I don't know if there's a tool for that, I just use a hex editor to null the unneeded part.)

[snek_one]

yes i have used mp3gain on a lot of files...

i'll give it a shot trying to remove ape tags if any are present..

[Foobar_User10]

I too am having a problem on this front. I recently taged a number of albums using foobar. Today I shuffled around the directories of those files. Now the files that were moved have no tag info at all.
What can I do to recover the missing information? Does foobar not imbed the data into the individual files?
Other than changing the directory structure I have done nothing to the files.

Thanks

Ryan

[kode54]

This is a mp3gain misfeature. It doesn't fill new APEv2 tags with the existing metadata from ID3 tags because it assumes that nothing will read the APEv2 tag, or that whatever will read the APE tag will somehow combine the metadata from the other tags as well.

[snek_one]

There is no way to get around this problem?

does fb2k write replaygain information to the file itself?

[kode54]

Yes.

[phwip]

it assumes ... that whatever will read the APE tag will somehow combine the metadata from the other tags as well.

Is this really such a bad assumption? Surely it wouldn't be too hard to read every tag and then on a field by field basis decide which tag to display information from in order of tag type preference.

For example, a file contains an APEv2 tag and an ID3 tag, and APEv2 has preference so read into foobar2000's metadata all fields from the APEv2 tag. Then read the ID3 tag and add into the metadata any fields haven't already been set from the APEv2 tag. (And so on for all tags in order of preference)

It seems this is how Case's Tag works: if you give it a file that has an APEv2 tag added by MP3Gain that only contains ReplayGain information, and has all other metadata in an ID3 tag it displays both the ReplayGain information and the other metadata as if it had all been read from a single tag. To me this seems more intuitive and user-friendly.

[kode54]

Yes, but how to decide?

Should it include all fields of the same name if the data is different? How should it detect if the data only differs by an ellipsis? Or by abbreviation?

Does a tag reader really need to be this complicated and prone to error?

Since I know he won't waste his time by responding to this topic, I'll respond in turn, in the most likely fashion.

Tag combining is a stupid idea, and things are just fine the way they are. If you don't like it, don't use mp3gain, or don't use the undo data, or ask the author to include metadata from the highest priority ID3 tag when creating the APE tag.

If you want proper tag combining, the source code is available for your perusal and modification. Have a nice day.

[snek_one]

Who won't reply?


Am I safe to assume that if I remove all mp3gain information from my mp3's and then redo it with fb2k's replaygain it shouldn't happen anymore?

[dev0]

Am I safe to assume that if I remove all mp3gain information from my mp3's and then redo it with fb2k's replaygain it shouldn't happen anymore?

Yes.

[Snelg]

Yes, but how to decide?

Should it include all fields of the same name if the data is different? How should it detect if the data only differs by an ellipsis? Or by abbreviation?

Does a tag reader really need to be this complicated and prone to error?

Since I know he won't waste his time by responding to this topic, I'll respond in turn, in the most likely fashion.

Tag combining is a stupid idea, and things are just fine the way they are. If you don't like it, don't use mp3gain, or don't use the undo data, or ask the author to include metadata from the highest priority ID3 tag when creating the APE tag.

If you want proper tag combining, the source code is available for your perusal and modification. Have a nice day.

Or just maybe he'll "waste his time by responding to this topic" if someone would be so kind as to bring this topic's existence to his attention in the first place

Thankfully, that's what someone did.

And with a search, I can now see that this topic has been covered before, with various accusations of "buggy" or "bad" coding thrown at me without me being present or even aware of the discussion

So allow me to belatedly explain my decision process when I was adding APE tags to the MP3Gain code.

I chose the APEv2 tag format because I didn't want to mess with ID3v2 issues, and because I knew that foobar2000 already had Replay Gain support. I wanted to play nice with the only program in town that had that support built-in.

But at the same time, I knew that many users of MP3Gain would never have heard of foobar2000, much less be users of it. And I knew that APE tags can cause problems with some players. So I had to include the option to remove the APE tags that MP3Gain would write.

The problem I had to think about was what to do with this "delete tag" function. I could not just make it a global "delete the whole APE tag", because there may be other stuff in there that MP3Gain had nothing to do with. So the way it works (by conscious design!) right now is this:

1) MP3Gain only writes MP3Gain-specific information into the APE tag.

2) If the user selects "delete tag info" from MP3Gain, then MP3Gain deletes all of the MP3Gain-specific information from the tag. IF there is no other information left in the tag, then MP3Gain deletes the APE tag header and footer, too.

So now, keeping in mind that MP3Gain has to deal with both foobar users and non-foobar users, let's revisit the questions that kode54 brought up, but apply them to MP3Gain:

If MP3Gain, when adding a new APE tag, also copies ID3v1(and/or ID3v2) info into the APE tag, then when the user asks MP3Gain to "delete MP3Gain tag info" from the mp3, how should it decide?

Should it delete all APE fields of the same name if the data is different? How should it detect if the data only differs by an ellipsis? Or by abbreviation?

Does the tag code for a program that only deals with particular information really need to be this complicated and prone to error?

That's not sarcasm. I'd really like to find a workable solutions for all MP3Gain users. Thoughts?

-Glen

[kode54]

Oh, I'm sorry. I should have clarified. I was referring to Peter, since I knew he would not be responding to this topic. I am sorry if I gave you the wrong impression.

The issues I described would apply to Foobar2000, but they would no doubt apply to your software as well. So, I suppose being ambiguous with my generic response fit both sides of the argument.

EDIT after reading more of your post: Like you, I do not enjoy dealing with ID3v2. At all. That tag format has so damn many quirks. I thought of switching to libid3tag, but that's GPL, and its author decided that tags should be gracefully upgraded to 2.4 with no support for writing older versions. Hell, I don't even know if id3lib falls back on the version I tell it to, or just writes whatever fields I added regardless of minimum or maximum version.

I see I've also opened up quite a can of worms for you as well. Similar issues exist if I were to design my tag writer to maintain unsupported fields in the existing ID3v2 tag in addition to assembling a new tag from the supported data. A means to keep album covers or other image data in the tag, or other binary data which does not translate easily to text, which is all metadb can contain at this time.

Quite troublesome, eh?

This post has been edited by kode54: May 23 2004, 23:22

[Snelg]

Oh, I'm sorry. I should have clarified. I was referring to Peter, since I knew he would not be responding to this topic. I am sorry if I gave you the wrong impression.

No problem. I live by something I heard a long time ago:
"A man who takes offense where none was intended is a fool. But a man who takes offense where it was intended is a greater fool."
And I'm sorry for inferring incorrectly. Now someone out there is going think I'm a cocky jerk who thinks that everything is all about me

I see I've also opened up quite a can of worms for you as well. Similar issues exist if I were to design my tag writer to maintain unsupported fields in the existing ID3v2 tag in addition to assembling a new tag from the supported data. A means to keep album covers or other image data in the tag, or other binary data which does not translate easily to text, which is all metadb can contain at this time.

Quite troublesome, eh?

Yep. Troublesome indeed. But only for foobar2000 users who don't use APE tags in the first place

Maybe I should first finish the added tag features I've been planning on putting in MP3Gain-- an option to use the LAME header to store Replay Gain info (there's already a defined space for it), or to use the ID3v1 "comment" field. Neither of those solutions is ideal (what about mp3s that don't have a LAME header? What if the user want to keep the data in the ID3v1 comment field?), but I'm afraid this is going to be one of those situations where I can't please everyone.

-Glen

[Ruby]

How about an option to copy existing tags to APEv2? It could be enabled by default and when turned off, it could warn that not copying the tags could cause problems in some players, while leaving the tags causes no harm (right? ) but you won't be able to remove all of them with mp3gain. So, leave the dilemma to the users and let them pick their solution.

[Lyx]

I as well think that the problem should be solved on fb2k's side, since similiar problems can also happen if a file was not tagged via fb2k.

I would say the "combining tags" is the simplest workaround:

- Just search for ape-tags first - and use them
- then search for id3v2 tag-fields which have a difference field-name compared to the ape-tags
- then do the same for id3v1
- discard all "lower-priority" dupe fields - no matter if they have more info or different one.
- then synchronize the gathered fields to all tag-types which were selected to "write".

Not perfect if fields with same name and different data inside exist? Yes. But better than no tag-combining at all, imho.

- Lyx

[kode54]

You missed the part where combining tags is not "simple." DEATH expressed a lack of interest in doing this anyway. The source code is available if anyone else is interested.

[Lyx]

I did your earlier comment on that - thats why i proposed to "just discard lower-priority tag-fields which are dupe" - even if the data is different.

The result may not be optimal (as you pointed out in your earlier post) but i think its better than no tag-combination at all.

[snek_one]

So if I have understood all this correctly there is info being stored in my mp3 files in id3v1, id3v2, AND ape v2 tags?

Why have so many duplicates of this information though? All I use care about is the standard info: tracknumber, artist, title, album..

And i've tried cleaning 1 album which i can not get to display properly in fb2k.. no matter what i tried i still can't get foobar to read the tags.. i even used fb2k to remove all tags and removed mp3gain info.. then replaygained them with fb2k and then tagged them with tag & rename..

[bigmoose]

i have the same problem, i mp3gained all my files and it removed the tags so foobar doesnt pick them up now. so ive gone into tag&rename and started tagging the file in id3v2 and foobar does not pick it up. ive checked the input settings and hanged them around and sitll nothing.

but if i use the foobar freedb tagger, the tags show up in foobar. weird, i dont want to lose my gain info as i have over 16000 songs, which all need renaming tagging, but i cant handle gaining them again

any info would really be appreciated

btw im using azrael and columnsui

edit:
ok, i think i understand now, mp3gain stores info in APE2? and takes over the info currently in the tag? because when i remove the mp3gain i can see the tags fine. am i understanding this right? so now i need a tag and rename that can edit ape2?

edit2: hrm, thats not right, now i get some files tagged and others not, see screenie

http://www.thekiwi.com/Untitled.jpg

This post has been edited by bigmoose: Jun 1 2004, 03:07

[Lyx]

no, foobar looks in this order for tag systems: apev2, id3v2, id3v1

It will use the first tag-system which it finds - so if mp3gain stored ONLY the replaygain values in apev2, then foobar doesn't read id3v2 and id3v1..... because it already found ape-tags.

Foobar only READS from one tag-system at a time (per file) - the first one of the above found gets priority. However it does WRITE to all tag-systems choosen in the preferences - to keep those tags in sync.

- Lyx

[kode54]

That is how it works if it uses the global tag reading service, assuming any of the listed services are installed. Any input can do whatever it wants when it comes to reading metadata, or even writing it. Yes, you could produce your own version of foo_input_std that does the tag combining you want, by running the single-type tag reader service call several times on a temporary info class, then merge the values into the output.

Good luck, or something.

[johnb]

no, foobar looks in this order for tag systems: apev2, id3v2, id3v1

It would be nice if one could tell foobar the tag system to read from...

I suffer from the same effects mentioned in this thread.

Cheers

johnb

[bigmoose]

ok, now is there a way to get the mp3gain info out of the ape2 tag, and into the ide3v2?