Hi,
I just noticed that whenever foo_playcount writes its own tags to the mp3 files it completely removes the id3v2 tags from the files and only the id3v2 tags are here now!!!. I think I lost almost half of my neatly tagged (tags only) library because of this Is there any ways I can stop this from happening?
Thanks

Same here!

((((( Strictly4me )))))

Once again, for great tag safety, use this.

Do you mean it changed from ID3v2 to APEv2 tags? If so, its probably because you have foobar set to use APEv2 tags.

Otherwise, yes when you update a files tag, obviously the tag will be rewritten with the new info.

This FAQ has some more info about foobar's tags (look at the APEv2 entry specifically):

http://shsc.info/foobar2000

No Mike..it deleted my id3v2tags when it worte its id3v1 tags in the file. I dont understand why it needs to do this :S. Does anyone know if this is a bug and will it be fixed cause I want to have tags inside files rather than in a db

I disconfirm... The component never deleted a tag of mine :confused:

play a file WITH ID3V2 tags and then check with any tag editor happens everytime...doesnt do anything to ID3V1 tags though

If you have APEv2 tags as standard inputs in the preferences, make sure 'remove id3v2' aren't enabled. Otherwise, yes, it'll delete your id3v2 tags when fb2k writes something to the file.

I havent even got the libraries for APE tags support installes

What exactly do you mean by that?

I've played several hundreds files with ID3v2 tags since I installed that component, and none got deleted Check settings in Prefs|Playback|Input|Standard inputs?

Should have used my fork or whatever, it doesn't even affect tags, only info fields.

put the file type in DB only mask..

As reported on the component discussion, it'll only delay the write to file process. If you ever want to tag (or change tags in) the file, then the playcount tag will be written.

Sorry for the confusion above...my foobar was set to APE and ID3V1 tags but when I try the options ID3V2 or ID3V1 and ID3V2 the tags are there but it still removes the embedded album art.

KODE54
does the mysql service need to be started before using sqllite.dll? I dont want another extra process

I think, now i know why it's happen.
Look in your "components"-folder and delete "foo_id3v2.dll"!
This file makes foobar2000 possible to write id3v2-tags (by example for WAV), but it moves your id3v2-tags from mp3-files.
After you delete this file, you have also the possibility to enable/disable "Remove id3v2-tags while updating" in Prefs|Playback|Input|Standard inputs.
I hope this is, what you looking for.

((((( Strictly4me )))))

What the hell are you talking about?

Yes foo_id3v2 does enable you to write id3v2 tags to your files. And NO it certainly does NOT remove them from your files. Where would be the sense in that? Having a component that first writes id3v2 tags and then removes them again.

Hell no. That'd be considered environmental pollution.

foo_id3v2 enables writing of id3v2 tags exclusively to mp3 files.

Of course it does! - Try it out.


I don't know!
But if i have this foo_id3v2-file in my componentsfolder, all my mp3's are without id3v2-tags, after playing. Without foo_id3v2-file in my componentsfolder, the id3v2-tags still exist im mp3's, after playing!
I checked this out with "mp3tag"-program.

And now?

((((( Strictly4me )))))

Strictly4me you forget one little thing:
You have set "Tag type to write: APEv2 and ID3v1". If you set it to "ID3v2 and ID3v1", your ID3v2 tags will be kept of course as you can read above!

I believe dano is correct...

In the preferences foobar makes it explicit that "All other tags (than the ones you choose to write) will be removed." So if you have it set to write only APEv2 and ID3v1 tags, then ID3v2 tags will be removed.

And no matter what type of tags are in your files, they should still all be properly tagged in the database. If you enable ID3v2 tag writing, you can do a "Rewrite tags from database."

Where in the preferences do you see that foobar intentionally causes such dataloss?? IIRC I had set it to write APEv2 and ID3v1 for long and no "residual" ID3v2 tag was deleted in the process ever.


Try what?? Please write up a post that *accurately* describes what is going on and how to reproduce.

Not to be a dick, but everything you've asked was explained in the FAQ I linked in the 3rd reply. It really wouldn't hurt to read it.

The minute I posted that I began to wonder if I was remembering the preferences window incorrectly...in any event, there is something regarding tag removal in the same window that you specify which tags to write to, and aliumalik doesn't seem to be aware of it...

As far as I know all tags are always removed whenever there is an update. So if you switch to APEv2, on the first update your ID3v2 tags are stripped completely out of the file, and replaced with APEv2. Thats why ID3v2 is so slow in .8, and its one of the upgrades planned in .9.

Well you guys had me confused =o It's true that if (for example) you switch from "use id3v1 and v2" to "use apev2 only", and edit one tag with foobar2000 then all the id3 will be removed... In fact I used to rip with CDex and "auto id3v2 tagging", which is why I had id3v2 tagged mp3s although foobar was actually set to "id3v1 and apev2".
Edit: Note that if you do *not* have foo_id3v2.dll in the components folder then foobar won't touch your Id3v2 tags though (unless you've checked "Remove ID3v2 tags while updating" of course).

Thats exactly what i said before!


Now you have it!

((((( Strictly4me )))))

Yes, if you get rid of foo_id3v2.dll, it won't be able to strip the ID3v2 tags (or do anything with ID3v2 tags for that matter), but that's an awfully awkward way of achieving that aim.



My head is spinning. If you don't want your ID3v2 tags messed up, you have three options:

1) include ID3v2 in your "Tag type to write"
2) block tag update operations
3) sigh...remove foo_id3v2.dll

Removing the ID3v2 dll will prevent foobar from altering/removing those tags, but will it also prevent it from reading them?

And yes, I've confirmed, foobar strips all tags that are not chosen to be written:
"Tag type to write: (other supported types will be stripped from file)"

*g* I know this is a way to keep ID3v2-tags in mp3's!
But please to everybody here .... this thread is from "aliumalik" created and i'm just a guy, what try to find a solution for him and his problem.
I have sure *not* this kind of problem, because i tag my mp3's only with APE always. I just saw, it's true what he said.


I don't think, thats a solution for this problem, because so it's not possible to use "Playcount" as a tag in his files. In this way, he has just the possibility to write it straight in his database. - Not?

((((( Strictly4me )))))

key word is "supported types" there

Are you emphasizing that if the id3v2 dll is removed, it won't strip id3v2 tags? I don't disagree with that, I'm just trying to demystify foobar's stripping of aliumalik's id3v2 tags for him.

Indeed. If you remove foo_id3v2.dll, foobar will not recognize id3v2 tags at all and do nothing to them (neither read nor remove).


(UNLESS of course you specifically make foobar strip id3v2 tags by ticking "Remove ID3v2..." in standard inputs configuration.)


Anyway, I can just repeat what kode54 said earlier:

Yeah its tru I experimented witha a few files and the tags only disappear when foo_id3v2.dll is present. But I am kinda iffy on removing it as I sometimes need to edit the tags. In the end I am thinking of shifting to kode54's version as it took me 2 days to retag all my files and I definitely wouldn't want to do that again. While we are on the topic how do I get his version working I have both foo_playcount and sqllite.dll in the components folder but wheneer I press test it gives me some kinda error log.
Thanks for the replies people

ID3v2 tags will only disappear when ID3v2 is present AND ID3v2 is not selected as one of the "Tag types to write." I hate to harp on this, but it seems like you're blaming the dll itself, like it's "buggy."

You may ALSO block all tag update operations. It may be the case that you don't want to do this, but so far you haven't indicated as much. Clearly you use another program to tag your files, so what harm would there be in disabling foobar from editing them?

I just hate to see you go with an awkward solution (removing the dll) or an unnecessary one (kode54's sql thingy (no matter how well-written )).

Just disable 'remove id3v2 tags while updating' (or similar) under preferences>standard inputs. You'll be able to write/read id3v2 if you want and prevent fb2k to remove them.

even when the selected tag type has id3v2 it removes the embedded album art :S. One question though if I block all tag update operations will the playcount numbers still be in the db?

No.
"Remove ID3v2 while updating" option is there only because people kept asking for option to remove ID3v2 without having foo_id3v2 installed. It is grayed out (on purpose) when foo_id3v2 is loaded because all tag types other than ones being written are removed, and ones being written are entirely rebuilt from data used by fb2k so album art gets lost anyway (unless you don't have foo_id3v2 and don't have that option checked; then ID3v2 tags are untouched).

Exactly the same here!

"picmixer" wrote:

So i think, it's a bug in this dll-file.

((((( Strictly4me )))))

No it's not. This dll removes the tag then writes it.



Not behaving the way you want it to is not a bug.



Are we being had?

Absolutely.

edit: however, you will not be able to edit/create tags using foobar. And no, this is not a "bug."

One thing I cannot understand is why does it remove the embedded art in the first place?

Ok, man .... I believe you.
Anyway, i don't need this dll-file.

((((( Strictly4me )))))

Because it removes the whole tag, art included.

Yes, it removes the whole tag and since the database doesn't support binary data, the album art gets lost. Not very tragically IMO

The only scenario I can imagine being a problem here is if you keep album art in your ID3v2 tags, and you would also like to keep PLAY_COUNTER in your ID3v2 tags. If that's the case, there is no solution. But it sounds to me like you don't care where PLAY_COUNTER is stored, and think there's just this unbridled bug in foobar, running amok deleting ID3v2 tags willy-nilly.

It also sounds like you use another program to write your ID3v2 tags. So, deleting foo_id3v2.dll WILL solve your problem, but not because you're eliminating a malicious, rogue element. "Block tag update operations" will also solve your problem.

*head explodes*

Have you ever collected album art for ALL your files? I'd be pretty upset if I lost them too. But it would be my fault, not foo_id3v2.dll's.

Is anyone running kode54's version successfully? Whenver it tries to connec t with the db crashes and give me this error
http://s25.yousendit.com/d.aspx?id=1A10PY5...WW2B9VP66YIF24F


I dont wanna risk anything so I think Ill stick with a db only thing with my files set as read-only

Try to copy the sqlite.dll to the foobar2000 program directory (not the components directory) and see if this solves the problem.

@aliumalik
Why you don't use APEv2 to tag your mp3's?

((((( Strictly4me )))))