Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [FEATURE REQUEST] deleting undisplayed id3v2 tags (Read 6684 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

The fact 0.9 doesnt display some id3v2 tags (component in 0.8.3 did) isnt a real pain compared to that we have no knowledge of what foobar writes (it may rewrite during tagging for exapmle some unproper and unneeded covers, that additionaly take some space) into our files. The only option to get rid of unwanted tags is to select "Tagging>MP3 tag types>unselect idv3v2>update files" or write additional apev2 tags using the same method. So why not to make it simplier? Why not let to choose if we want to strip (undisplayed by 0.9) id3v2 tags or keep them? I decided to type thic post in hope that others also want this function to come back, and maybe dev's will make this small change in next version (0.9.1?) or someone will write component for this (hmm, it could for exapmle write apev2 and delete them, but thats probably not the clearest way). What do you think about it?

PS. Some undeletable tags in 0.9 (they are rewritten without our knowledge):
UNSYNCEDLYRICS
INITIALKEY
COVER
INVOLVEDPEOPLE
And more that i havent tested.
Please dont understand me bad, foobar is great software, especially 0.9, but it will even better with this feature

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #1
could you tell me, where to find the foo_id3v2.dll for 0.8.3 online?

every link seems broken and unavaible, googled it: no results.

please help me

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #2
I agree that some temporary instrument to keep the consistency from 0.8.3 and 0.9 should be considered. Especially now that all the community is having the two feet into two different shoes.
It's quite fearful for people, like me, that spent hours tagging its files with 0.8.3 see part of his work disappear when he load them into 0.9 and not properly understand why.
As you carrectly stated, it's even scaring thinking to use 0.9 to wite tags (still the ignorant point of view).
Maybe it would be useful some sort of indicator beside any tag to know which info we have into which tag type. Or maybe, in properties, having one pane for each type.


[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #4
thank you very much!

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #5
I agree that some temporary instrument to keep the consistency from 0.8.3 and 0.9 should be considered. Especially now that all the community is having the two feet into two different shoes.
It's quite fearful for people, like me, that spent hours tagging its files with 0.8.3 see part of his work disappear when he load them into 0.9 and not properly understand why.
As you carrectly stated, it's even scaring thinking to use 0.9 to wite tags (still the ignorant point of view).
Maybe it would be useful some sort of indicator beside any tag to know which info we have into which tag type. Or maybe, in properties, having one pane for each type.


Hmh, there seems to be a lot of fear in you.

Well, first of all about the "consistency tool". This certainly won't happen. It has always been known that fb2k at it's current stage will most likely break certain compatibilty on major updates ie. 0.8x --> 0.9x in certain areas. This is to keep development going forwards and not backwards. Also I am sure none of the developers see a reason to waste their time on writing such a tool.

About this while tagging issue. Of course fb2k won't delete any id3v2 tag values that it cannot read. Imagine all the whining we would get from people if some of their tag values where erased by writing tags in fb2k. Just remember all the "OMG fb2k has eaten my album art" posts for 0.8x.

If you want to remove those values please use an external tagging program that can read them.

Also I have been using 0.9 since the earliest alpha releases and so far strangely have never run into any kind of tagging problem whatsoever. For me everything still works fine just the way it did with 0.8. Not a single time I even had to think about any tagging options.

I guess if you want to look for someone to blame you could blame messed up id3v2 standards and messed up implementations of id3v2 all over the place in other players.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #6
Quote
Hmh, there seems to be a lot of fear in you.

As I wrote, ignorancy leads to fear (even if a little one).

I know I don't have a comprehension of what really happens when I tag a file so, when I see a thing in an app and a different thing in another I'm a little puzzled.
And thinking to erase something using one or the other app, without knowing what is really going to happen, makes me afraid of loosing hours of work in just a couple of clicks. Unfortunately I choose to use many custom tags that you can't retrieve autmatically. And there is no Undo for a file operation (unless you keep a backup of Gigas).

Quote
Well, first of all about the "consistency tool". This certainly won't happen. It has always been known that fb2k at it's current stage will most likely break certain compatibilty on major updates ie. 0.8x --> 0.9x in certain areas. This is to keep development going forwards and not backwards. Also I am sure none of the developers see a reason to waste their time on writing such a tool.

I agree with you that developement should always go forward. But it should also try to catch up the changes. I mean that, if possible, the developer of the ID3v2 tag reader for 0.8.3 should have updated his plugin to 2.4 - even if the 0.9 betas was already around. Another way could have been to keep the backward compatibility in 0.9, if possible, at least for some time. But this is just the easy point of view of a common user.

Quote
Also I have been using 0.9 since the earliest alpha releases and so far strangely have never run into any kind of tagging problem whatsoever. For me everything still works fine just the way it did with 0.8. Not a single time I even had to think about any tagging options.

Unfortunately, with the standard tags, I can see differences for some files. I think this is only true for files I didn't tag myself but nonetheless...

Quote
I guess if you want to look for someone to blame you could blame messed up id3v2 standards and messed up implementations of id3v2 all over the place in other players.

No, I'm not looking for blaming anybody, I can't. I can only say a big thanks to all the people that uses its time to develop, polish and mantain all the things that make easier dealing with a large collection of music files, retrieve them easily and enjoy listening to them, instantly knowing who's that saxophone that's "calling me home...".

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #7
I guess if you want to look for someone to blame you could blame messed up id3v2 standards and messed up implementations of id3v2 all over the place in other players.


Standards are never properly respected in the real world. Ignoring that fact could be politically correct but it will always be considered useless from the end users'point of view.
I understand that this is done as a way to push forward the adoption of the standard but until that happens (and it probably will take months or even years) this will go against foobar's usability.
Look into Firefox for example, even with all the W3C standards evangelism being done there is still Quirks Mode for rendering all those pages that dont comply with W3C standards. If Mozilla developers would had just ignored the fact that many of the actual content of the web does not render correctly in Standards-compliance mode Firefox would be pretty useless right now.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #8
What is more, masstagger option "delete all tags" now doesnt delete all tags, only some chosen from standard id3v2 set. Is only cause confusion.

What is more, now when i have some tags like UNSYNCEDLYRICS, INITIALKEY, COVER, INVOLVEDPEOPLE, LANGUAGE in id3v2 frames, and i want to convert them to apev2 they will simply be lost. To be more clear i must say that in 0.8.3 they were simply saved.

You, picmixer, say that it is imposible to delete tags that foo cant read, so how it is possible that foo rewrites them? Will it hurt to allow people to save undisplayed tags, and others give an option to dele them?

So whats the real reason of not implementing option to strip unwatned tags, is foobar cutting of own futures that its users got used to? It just makes some things even more complicated. One more question: is foobar going to have support of all standard id3v2 tags?

All i want is simple feature that will allow me delete tags that i dont wont, i dont like id3v2 being suppoerted only in some part, i just expect that masstager function "delete all tags" will delete all tags, not only some of them.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #9
The current version does not support all ID3v2 tag frames, so according to the ID3v2 specificiation it does not remove them when rewriting the tag. It is simply a matter of leaving uninterpreted (by foobar200 0.9) data in the file.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #10
So will the newer version support them all, allowing to delete them?

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #11
Since we received so many contradictory requests regarding id3v2 tagging, we decided to drop mp3 support entirely in the next version of foobar2000.
A riddle is a short sword attached to the next 2000 years.

[FEATURE REQUEST] deleting undisplayed id3v2 tags

Reply #12
Since we received so many contradictory requests regarding id3v2 tagging, we decided to drop mp3 support entirely in the next version of foobar2000.


Ah, now that's jolly good news!