id3v2.x tag frame wiping by replaygain plugin

[dbpower44100]

I wonder what replaygain does for example.

Apart from adding things to the tag it simply deleted things, which I rate it shouldn't at all.
With v2.4 TDRA becomes TDRC (recording date)
and it got TDRL (release date)

now since most programs do stumble across v2.4, there's quite some now which do allow to carry the TDRC & TDRL (v2.4 specific) within a v2.3 tag (header tells it's v2.3)

one could argue that this is against the defined standard, ok, granted, but what's definatly against the standard is that frames not able to be handled should be kept.
What I see is that running the r12 replaygain plugin within dbpoweramp does kill the TDRC frame from the tags. Wonder who implemented it that way.

And I got not much choice since I can't select v2.4 either in dbpoweramp.
Any idea ?

[LtData]

Re: id3v2.x tag frame wiping by replaygain plugin

dMC r12 only reads 2.4 tags. As to why it changed the tags, are those 3 tags in the 2.3 standard?

[dbpower44100]

Re: id3v2.x tag frame wiping by replaygain plugin

nope .. but when any program does read a tag it should try to read what it understands and keep the frames it doesn't understand. That's a common way that most programs do, since I can't rate a single program which is able to read and handle all frames.
Sort of .. looping through the frames (that's why they got a frameheader telling the length of the frame) and either process it if realising that it's a frame identifier the program could cope wiith, or simply copy the whole frame, leaving it untouched, in case it's a frameheader not known by the program.

If doing it differnt by removing all frames not being able to handle one could likely remove all frames from a tag by simple passing the file onto 10 differnt applications all claiming to be able to handle an ID3v2.x tag. Since each of them supports a differnt subset of the spec.

[Spoon]

Re: id3v2.x tag frame wiping by replaygain plugin

We use id3lib from Sourceforge.net This reads the entire id3v2 tag, modifies it and writes it back out. As this library is open source, anyone can modify it to add v2.4 support or fix any other issues you are having.

[dbpower44100]

Re: id3v2.x tag frame wiping by replaygain plugin

Didn't knew that dbpoweramp relies on such old stuff, known to be incomplete. It's well documented that it doesn't write back frames with unknown frameidentifiers, so this explains it all.

thanks for lettin me known

[Spoon]

Re: id3v2.x tag frame wiping by replaygain plugin

Hopefully for R13 we will be on a new library.

[dbpower44100]

Re: id3v2.x tag frame wiping by replaygain plugin

Picking up this old issue .... since I just upgraded to R13.

Looks as if nothing changed in R13, right ?
What a luck, noone'e is inventing ID3v2.5 since then dbp would be 2 minor version points from being up to date.
It's a real pain to loose frames when replaygaining previously tagged tracks since also v2.3 says ... don't modify anything you can't handle.

Perhaps we see a fix in R14 then ?

[Spoon]

Re: id3v2.x tag frame wiping by replaygain plugin

ID3v2.5 is never going to happen. v2.4 is a right mess with huge compatibility problems between the programs which implement it, v2.3 is the standard.

[Nonreality]

Re: id3v2.x tag frame wiping by replaygain plugin

ID3v2.5 is never going to happen. v2.4 is a right mess with huge compatibility problems between the programs which implement it, v2.3 is the standard.

I agree, I used 2.4 for a bit until I ran into all kinds of problems with programs. Now I use only 2.3 and don't seem to have any problems until a program intruduces a different tag without me knowing.

[dbpower44100]

Re: id3v2.x tag frame wiping by replaygain plugin

I agree, I used 2.4 for a bit until I ran into all kinds of problems with programs. Now I use only 2.3 and don't seem to have any problems until a program intruduces a different tag without me knowing.

until .... exactly, until you realise some programmers take the grip. And I wouldn't say 2.3 is a standand when saying 2.4 isn't. Both do exist, and there's bunches of programs supporting either or other or even both.

And there's one, dbpoweramp which simply wipes frames from v2.3 not being defined in v2.3, whereas even v2.3 mentions to not do so but leave stuff being a bit more but the coder could handle as it is. ;-) This coder surely knows, but doesn't bother.

What makes me happy, is that not only iTunes introduced the need for album artist besides what id3 specs say, but foobar moved onto 2.4.

There'll likely be a time google pops up with an itunes competitor, defining it's own interpretations of what an id3v2 tag should have or not, and if the masses follow the ideas sooner or later programs catch up due to the need.

And more or less directed to Spoon's answer that's it id3lib related, no can't be since some other programs are based upon id3lib which won't delete unknown frames. Thus it's a more brewn issue I think.

Since id3lib is well aware to read all frames, even the ones being located after an unknown frame, so the different between dbp and others based upon id3lib is simply there preserve the data as being said in the id3 specs, whereas dpb simply rips them off, means they are simply lost.

Well see .. with foobar and mp3tag going the v2.4 way, later one supporting both, the need arises since more and more problems do arise when using dbpoweramp since it wipes essential metadata without need.

Would at least be nice if the id3 part would get similar mappings such as vorbis comments. On the other hand, Spoon's well aware some other applications tagged ENSEMBLE and ALBUM ARTIST but only allows mappings for ALBUM ARTIST. I wonder why the list of mappings isn't userdefinable as are the input and result strings, since who knows, google might jump upon the train introducing something new, the mases will follow and the user will again have to wait until programmers catch up making their minds to either follow or wait until demand rises. ;-)

Anyway, as long as one remembers which programe do which harm, it's easy to remember to correct metadata afterwards. And no, I simply can't live with the 2.3 limitations. Did work for smaller collections, but not if you got identical albums as different releases, since then for example you need more but 1 year/date field, aswell as album subtitles and such like.
And again, vorbis eases the problem, since being totally open to what one includes as long as the taggers do allow.

[Spoon]

Re: id3v2.x tag frame wiping by replaygain plugin

>This coder surely knows, but doesn't bother.

We use ID3Lib the main open source id3 implementation...just goes to show the mess that id3v2 is.

Every major program / portable player supports id3v2.3, that cannot be said for v2.4.

RE Album Artist we are compatible with iTunes and WMP, that is 95% of all media players, it is hard to argue that that is incorrect!

>vorbis eases the problem

Do not kid yourself, vorbis comments are in an even bigger mess, there are 3 'standards' for album artist and nothing defined by spec.

[LtData]

Re: id3v2.x tag frame wiping by replaygain plugin

since being totally open to what one includes as long as the taggers do allow.

Yes, so then you have to have an implementation for each way the tagging programs work. See the Ensemble and Album Artist problem.

[Spoon]

Re: id3v2.x tag frame wiping by replaygain plugin

Well enough was enough, I am pushing Josh (of FLAC) to define standard values, Ogg Voribs is dead in the water, FLAC has the momentum these days.

[dbpower44100]

Re: id3v2.x tag frame wiping by replaygain plugin

>>vorbis eases the problem

>Do not kid yourself, vorbis comments are in an even bigger mess, there are 3 'standards' for album artist and nothing defined by spec.

pls, see below

>Yes, so then you have to have an implementation for each way the tagging programs work.

No, that's not what I asked for.
Get some 100 flac files from various sources (not all self ripped using dbp cd ripper, since that's a silly testbed, everything would be correct)
And then try to count the number of differnt vorbis comment strings. Then concentrate onto the ones you'd define being anything but standard. If you now find entries containing 'valid' metadata but using a non-standard commentstring, ask yourself what's the best solution.

I'd say the vorbis mapping ability from dbp is a good one since it'll allow to read what's stored using 'album artist' and does allow writing it as 'albumartist'. Metadata is kept not lost, commentstring turned into a propper one, ideal solution.

Now remember you likely found a handfull if not more entries where the metadata itself is ok, but unfortunately stored under strange terms. Not album artist only but all sorts of metadata, let it be releaseyears, whatever.

What's ideal now ?
a) to ignore them
b) wipe them
c) to ask the user to reenter it using the standard comment so that it get's stored as redundant data as long as you won't delete the stupid entry.
d) offer a user defined mapping which allow the user to enter the strange commentstring he's aware or of, and choose the resulting standard-string so that this issue is solved when writing back tags

I'd again say, d) is the best offer.

Now exclusive for Spoon. Perhaps my statement was wrong. dbp allows at least a handfull of possible mappings against lost frames (metadata) on the vorbis side. Similar to what happens on the id3v2 side dpb could have wiped all comments not being dbp-compatible.
Thus my statement corrected. "Not vorbis eases the problem, but dbp eases the problem", at least on the vorbis side of live, offering mappings.

And to force Josh to define something is a pretty good idea, no question. But remember, existing collections and it's issues won't auto-adopt that standard from themselves. Not mine, not yours, not the ones from anyone else. It's the existing issues in existing collections which ask for something to address them and dbp is at least to my knowledge amongst 2-3 programs offering that at a very small level. (the others completely ignore such issues)